logo for information-management-architect.com
leftimage for information-management-architect.com

Release Plan

Improve deployment process with David Bowman’s information management guidelines for data warehouse release plan

This site is designed for Information Technology professionals who need to improve deployment process and require guidance and direction to help teams consistently produce error free results.

It provides a checklist of information management guidelines for release planning.

What is a Software Release?

Deploying a release into the production environment involves risks to the availability and reliability of that environment.

All stakeholders need to be aware of the potential risks involved in the deployment.

Recognizing this, a release manager should ensure that the appropriate managers agree on and sign off on a release plan before the release moves into the design and build phase.

Release Planning
  • Should specify release objectives, roles, responsibilities; tasks, activities and deliverables, communication and training plans; and release schedule;
  • Should review the change request with stakeholders to ensure full understanding of the nature/magnitude of the change and which components and services need to be changed in order to implement it;
  • Should decide how to release those changes into production e.g. it may be appropriate to treat the change request as a simple single-release project, with its own project plan and allocated resources or it may be beneficial to combine the changes from one or more change requests to form a more complex release package especially if the Change Requests make different changes to the same production components and services. Making changes in this manner can often help reduce downtime and improve the use of resources available to the release manager;
  • Should determine the contents of a release;
  • Should assign a release number to the release;
  • Should plan and schedule activities e.g. the release manager should define release tasks/activities required to deploy the release into the production environment e.g. for small or well-understood releases, a release plan should contain all of the tasks and activities required to deploy the release into the production environment and for large and complex releases, the release plan may contain a number of tasks that simply indicate the duration and owner of a particular phase or stage, with the owner responsible for creating and obtaining resources for a roll out plan to deliver that part of the release; and
  • Should determine release team composition and roles e.g. for small releases, the release manager may be the only individual required to deploy them into production but for more complex releases, the release manager may need to assemble a release team to carry out certain tasks and activities of the release plan, or the release manager may appoint phase, or roll out, managers to manage a specific part of the release process.
Release Plan
  • Should identify and describe the type of training required, when the training is required, how the training will be provided, and the reasons for providing it;
  • Should provide a detailed estimate of cost;
  • Should  identify how the service desk and support team will support the release;
  • Should identify the what, where, when, and how change communications will be handled;
  • Should provide an estimate of any required equipment costs and explain how existing equipment will be reused, if appropriate, to minimize cost e.g. in some cases, the release manager may need to provide an indication of when new equipment should be ordered and purchased, where it is to be stored prior to deployment, and how it should be moved from one location to another;
  • Should identify release order e.g. the release team may find that business requirements and priorities change during the course of release development and it might be necessary to change aspects of the release plan or the deployment order in response to these changes as the release progresses;
  • Should initiate a meeting of the change management team to secure approval for the release plan so that the release can proceed to the next phase of the release management process; and
  • Should place copy of release plan in the change management documentation folder.   
Build Release
  • Should select a suitable release mechanism for the change that is a strategic fit, is repeatable, and is consistent e.g. most data warehouse releases will involve new data base structures, new data integration feeds and/or new business intelligence components,  however, some releases may involve new infrastructure such as new versions of MicroStrategy, Informatica, Erwin, Model Mart or other infrastructure software components etc. The release team should aim to deploy each release by using a mechanism that allows it to automate as much of the process as possible since this ensures repeatability and consistency;
  • Should design and build a release package for the change that allows it to be successfully deployed e.g. the release team should develop the procedures, tools, and technologies necessary to deploy the release into production using the selected mechanism and to remove it from production should that become necessary;
  • Should create test cases e.g. the test coordinator should create test cases, as specified in the test plan, showing expected results of each test;
  • Should test that the release package delivers the change effectively in line with requirements; and
  • Should update the configuration management database with appropriate release documentation.
Release Testing
  • Should test the release process to ensure that all components can be migrated correctly;
  • Should test user functionality to ensure that the release meets user specified requirements;
  • Should perform controlled pilot testing in the production environment where necessary; and
  • Should evaluate acceptance testing results to make a confident decision to move toward release preparation.
