Release Models | Release Policy and Procedures

Being able to classify and categorize different types of releases into release models allows one to determine the types of governance and review that should be completed. It also provides for the right sizing of release structure, deliverables, and promotion and implementation methods for the release. Release models also provide the organization with a common language and provide a connection to the project management methodology.

While there are many considerations in developing release models, one of the basic considerations is what Configuration Items (CIs) or parts of the IT service should be released together. Being able to determine the dependencies between CIs within the IT service will determine what parts of the IT service need to be released together and understanding these relationships define the release unit. As illustrated in Figure 1, release units can be as small as a single module or as large as the entire IT service. These different types of release units can be separated into three categories: delta, full, and package.

 Figure 1: Release units.

• Delta release —A basic release unit that usually includes a small number of modules or components of the IT service that have changed since the last full or delta release.
• Full release —A release that is comprised of several components of an IT service and may include several delta releases. All of the components are built, tested, and implemented together.
• Package release —When several releases are grouped and implemented together, a package release can be comprised of a full release and delta releases.

Another consideration in creating release models is release type. Release types describe the complexity of the actual change or release being implemented. The generic description of release types are: minor, major, and emergency. Organizations should look at their existing methodology to determine if release categorizations already exist. If so, then consideration should be given to using the existing naming convention. Using existing naming conventions will improve the acceptance of the release methodology. Generic release types are relatively easy to define.

• Minor release —Consists of small enhancements and fixes; some minor releases may have been completed as emergency releases. Minor releases will supersede all previous emergency releases. More frequently done than major releases, minor releases can range from once a month to quarterly.
• Major release —Contains significant or large portions of new functionality, major upgrades, or new service implementations. Major releases will super-sede all minor and emergency releases. Less frequent and requires significant planning and lead times. These are usually done only once a year.
• Emergency release —This type of release is done in response to an incident or significant problem and may be related to the emergency change process. Typically the release is small and similar in nature to a minor release, but is completed in much less time.

Examples of organization-specific release types could include categorizations such as projects and system enhancements rather than major and minor releases. If an organization has classified their release types this way, then this naming convention can be used.

Deployment Considerations

An additional consideration for a release model is the deployment options for the release. The type of deployment model used is dependent on many factors, such as complexity of the release, the impact the implementation will have on business operations, and resource allocation needed for implementation. When deciding which type of deployment model to use, a risk assessment should be done to determine which model presents the least acceptable risk. The various deployment models range from a big bang approach to a phased approach.

• Big bang deployment —The big bang model is the riskiest deployment strategy. It is simply implementing the release all at one time for all locations and all users. This presents the greatest risk as it is all or nothing. If issues occur with the release deployment it affects all users in all locations.
• Phased deployment —The phased model still has risk associated with the deployment, however, not as great as the big bang model. The phased deployment model involves creating specific groups of users and deploying the release to each of the groups in a sequential order. The deployment groups can be grouped by types of users, location, or function. A phased deployment can be done over an extended period of time or over a shot period.
• Phased parallel deployment —This approach is a variation on the phased deployment mode. The difference is the running of parallel systems during the deployment period. In other words, the legacy system continues to function and the new system is deployed in parallel. This is the most complex approach since there are two systems running, performing the same service. Both systems have to be supported and maintained.
• Pilot deployment —The pilot deployment model presents the least risk of the deployment models. In this approach a pilot group is identified and the release is deployed to this group for a specified period of time. During this period of time, the release is monitored closely to ensure the release is successful and addresses any issues that arise. A modified approach is to start with a small alpha group, expand to a larger beta group, and then deploy the release to the targeted group.

The deployment model utilized needs to be considered carefully to ensure the appropriate risk matches the complexity of the release and the risk the organization is willing to accept.