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.

Release Policy and Procedures | IT Release Management

Organizations embarking on the creation of a release management practice will need to create a documented policy and procedure that resources using the process will be able to reference to understand what is expected and what processes need to be followed. The release policy defines the scope, strategy, and standards of the release practice within the organization; it is the playbook for delivering a quality, operation-ready release. The release policy should be considered a living document and will continue to be revised and improved as the release practice continues to mature and as the organization assimilates the release process. Care should be taken when creating a release policy not to include concepts and standards that cannot be implemented due to lack of organizational maturity or readiness. In the same vein, however, those concepts and standards that need to be implemented must be included within the policy. 

There is a saying that you don't want to throw the baby out with the bathwater. Organizations that have successfully or have at some level been successful in delivering releases will have some good release practices that should be retained and incorporated into the release processes being developed. The practices that have been used by the organization may not be consistent or documented. These practices should be reviewed to determine their viability and what value they provide. Once this initial assessment has been done, these existing processes can be the starting point for process development and the basis for the standards that will be documented within the release policy. This is the second part of the strategy model—Where are we now? In addition to creating a basis for the creation of standards, using existing processes in some form will lead to fewer changes and create better acceptance of the new processes being introduced.

When creating a release policy or other deliverables within the process, three questions should be continually asked:

• What value does this provide to the user?
• Who is going to use the policy?
• How is it going to be used?

We have all seen processes that appear to be meaningless and the value they bring is questionable. These processes usually break down and fail. Being able to clearly articulate the value proposition of the process will increase the adoption.

Following this approach, the first thing the release policy must address is the purpose and the value of release management. Being able to document the defined strategy and objective, the guiding mission statement, and the defined scope will set the basis for the policy. The release policy should also include the organizational context for release management; this context will define the role release management plays within the organization and the developmental process. There are three roles that release management plays within the organizational context—guidance, facilitator, and governance.

Guidance

One of the primary functions of release management is to define the release process, manage the release, and provide guidance throughout the development of the planned release cycle. In a later chapter the use of the release lifecycle (RLC) will be introduced and discussed. The release lifecycle is a systematic approach that defines and provides a roadmap of the checkpoints and deliverables that need to be produced to provide a value-added release. Consulting with design teams throughout the delivery process provides for successful releases of applications and associated hardware. Release management works closely with the project management office (PMO) to provide training for the project manager's processes and the key deliverables throughout the RLC.

Facilitator

Once the release process has been established and implemented, there will be multiple checkpoints and deliverable reviews that will take place. These reviews will be managed and conducted by the project manager with release management to ensure the required activities and tasks are being completed to ensure the release schedule is being maintained. These reviews should be focused only on release deliverables and tasks; deliverables required by the PMO should be reviewed by the PMO and excluded from this review. Release management helps to facilitate these reviews and to identify any issues or conflicts between competing releases. Release management should have an enterprise view of all releases and can facilitate a review with competing project teams to assist with the resolution of any issues arising from scheduling conflicts.

Governance

The governance role within an organization is either a role that everyone wants or no one wants. The role release management plays should be clearly defined within the organization and documented in the release policy to ensure a full understanding. Generally, governance within the release realm pertains to the tasks related to the quality delivery of the release and the ability of the organization to support and operate the service to the designed service levels. These tasks and deliverables include, but are not limited to, different levels of testing, support documentation, service level agreements, and service continuity plans. These deliverables and tasks should be right sized for the specific release and described in the RLC.

Another governance role release management can play is in the area of regulatory compliance. In every industry and in every country there are specific regulations that need to be met, whether it is Sarbanes—Oxley Act (SOX), Health Insurance Portability and Accountability Act (HIPAA), Federal Deposit Insurance Corporation (FDIC), or JSOX, the Japanese version of SOX, just to name a few, and the release process can be designed to assist in complying with these regulations. How this can be done will be covered further in the release lifecycle.

Release Standards

The release policy and procedure document should also provide direction on standards and guidelines that need to be followed. The guidelines described in the release policy need to be created to ensure that release development aligns with the goals and objectives of the organization. The document should be generic enough so that it doesn't have to be revised frequently, but specific enough to provide the user enough information to use the process. These standards, guidelines, and policies must be created to fit the organization where they are being used. Many generic standards and definitions can be found in various publications; however, to be successful they must be tailored to the specific organization. The concept of the release lifecycle, which was introduced earlier in this chapter, will help development teams understand and use the standards, policies, and guidelines documented in the release policy.

Basic Concepts

The basic concepts of release management should be incorporated into the release policy. However, before they can be included in the policy, the concepts need to be customized to fit the specific organization. A basic understanding of these generic concepts is needed:

• Release models
• Release schedules
• Naming conventions