Slashdot Mirror
A Proper Environment for Web Development?
umdenken wonders: "I'd like to know how others on Slashdot do their server-side web programming. We have dozens of Perl CGI scripts, and are currently doing development by editing these production scripts in place on the web server (!). Our sysadmins have finally installed an SVN client on the server (Solaris), and have offered to create a new virtual host that we can use as the development server. What are some of the practices you use for organizing this kind of set up?"
In my experience, I have found that it is best to have four environments: Production, Pre-Production, Testing, and Development. Every environment is isolated and has the same hardware and software.
Developers do their development in one environment (if possible, each developer should be isolated), and when their code is written it goes to a testing server where it can be hammered by your QA/Testing team.
When it passes QA, it goes into Pre-Production, which is what your Production environment should look like when you push your changes live. Any kind of external integration can test against this environment, since it is as close to your production environment as possible.
Then, you have your production environment where everything is live.
It is VITAL that each environment is set up the exact same way, or as close as possible, to every other environment. Each one should have its own separate hardware running identical software versions - unless you are testing software upgrades, in which case you FREEZE THE CODE, update Development, then QA, the Pre-Production, then Production (testing everything, everywhere), and THEN resume writing your code again. It is incredibly frustrating for a developer when code works on servers A, B, and D, but breaks on C and E due to non-matching hardware and software.
It is also important that your developers and qa team have access to fresh, live data if at all possible. It is easier to develop when you have real data to develop with; Plan on updating your QA and development data once a week.
If you have a set up like this, then development, testing, and deployment will be very smooth. It can be a bit of a pain to set up at first, especially if you are not used to the idea, but once you have something like this I promise that you will never go back.
Other people may recommend different set ups, but the basic idea is the same. Keep the developers separate from the testers, keep everyone separate from production. The pre-production just makes deployment easier - push code that passes QA to pre-production, then when the time comes, just rsync the files over.
Love sees no species.
If you find a bug on the test server but can't reproduce it on the production, don't assumed that it's not there. My boss made that mistake since he couldn't reproduced the bug for a new tool on the test server and he approved the release candidate. The art department was consistently crashing the production server the next morning by using the new tool as described in my bug report. The production server was off line for three days as the programmers had to do a thorough code rewrite that cost the company $250K. A few months later, they declined to renew my contract. Go figure.
Big Fan of PXE and kickstart for deploying development machines and Yum/Apt for deploying code.
1. Use PXE as a way to get an install running as quickly as possible. Do a minimal install to get the machine up and on the network.
2. Use Yum, Apt or Yast according to your distro to install everything required to support your development and application stack.
3. Your code should be done as a package (RPM/Deb). Yes, even for web stuff. If you customize your Apache install, that should be a package, too.
4. Use Subversion. CVS makes me sad, because it isn't Subversion.
5. Have a build environment that pulls your code out of subversion and builds it for QA. A package that is built here is what will be pushed live.
The bottom line is make it as easy as possible to reproduce your environment.
And back everything up over the network to a server in another state. Prefereablle, two different servers, at least one on another coast.
Open Source Identity Management: FreeIPA.org