Release Plan

• Release objectives;
• Roles, responsibilities;
• Tasks, activities;
• Deliverables;
• Communication and training plans; and
• Release schedule.

• 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.
• 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. 
• Determine the contents of a release,
  
• Assign a Release Number to the release.
• Plan and Schedule Activities. The release manager should define release tasks/activities required to deploy the release into the production environment.

• Determine Release Team Composition and Roles. For small releases, the release manager may be the only individual required to deploy them into production.

• Create Release Plan. 
• Identify Training requirements. The release manager is responsible for identifying and describing the type of training required, when the training is required, how the training will be provided, and the reasons for providing it. A detailed estimate of cost may also be required.
• Identify Support Requirements. The release manager should identify and document how the service desk and support team will support the release;
• Identify Communications Requirements. The release manager and the communications coordinator should decide the what, where, when,  and how change communications will be handled.
• Identify Release Logistics. It may be necessary to provide an estimate of the equipment costs and explain how existing equipment will be reused (if appropriate) to minimize cost. 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.
  
• Identify Release order. 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.
  
• Secure Approval For Release Delivery Plan. The Release Manager shall initiate a meeting of the change management team to secure approval for the Release Delivery Plan so that the release can proceed to the next phase of the release management process; and
• Place copy of Release Delivery Plan in the change management documentation folder.   
  

• Selects a suitable release mechanism for the change that is a strategic fit, is repeatable, and is consistent;
  
• Designs and builds a release package for the change that allows it to be successfully deployed;
  
• Tests that the release package delivers the change effectively in line with requirements; and
• Updates the configuration management database with appropriate release documentation as specified in the release plan.
  

• Select Release Mechanism. Most information management releases will involve new data base structures, new ETL feeds and/or  new business intelligence components. However, some releases may involve new infrastructure such as new versions of micro strategy, 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. 
• Design Release Package. 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.
• Build Release Package. The  release team should create a Release Package  documenting the manual processes and procedures required to deploy the release into production (or remove it as necessary) The documentation should include details of how to monitor and check the effectiveness of the release and how to recognize and react to problems.
  
• Create Test Cases. The Test Coordinator should create test cases, as specified in the test plan, showing expected results of each test.
• Update Configuration Management Database. The Release Team should  update appropriate sections of the Configuration Management Data Base.

• Tests the release process to ensure that all components can be migrated correctly;
• Tests the user functionality to ensure that the release meets user specified requirements;
• Performs controlled pilot testing in the production environment where necessary; and
• Evaluates acceptance testing results to make a confident decision to move toward release preparation.

• Design and Build Test Environment. The release process will normally 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.
  
• Conduct Tests and document Results. The test coordinator should coordinate the execution of test cases as specified in the release test plan.
  For most releases, key functionality tests include proving the effectiveness of back-out and recovery procedures.
  
• Obtain Acceptance to Proceed. The Test Coordinator should review test results with the Release Manager, Change manager, and Change Owner to determine if the release should proceed for deployment.
• In some cases, additional Change Requests may need to be created to make the release work as planned. In either case, the change log needs to be updated with the decision and any other supporting information.
• As each test is completed, the results are documented and verified against the expected results.
  
• Failures encountered during testing should be investigated and evaluated to determine if the failure is acceptable or if components in the release or release package need to be reworked.

• Ensures that adequate resources, as specified in the release plan, are available for deployment of the release;
• Ensures that release communications plans have been executed;
• Ensures all training has been completed;
• Confirms the production environment readiness for receiving the release;
• Reviews the preparation of the release for deployment into the production environment; and
• Ensures all related changes have been handled by the change management process.

• Mobilize resources. The release manager should confirm that the resources needed to deploy the release are available.
  
• Execute Communications Plan.The Communications Coordinator shall execute the communications plan defined in the Release Delivery Plan.
• Conduct Training. The Training Coordinator shall conduct the training defined in the Release Delivery Plan.
  
• Prepare Production Environment. Most releases will not require changes to the current production environment and hence will be deployed with no additional preparation. Some, e.g. upgrades to  infrastructure e.g. hardware, micro strategy, Informatica, data base management system may require changes for the deployment of a release.  The release manager should ensure that the production environment is ready to accept the release.
• Conduct Release Readiness Review. The Release Manager and Change Owner should convene a meeting of the Change Management Team to review the status of the release plan to determine if the release should proceed to deployment or if it should be suspended or canceled. This review should focus on the following key factors:
• Are the release management processes completed?
• Are the required resources available?; and
• Is the production environment ready?

• Deploy Release. The Release Manager should submit the Release Package to the appropriate team members for execution; and
• Back-Out Release. If errors occur during execution of release deployment, the back-out plan specified in the release package should be executed.

• Monitors  change after implementation into production;
• Reviews lessons learned from the deployment and documents them for future benefit;
• Deals with unsuccessful change implementations by backing out, considering further remedial changes, or using the “accept issues and continue” policy; and
• Closes successful Change Requests  and informs the initiator.

• Monitoring Change in Production Environment.  Key stakeholders should  monitor the change and report observations; Key areas of concern include:
• Infrastructure     Did any technical or capacity issues occur during the change?
• Operations     Did any operational issues occur during and after the change?
  
• 3rd Party        Were there any third-party e.g. supplier issues with the change?
• Release        How did the change progress through the change management process and where can lessons be learned?
• Security        Did any security issues become apparent with the change?
• Support        Were any supportability issues evident during or after the change?
• Service        Were any service levels breached during or after the change? 

• Conduct Post-Implementation Review. The release manager is responsible for convening a post implementation review meeting as soon as practical after a release has been deployed. Any  significant items identified during the monitoring period should be reviewed and addressed. The Change Management Team should 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. The Release Manager should notify the Change Manager that the Release has been closed. The Change Manager should:
• Update the Change Request;
• Notify the Change Initiator; and
• Add the updated Change Request to the change management documentation repository
  

• Back Out Changes. If the change has not met the objectives, then the Change Management team should  decide what, if anything should be done. The CMT shall consider issues such as:
• The amount of effort required to perform the back out;
• The effect it might have on other (either planned or already deployed) changes; and
• 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.
  
• If back out is required, the defined release back out plan should be executed.

• Submit Additional Change Requests.   If the change has not met the objectives, the CMT may decide to create additional Change Requests to remedy the issue. If this occurs, the entire Change Request process starts again.

• Accept Issues and Continue.   If the change has not met the objectives, the CMT may decide to accept the issues and continue with production. If this occurs, the change log is updated to reflect the CMT decision and the Change Request is closed.