Re: [PLUG] dev vs production environments

[Sam Gleske <sam.mxracer@gmail.com>]

Hey JP,
It depends on what type of data you're handling and types of
applications/services your company is deploying.  For the remainder of
my response I'll assume you and your devs are not trying to run a blog
about cheese sandwiches.

At Drexel we follow PCI security standards and having separate test
and production environments is outlined as part of the standards.

http://whatispcicompliance.org/pci_audit.html

There are legal advantages to forming a separate production vs. test
environments.  Should a machine be compromised and a lawsuit is a
result from that compromise then the outcome of that suit can be very
different depending if your devs and testers are using real customer
data or fake test data.  I found an article which explains better than
I could about that.

http://career-resources.dice.com/job-technology/dangers_testing_real_data.shtml

Your devs, testers, and corporate managers need to understand this
basic concept: hardware is cheap and data is expensive.  Actually
mainly the people who make decisions about money and purchasing need
to understand that concept the most.  Luckily, my boss and the bosses
above him understand that.

At Drexel we have more than 200 production servers which are running
in VMs.  For every production server there is a test equivalent.  Even
if the machine is as simple as a proxypassing gateway which insulates
the service while still providing it, it still has a prod/test mirror.
 Whether it be Linux, Windows, Solaris, .... whatever.

So I would try to convince the devs and management to stop flying by
the seat of their pants and try to understand that by spending money
up front on "best practices" could save them millions of dollars in
the long run.  Let's try to come up with a list of good points to
pitch.

* Lost customers from application downtime because the environments
between test and production were different and not properly accounted.
* Lost customers from poor application reliability since the
application could work different in test than prod if they're not
closely similar.
* Possibly costing the company millions of dollars for losing a law
suit on something which is easily followed.

Another idea which you could suggest for test environments is the following:
* Having separate FQDNs for test and prod such as *.test.company.com
and *.prod.company.com
* In the case of VMs, create only the test environment first.  Then
when that environment and app are stable (pointing to test databases
and what not) create a copy of the test environment (changing the MAC,
computer name, etc.) and make that copy the production environment.
This means you would point that new environment at prod databases
instead of test databases.

That's about all I can think of for now,
SAM
___________________________________________________________________________
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