There are IT departments that can release code directly into production, but they are few and far between. Unless a development team is small, agile, excellent at communication, and the impact of defects is low, a formal release management process should be used.

What is Release Management?

Release management is the mechanics by which new applications, or modifications to existing ones, are moved into the production environment. Releases, like any change to the IT production environment, are governed by the change management process in that a release can only go into production if it has been approved by the change manager. For more information on change management, refer to the Info-Tech Advisor research note, “Keep Production Environments Safe with Solid IT Change Management.”

Figure 1. Release Management Process

Source: Info-Tech Research Group

The major steps in the process are depicted in Figure 1. Release Management begins with a plan for the release – the enhancements, fixes, or other changes that will be included and who will implement them. The plan is then communicated to the developers for completion. All the changes are built and configured to form the release which is handed over to the QA team for testing. If any change in the release is not accepted, the necessary source files are rolled back to the previous accepted version and a new release is built. Once the release is accepted, training communicates the planned changes to end users. Finally, the release is implemented into the production environment.

Seven Steps to Release Management Implementation

1. Lock down production environment. Access to the production environment must be controlled; it should not be possible for everyone to make modifications to the files in production. Implement some form of security around the environment that gives full access to only a few, authorized people.
2. Designate a Release Manager. At least one person needs to become an expert on the process and ensure compliance. This person is responsible for:
   • Training team members.
   • Building and configuring the releases.
   • Migrating them to the different environments.
   • Performing rollbacks.
   • Communicating the details of the release to other departments.
   • Documenting the release.
3. Configure separate development environments. Development changes should not be moved directly from the developer’s environment to production. For more information on unnecessary multiple logical environments, refer to the Info-Tech Advisor research note, “Save Money: Cut the Number of Logical Application Environments.”

Set up at least the following logical application environments to safeguard against introducing defects into production:

• Local development: Release development is done locally by each developer. All developer environments should be configured with the exact same versions of operating systems, tools, and IDE.
• Quality Assurance: Releases are moved to this environment for formal testing by the QA department. This environment should be regularly updated with production data for accurate test results.
• Deployment: Here, final system testing occurs to ensure releases that have been approved do not cause any unexpected issues once implemented in production. This environment should mimic the production environment in terms of network configuration, software versions, installed hardware, and data.

4. Manage versions of software configuration. Release defects are inevitable when source files are stored on multiple servers in various directories and there isn’t a clear indicator of the most recent version. A configuration management tool provides the following benefits:
   • Stores all source files in a single, centralized location.
   • Saves multiple versions of a file for easy rollback and change tracking.
   • Allows developers to access the latest version of a file, view its change history, and check it out for exclusive editing privileges.
   • Regulates source file change commenting. It can be configured so that developers must document their changes to the file.
   • Supports file merging and release designation.
5. Develop a rollback policy. If it is decided that a set of changes are not going to be included in the release, then the changed files need to be reverted back to the last accepted version. Develop a policy that defines:
   • The parameters for rolling back a source file.
   • Deadline for rolling back source files to ensure release deadline.
   • What needs to occur after the rollback to ensure the quality of the release.
6. Include formal testing. Testing should not be limited to that done by the developer. Testing should be both manual and automated and include formal unit testing, functional testing, full regression testing (to ensure that other systems are not adversely affected by the release), and system testing on the deployment environment. For more information on application testing, refer to the Info-Tech Advisor In-Depth Report, “ Application Software Testing: An IT Manager's Guide.”
7. Define documentation standards. Documenting the changes related to a release guarantees relevant information is available to others besides the developer. Documentation should describe both the how and the why of each change, the person responsible for the change, and when the change was implemented.

Bottom Line

A release management process ensures that changes released into the production environment are stable. Application changes are not released directly into production; instead they go through a series of checks and balances to confirm quality and correctness. Follow these seven steps to implement a disciplined release management process.