Paul Stovell says…

Mitch just wrote a blog entry on software teams that can’t react quickly.

In the scenario that I am thinking of this would allow the development team to provision a system that was instantly more useful to them and allow a very costly resource to be more productive. The fix for the broken team is realize developers and systems guys are fighting for the same cause and ultimately developers share some of the operational skills that system administrators have.

I think that’s right - in fact, I think that on a decent development team, it’s likely that with the sum total of all of the developer’s knowledge that they could do most of the day-to-day things required to keep a server operational and get it setup. And when it comes to configuring the software and dependencies, they’re likely to be more efficient than the infrastructure guys at setting it up.  

Here’s a passing thought I just had:

Let’s say you’re building a web site that will be hosted internally. At the end of your build process, rather than giving the infrastructure guys the following artifacts:

• A link to a directory containing all of the compiled code
• A batch file that sets up all the ACLs
• A pointer to the correct configuration files they need to deploy for each environment
• A document that details the deployment process
• Phone access so they can call you in case of emergency

Your build process could just give them:

• A virtual machine with the application fully installed and ready to go

Things like ACL’s, AppPools and dependencies for libraries/runtimes would be already installed by the time you handed the VM off for testing.

This has a bunch of advantages:

• When they bring the VM on-line for the first time, they just have to run automatic updates - no other setup required.
• The application could be promoted between development, test, staging and production environments simply by mapping the correct DNS entry to the correct virtual machine.
• No downtime required - just map your DNS entries to the latest version of the VM once you’ve tested it, and when that’s done shut down the old VM
• If the deployment fails (say, there’s a security issue or a big bug), just point the DNS entries back to the previous VM. No need to restore from a backup.
• If the server becomes corrupt, contracts a virus or suddenly starts blue-screening, just roll it back to the original VM using undo disks.
• If you ever need to see what the previous version of the site looked like, you can just start up one of the old VM’s.
• If a sales guy has to take the site on the road (offline), he just has to copy the VM locally

Of course, such a system might not be very practical - it would require a lot of disk space, a lot of network bandwidth and a lot of memory to keep running. And it assumes that your application lives in a vacuum; one problem would be database access - you’d need to point to a different database for each environment, and you’d likely need to update the schema sometimes during deployment. I can’t think of a no-touch way to do that yet.

Filed under: Uncategorized