Structured Deployment Process

Integration is always the most difficult part of any software project. While there is no magic bullet, a strong deployment process and automated testing procedures can go a long way towards a coherent release process.

The most important single step is to move as many run-time configuration elements as possible from the compiled code to external configuration files. Application code should be constructed so that it is as generic as possible, and external files control the system elements that change from one environment to another. This allows the configuration files to be put under change control and individually deployed to each environment. Some application architectures do not lend themselves to this approach. In those cases, the team will need to branch the systems in SVN, and perform merges with the main development trunk for each deployment.

In order to build confidence that the system is of high quality, we recommend a continuous integration build process. This requires several steps:

• External Build Script - We develop a simple Ant or Nant script that can build the system without human attention
• Unit and Regression Tests – The developers should create unit tests as they develop the system, ideally using a framework such as Junit or Nunit Otherwise, a simple set of test scripts will assure us that the system builds correctly and passes minimum functionality thresholds at all times.
• Continuous Integration Server – We use the CruiseControl and CruiseControl.NET systems to check out the latest version of the code, execute our build script, execute our unit tests, and email us a report with any failures.
• Automated Regression Tests – We strongly recommend an automated regression test be developed that can run against the completed system and check for complete functionality. We use the JMeter load and regression testing tool to run standard test scripts and report results to us. This allows us to push builds to production with confidence.

With these pieces in place, it becomes much simpler to produce structured, reliable builds on demand. The system as a whole will resemble:

• Developer Workstation: This is where the developer is actively working on the code base. As part of a daily routine, the developer retrieves the latest changes to the codebase by executing an SVN Update command. When progress has been made, the developer checks in his changes with an SVN Commit.
• SVN Repository: This is the central source code repository for the system. It maintains branches (to handle alternate configurations) and tags (associated with releases).
• Continuous Integration Server: This system retrieves the latest version of the system from the repository, attempts to build it, and then executes the unit and regression tests against  the results. If the build fails, the system notifies the development team for immediate rememdiation. If the build succeeds, the unit and regression test results are sent to the team manager.
• Test Environment: The Test environment is a manual deployment for the QA team to test a new build against. The process for builds to the test environment is:
• Code is tagged within repository
• Code is checked out from repository
• Pre-build script is executed against application (to bring latest configuration files to test environment)
• Site is built
• Regression Tests are run and reported to team manager.
• Production Environment: The Production environment is publically available. The process is similar to the test environment build:
• Binary code is copied from test environment
• Prebuild script is executed against application to bring production configuration files to environment
• Regression tests run and results are reported to team manager