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?"

Re:Separate your environments

[Phillup]

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.

I like for the pre-production and production environments to be as close as possible.

But...

I like the dev and testing environments to be different from each other... and from the production environment.

I've found that doing this helps me shake out some "dependencies" that I may not have thought about.

Taking care of those "dependencies" helps me write code that is easier to move to another environment if the customer wants to upgrade their systems.

YMMV

Process with Tomcat

[wmshub]

I use JSP, which makes it a little bit easier to use "good practices" since you can't just edit the files on the web server.

Instead I build up a .war file (with ant), which as a side effect also verifies that all source is committed into subversion, then it tags it all so I can always see exactly what went into the current release on the web server. Then I install the .war on the test server. Test. Then remove the current webapp from the release server. Then, as quickly as I can, install the .war that was tested. (There should be a way to tell tomcat to install a new webapp *on top of* an old one, then undeploy the old one, removing this "gap" where no webapp is present...anybody know how to do this?)

There are drawbacks though. Once in a while there's an emergency and I'm asked, "can't you just edit this file and get it fixed in 30 seconds?" and I have to explain that even if I skip the "test" period, the build/upload/install takes about 20 minutes (it's a big webapp, the build script runs some image generation apps that take 5-10 minutes minutes).

Minimize complexity

[riceboy50]

In my opinion, there is a point at which complexity outstrips any gains from separation. Just keep it simple; dev, staging, production.

Re:Er, uh

[ePhil_One]

He's currently doing dev directly on the production server and is wondering if there is a better way.

His COMPANY was doing dev directly on the server, he has implemented SVN and a Test environment, and is wondering what the Best Practices might be. He knows there's a better way, and rather brilliantly knows he doesn't have all the answers.

For the record just a dev and prod environment isn't enough, ideally you would have multiple dev environments (individual playgrounds plus common test areas, two QA environments (New releases and current release for bugfix testing), and possibly even a User Acceptance Testing area. There should be no code updates a release is migrated through the environments, all environmental variables get read from the environment...

Of course, every dev environment will be different, with different needs, release cycles, etc...

Re:Separate your environments

[Fulcrum of Evil]

I like the dev and testing environments to be different from each other... and from the production environment.

Simple solution that mostly works: run a lot of the dev stuff on your desktop. Depending on your environment, that can isolate developers from each other and free up a test server for 'more stable' code.