Presentation on theme: "Release & Deployment ITIL Version 3"— Presentation transcript:
1 Release & Deployment ITIL Version 3 Process Definition Document OverviewITIL Version 3
2 Purpose of DocumentThis document defines the standard MN.IT roles and responsibilities for managing release and deployment of normal change to an IT managed system or service.The audience for this document is MN.IT employees and anyone wishing to understand ITIL v.3 release and deployment processes.
3 Document Scope This includes prescribed activities, roles, metrics, and other requirements to be used by MN.ITEach team may define additional rigor or otheraspects to Release and Deployment, as long asthey fit within the team’s adherence to ITIL v.3 concepts and principles.
4 High-Level Process Description Release and deployment management is the process to Plan, Build, Test and Implement the capability specified by the service design.That service design accomplishes the stakeholders’ requirements and delivers value to the business unit.
5 Purpose and Objectives To define and agree upon release policies, and plans with customers and stakeholders.To ensure the integrity of constructed packages and that all changes are accurately recorded in the Configuration Management System.To ensure that all release packages can be tracked, installed, verified, and uninstalled if necessary.To ensure the required skills and knowledge are transferred to customers, end users and stakeholders.With minimal impact to the live production environment
6 Process FlowRelease and Deployment management encompasses nine high-level processes
7 PlanningDuring this step, a plan is created to identify the activities and the resources required to successfully deploy a release.For each of the additional eight steps that are part of release and deployment an initial plan needs to take place to ensure that all levels of construction are understood, and all risks relating to people, software, and hardware is minimized.
9 Preparation: Building – Testing - Deployment Ensure that each release package consists of a set of related assets and service components that are compatible with the future updates.In addition, review all past service level agreements, underpinning contracts, operational level agreements, and policy statements that apply to this project.
12 Building and TestingBuild and test planning establishes the approach to building, testing and maintaining the controlled environment prior to going live.The build and test plan must work with service validation and testing to ensure that test plans can be carried out.
14 Service Testing and Pilots This test aims to build confidence in the service capability prior to final acceptance during pilot and early life support.It will be based on the test strategy and model for the service being changed.
16 Preparing the Deployment The major tasks for preparation for deploymentAssembling resourcesCommunications plan for release to Users, StakeholdersTraining sub-process for supporting staffScheduling support for the deploymentCompleting a readiness review
18 Release DeploymentThe release and deployment manager will provided status reports and tools to track deployment progress.Once the release is deployed, the release manager confirms that it is working correctly before proceeding with further deployments.
20 Verify DeploymentDuring this step, the release and deployment manager confirms that the release is working correctly and documents feedback from business users ,stakeholders and deployment team.If the release fails to meet expectations, issue management may need to identify and diagnose the root cause of the problem. If the fix is found, this should be documented and an RFC created to deploy it into production
22 Early Life SupportEnsure that there is knowledge transfer to enable the customers and users can optimize their use of the new service.Project and implementation resources work hand in hand with support staff to ensure implementation objectives are met and the application or service is working as planned.
24 Review and CloseRequirements and guidelines for review and close: Review the plan, Review the nine steps, and document issues and workarounds.This should ensure that skills and knowledge are transferred to users and support staff. Enabling them to effectively and efficiently deliver the service into the future.
26 Roles and Responsibilities Release and Deployment Manager - Is responsible for the planning, building, testing and implementation of all software and hardware releases.Build and Test Coordinator - Establishes the final release configuration and coordinates all tests/builds.Deployment Staff - Deals with building the release, and final physical delivery.Early Life Support Coordinator - Provides IT service and business functional support from early release to final acceptance.Communications Coordinator - Builds a dynamic communication channel – between Stakeholders, Managers, Staff and Development Team, keeping all informed.
27 Roles and Responsibilities Matrix The RACI shows the relationships between the participants in Change Management, and the various activities within each stage of the release and deployment process.R = Responsible – People expected to actively participate in the activity.A = Accountable – The person who is ultimately responsible for the results.C = Consulted – People with expertise or who must be consulted before a final decision is made.I = Informed – People who are affected by the activity/decision.
28 Release and Deployment Management Standards 1Does the change request have the right approval?2Has planning for deployment been properly executed i.e. defining scope, contents, risk, responsibilities, stakeholders, etc.?3Have the issues or risks identified been prioritized and actions taken to resolve them?4Have the proper configuration level at which building and testing can take place been identified?5Have the test environment been properly configured to support the level of tests and pilots needed for the release?6Is the deployment team ready for the deployment i.e. have they properly prepare the production environment, has potential risks been mapped out, are they sufficiently trained, have they communicated release plans to users, etc.?7Was the deployment successful or failed i.e. did deployment goes as planned, have users been trained, has proper documentations been distributed, etc.? If deployment failed, has root cause been identified and did the back out procedures remove the release from production?8Can users, stakeholders, service operations, and other staff able to use the release as intended? Has feedback been collected?9Are any extra support needed after deployment to help stabilized the service?10Have the release been properly reviewed and closed i.e. have the skills and knowledge been transferred to operation and support staff to adequately perform the service?
29 Key Release and Deployment Management Guidelines 1All change requests need proper approval before they can be release into production.2When starting any release and deployment make sure adequate planning is done to ensure scope, content, risks, responsibilities, stakeholders, etc are properly defined.3All identified risks and issues must be prioritized and the proper action taken to resolve them.4All releases should be properly tested in a configured test environment that supports various levels of testing and pilots.5All releases in production should be reviewed if they were successful or not. If release was not successful, proper action should be established to roll back release and identify root cause.6All deployment activities that have been completed should be verified that all the users, service operations, other staff and stakeholders are able to use the service as intended.7Deployment should be reviewed and closed.