Staging Environments and Release Management

Regardless of how well an application is written and the quality of the server it runs on, stability will be disappointing unless there is an efficient release management process and unless there are suitable development and staging environments. It's important to invest time upfront into establishing reliable and repeatable procedures that will be familiar to all involved before the application reaches production.

A typical web project might require three completely separate environments:

• Development environment
  This should closely mirror the Test and Production environments. Developers should be relatively free to make changes.

• Test or Staging environment
  This should mirror the Production environment as closely as possible. In particular, it should contain the same volume of data as the production environment, so that performance testing will be meaningful. Cost may rule out using exactly the same hardware as that in production. However, if deploying on a Production cluster, it's vital that Test should also be clustered, as clustering raises many issues that might otherwise only appear in Production. As load testing will usually be conducted in Test, this is another reason why it should mirror the Production hardware configuration as closely as possible. Releases to Test should require a formal release process. It is vital that Test use the same operating system as Production.

• Production environment
  The environment in which the live site runs. Developers should have no direct access to Production, and deployment into Production should be the culmination of a formal release process, after testing in the Test environment is complete.

In many sites, all developers have their own "pre-development" sandbox on their own workstation. This is often a Windows workstation, while the development and staging servers will often run a flavor of Unix. Although the use of different operating systems introduces some risk, since the JVMs cannot be identical, its benefits in productivity may make it a worthwhile approach, as developers may need to perform other tasks on their local machines that are not best served by the production operating system.

Release management is the task of ensuring that the progress of an application release through Development, Test, and Production is reversible and repeatable. It is vital that every organization develops a release management strategy accepted by all team members before application development begins. The issues addressed by a release management strategy will include:

• "Labeling" all sources in a version control system so that it's easy to extract a snapshot of the artifacts included in each release. Thus a release management strategy will be substantially based around the version control system in use.

• Deployment onto Test and Production servers. This may include rollout to a cluster of servers. Thus the application server in use – and the deployment tools it provides – is another crucial variable in practical release management.

• A rollback strategy, to ensure that if a release causes unexpected problems in Test or Production environments it is possible to roll back to the previous version of the application.

• The creation of any database tables required and the provision of data as necessary.

• Management of binary dependencies that may change between releases (for example, JAR files shipped with third-party products such as Velocity).

• The documentation required with each release.

• The sign-off process required for each release.

Important 

Successful J2EE projects depend not only on good application and application server software, but also on sound release management practices and suitable staging environments between developers' local machines and live servers. It's vital to invest sufficient time and involve all project personnel in developing a sound and workable strategy in these areas.