How Do You Manage Dev/Test/Production Environments?

An anonymous reader writes "I am a n00b system administrator for a small web development company that builds and hosts OSS CMSes on a few LAMP servers (mostly Drupal). I've written a few scripts that check out dev/test/production environments from our repository, so web developers can access the site they're working on from a URL (ex: site1.developer.example.com). Developers also get FTP access and MySQL access (through phpMyAdmin). Additional scripts check in files to the repository and move files/DBs through the different environments. I'm finding as our company grows (we currently host 50+ sites) it is cumbersome to manage all sites by hacking away at the command prompt. I would like to find a solution with a relatively easy-to-use user interface that provisions dev/test/live environments. The Aegir project is a close fit, but is only for Drupal sites and still under heavy development. Another option is to completely rewrite the scripts (or hire someone to do it for me), but I would much rather use something OSS so I can give back to the community. How have fellow slashdotters managed this process, what systems/scripts have you used, and what advice do you have?"

go virtual

[Anonymous Coward]

Have a perfect virtual machine image ready. You can bring up a new server in about 5 minutes.

Leverage your issue tracking and cvs

[dkh2]

If you're able to script deployments from a configuration management host you can script against your CVS (SVN, SourceSafe, whatever-you're-using).

There are a lot of ways to automate the management of what file version is in each environment but a smart choice is to tie things to an issue tracking system. My company uses MKS (http://mks.com) but BugTracker or BugZilla will do just as well.

Your scripted interface can check-out/export the specified version from controlled source and FTP/SFTP/XCOPY/whatever to the specified destination environment. For issue-tracker backed systems you can even have this processes driven by issue-id to automatically select the correct version based on issues to be elevated. Additionally, the closing task for the elevation process can then update the issue tracking system as needed.

Many issue tracking systems will allow you to integrate your source management and deployment management tools. It's a beautiful thing when you get it set up.

Hilarity

[eln]

Another option is to completely rewrite the scripts (or hire someone to do it for me), but I would much rather use something OSS so I can give back to the community. How have fellow slashdotters managed this process, what systems/scripts have you used, and what advice do you have?"

I'm sure you have a legitimate problem, and there are lots of ways to solve it, but this line just cracks me up. You COULD write it yourself or pay someone but if you use someone else's Open Source work (note: nothing is said about contributing to an OSS project, just using it) you'd be "giving back to the community.

Translation: I have a problem, and I don't want to spend any of my own time or money to solve it, so I'm going to try and butter up the people on Slashdot in hope of taking advantage of the free labor force that is the OSS community.

Simply using Open Source software is not giving back to the community...using open source software is what gives you the moral imperative to give back to the community, which you can do through contributing code, documentation, beta testing, providing support on the mailing lists, or whatever.

Most important thing in my book

[BlueBoxSW.com]

Most important thing is to treat your code and data separately.

Code:

Dev -> Test -> Production

Data:

Production -> Test -> Dev

Many developers forget to test and develop with real and current data, allowing problems to slip further downstream than they should.

And make sure you backup you Dev code and you Production Data.

Re:go virtual

[palegray.net]

I was going to suggest using virtualized environments as well, but that still leaves the admin with the task of automating the management of all his difference systems. Frankly, I've always approached this the way he's already doing it: a set of scripts that manage things.

I'm not aware of any systems that do all this for you while still being flexible enough to accommodate lots of unique requirements. The script-based systems I've employed over the years all followed some basic rules:

• Increment the version number and make a new DNS entry for each committed changeset.
• Only allow migrations to "test" from "dev", and from "test" to "prod".
• Allow automatic reverting to a previous version in test or prod, but require manual merging of changesets from later revisions to put them back into the older upper stage.

I've successfully managed hundreds of sites and web apps in this manner, with minimal fuss. Virtualization adds in extra complexity in some respects, but makes other things easier as each VPS can have its own customized environment. As long as everything in dev, test, and prod uses the same base VPS environment, problems should be minimal.

Re:You are not a n00b

[Eil]

If he is indeed allowing FTP logins over the public Internet (as the submission suggests), he is a n00b whether or not he realizes it.

Re:You are not a n00b

[Anonymous Coward]

n00b is unknowable?

Re:You are not a n00b

[fuzzyfuzzyfungus]

How Socratic...