Re: [PLUG] dev vs production environments

["John BORIS" <jboris@adphila.org>]

I think that you are going to find multiple concepts, versions or
methods that are used to answer this question. I feel it depends on the
environment that the you are in. But the concept remains the same --
"You want to test your product before rolling it out". Now how much you
test it and how you perform those tests is going to be governed by your
environment. If you have the $$$$ to have multiple machines and a
testing group (QA) and ample time you may do it one way as opposed to
someone who has limited $$$ and resources. Along with that, as has been
alluded to in this thread, how much grief can you stand for having bugs
in software. How many legal problems can a buggy program cause. Will you
still be employed if a buggy product is rolled out.

So if your head is on the block for what the developers do then they
should cowtail to your policy, enough said. But you have to have the
support of your superiors.

Here at my $WORK I wear multiple hats. Software Manager, System
Administrator, Programmer, Documentation, Tester, QA and much more. I do
have three programmer that do the lions share of my coding. They are
required to test their stuff before they throw it over the wall to me.
Then I have to test it before it goes into production. My users andmy
superiors don't want to hear the programmer missed something. They want
to know why I didn't catch it. So suffice it to say I demand they have a
testbed with the latest data to test their work. In here I have multiple
VMs to test their work and for my in house programmer to test her work.


A good programmer will always want someone else to test their work. The
programmer can miss something. Especially if you are in an environment
where you don't have the luxury of extensive test plans and testing
groups and they are the alpha and beta testers of their own work.

John J. Boris, Sr.

"Remember! That light at the end of the tunnel
Just might be the headlight of an oncoming train!"
Professional IT Community Conference (PICC'12)
www.picconf.org ( http://www.picconf.org/ )  


>>> Douglas Muth <doug.muth@gmail.com> 1/26/2012 9:38 AM >>>
On Wed, Jan 25, 2012 at 5:22 PM, JP Vossen <jp@jpsdomain.org> wrote:
>
> I'm having a problem at work convincing some developers that the dev
and
> testing environments should match production as close as possible.
Since
> this is all Linux stuff, and we have machines and virtualization,
this seems
> like it should be a no-brainer to me.  In fact, this is so
blindingly
> obvious that I'm having trouble making a stronger argument for this
than
> "because it's so blindingly obvious."
>

I agree.  It blows my mind that people wouldn't want their machines as
close to identical as possible.

I use 2 approaches at $WORK that I haven't seen mentioned in this
thread:

1) Amazon web services.  It is stupidly easy to make disk images of
machines and database instances while those instances are running.  In
fact, I have an automated process that does this in the wee hours each
morning.  For each server.  So if I ever need to build a new
production server, or a new staging server, I just create a new
machine based on the most recent image.  Saves loads of work, too.

2) Revision control for configuration files.  I keep all of our
webserver configuration files, along with a common bashrc file for
developers to use, inside our git repository.  Any changes that are
made are made to those files and then pushed to other machines.  Not
only does it keep the configuration standardized across machines, but
it also provides auditing of who changed what and when they changed
it.

As a corollary to 1, I also use EC2 security groups so that only the
production webserver can talk to the production database, the staging
webserver can talk to the staging database, and the dev webserver can
talk to the dev database.  This ENSURES that an engineer can't
accidentally work on production data from the dev machine, for
instance.

Just the easy ability to make disk images makes AWS/EC2 a no-brainer
for my company.  It's saved us so much time and hassle with sytems
management.

-- Doug
___________________________________________________________________________
Philadelphia Linux Users Group         --       
http://www.phillylinux.org 
Announcements -
http://lists.phillylinux.org/mailman/listinfo/plug-announce 
General Discussion  --  
http://lists.phillylinux.org/mailman/listinfo/plug
___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug