CO is the ability to deploy your entire development environment as rapidly as possible to a virgin workstation. As usual with other "continuous" practices (ContinuousIntegration, DailyDeployment, PairProgramming, etc.), the ability to do this is much more important than actually doing it. You force a highly useful level of control over your toolchain.

----

We used the same for development (JBoss [JbossServer], PostgreSql, Phoenix (?), TomCat). We included the setting up of the whole development environment in our ant [ApacheAnt] scripts. I.e., to setup a new development machine, you only needed to checkout the code, set some environment parameters (mostly location of checked out CVS modules) and call 'ant rebuild'. That did everything for you.

Was very useful! Not only for new development machines but also every now and then when we had some strange behavior (which could have been caused by inconsistent modules or such). You just deleted the whole build and sandbox tree and rebuilt from scratch. The easiness of this ensured that nobody added some proprietary stuff on their development machines.

Later, we extended this to WebLogic, MySQL [MySql], Oracle [OracleDatabase] and WebSphere. It was always worth figuring out how to do this through ant scripts.

-- MarkStriebeck (reposted from a mailing list)

----

I would have to agree.  This is one of the proverbial GoodThing''''s in software development.

Much of the benefit comes from defining exactly the dependencies within your deveopment environment.  This brings many of the same benefits as dependency management in code.

In three past projects we did vastly different things to provide this capability; none of them was terribly sophisticated, and most pre-date the advent of modern IDEs, but at the heart of all was the desire to be able to sit down at a new machine and quickly (or at least in a known amount of time) be ready to start "cutting code".  

In one project, the development environment was completely contained in CVS (including the JSDK and scripts to initialize environment variables), and the only "developer supplied" tool was an sh-shell to run the scripts, a command-line, and a text editor.  A key piece of automation was a set of scripts that could create any number of development/test "sandboxes" (in this case a Web/App-server and data-store) that you could easily deploy your code into.  A side benefit of this was that underneath the sandbox scripts was the production deploy code, so it got tested much more frequently than if it was only used for "real" production releases.  

A second (similar) system was in place when I worked at a Fourtune-5 company doing medical ''stuff''; everything for the development/build (including the source for gcc!) was under version/configuration management; again all the developer supplied was a workstation and text editor.  

In another, we used a Gordian solution (''see GordianKnot'') to deal with the instability and configuration difficulty of VisualAgeJava, WebSphere, Websphere Commerce Suite (''You don't want to know... In case you still do, try: http://www.google.com/search?hl=en&q=websphere+commerce+suite&btnG=Google+Search''), and Windows2000 by creating a GhostBackup of each developer's machine after a pristine install/configuration (an automatable process...).  This allowed us to quickly (over lunch, or faster) to completely reload any development machine when things started to get weird.

-GeoffSobering