Release Testing Process
  • Should use the release test environment for release testing purposes. In some instances, it may be necessary to build a new test environment e.g. to permit testing of a new micro strategy release. If this is required, the release manager should appoint a test manager to oversee the creation of the test facility and to monitor and control all activities that take place within it;
  • Should coordinate the execution of test cases as specified in the release test plan e.g. for most releases, key functionality tests include proving the effectiveness of back-out and recovery procedures;
  • Should review test results with the release manager, change manager, and change owner to determine if the release should proceed for deployment;
  • Should additional change requests, if necessary, to make the release work as planned;
  • Should update the change log with any other supporting information;
  • Should document test results and verify them against expected results; and
  • should investigate failures encountered during testing to determine if the failure is acceptable or if components in the release or release package need to be reworked.
Release Preparation Process
  • Should ensure that adequate resources, as specified in the release plan, are available for deployment of the release;
  • Should ensure that release communications plans have been executed;
  • Should ensure all training has been completed;
  • Should confirm the production environment readiness for receiving the release;
  • Should review the preparation of the release for deployment into the production environment; and
  • Should ensure all related changes have been handled by the change management process.
Release Deployment
  • Should involve the physical migration of objects into the production environment using the procedures defined in the Release Package and release plan;
  • Should only occur if the Change Management Team authorizes readiness;
  • Should submit the Release Package to the appropriate team members for execution; and
  • Should execute the back-out plan specified in the release package If errors occur during execution of release deployment
Release Monitoring
  • Should determine if any infrastructure technical or capacity issues occurred during the change;
  • Should determine if any operational issues occurred during and after the change;
  • Should determine if there any third-party e.g. supplier issues with the change;
  • Should determine if any security issues became apparent with the change;
  • Should determine if any supportability issues became evident during or after the change;
  • Should determine if any service levels were breached during or after the change;
  • Should determine if any infrastructure technical or capacity issues occurred during the change;
  • Should determine if any operational issues occurred during and after the change;
  • Should determine if there any third-party e.g. supplier issues with the change;
  • Should determine if any security issues became apparent with the change;
  • Should determine if any supportability issues became evident during or after the change;
  • Should determine if any service levels were breached during or after the change;
  • Should review lessons learned from the deployment and document them for future benefit;
  • Should deal with unsuccessful change implementations by backing out, considering further remedial changes, or using the “accept issues and continue” policy; and
  • Should close successful change requests  and inform the initiator.
Back Out Changes

If the change has not met the objectives, then the Change Management team should decide what, if anything, should be done.
  • Should determine if the change has not met the objectives, and if not, should create additional Change Requests to remedy the issue;
  • Should determine what action to take if the change has not met  objectives e.g. the change management team may decide to accept the issues and continue with production. If this occurs, the change log is updated to reflect the decision and the Change Request is closed;
  • Should consider the amount of effort required to perform the back out;
  • Should consider the effect it might have on other (either planned or already deployed) changes;
  • Should consider the possibility that users are already using the changed production environment, although not to the best effect, and removing some functionality that the users have become used to may be worse than leaving it as is; and
  • Should consider if back out is required, which defined release back out plan should be executed
Post-Implementation Review
  • Should be convened soon as practical after a release has been deployed;
  • Should review and address any significant items identified during the monitoring period e.g. the Change Management Team might decide to close successful changes, to back-out changes, to create additional change requests to address issues; or to accept issues and continue with production.

Close Successful Changes
  • Should notify the Change Manager that the Release has been closed.;
  • Should update the Change Request;
  • Should notify the Change Initiator; and
  • Should update the change request to the change management documentation repository.
Summary...

Deploying a release into the production environment involves risks to the availability and reliability of that environment.

All stakeholders need to be aware of the potential risks involved in the deployment.

This site provided a checklist of information management guidelines for release planning,