Continuous Integration

Agile Methodologies demand frequent deliveries in short cycles. It's desirable to fully automate the mundane process to checkout latest code, build, deploy, test, and send out notification on errors. Continuous Integration (CI) come into the play. There are some other significant benefits to adopt a CI tool:

• A fully automated process will improve the quality standard for build processes. You don't need to worry about scenarios when the code works on programerA's environment, but not programerB's.
  
• Code quality will be improved. For a large project with many programmers, it is inevitable to accidentally check in uncompilable code. You can count on the CI tool as a safety net to catch the errors before they pollute the whole team's working environments. To be specifically, the CI tool can be configured to check out code every 15 or 30 minutes, catch the error, and send out notifications accordingly.
  

You may have vivid memory how frustrated you were when hours of debugging work only pointed to non-reliable build process or non-stable code repository. So you cannot wait to try out a CI tool. Amazingly the efforts needed are trivial. You may only need a hardware, an open source CI tool, and some configuration work. For the hardware, you need a dedicated box to do the CI work exclusively. For the software, there are several major players on the CI arena, for example, Hudson, Cruise Control and Continuum. Java World has a good article to compare them: http://www.javaworld.com/javaworld/jw-11-2006/jw-1101-ci.html

Most configuration work is easy if you are familiar with build scripts like Maven or Ant. It may be a little bit challenging to configure those scripts to be environment-agnostic. You may wish to put all environment-specific variables into a configuration file, which includes, directory locations, database connection strings, external system URL's and etc.