Release and Deployment

Plan, schedule and transition services into a live operational environment.

The purpose of Release and deployment management is to plan, schedule and control the build, test and deployment of releases, and to deliver the new functionality required by the business while protecting the integrity of existing services. A release is a set of changes which are authorized for implementation into an IT service.


Release Types:

  • Major releases: It is a type of release which contains new hardware or software
  • Minor releases: It is a type of release which makes significant improvements to the existing functions.
  • Emergency releases: It is a type of release which is a quick fix to an emergency problem


Release and Deployment objectives:

  • To define and agree to the plans made for release and deployment management.
  • To create and test the release packages, store it in a definitive media library (DML) and record it in the CMS.
  • To deploy the release packages as per the agreed plan from the definitive media library.
  • To make sure that the organization and the stakeholder involved are effectively managed.
  • To ensure that the services which are new and changed can deliver the agreed upon utility and warranty.
  • To make sure that there is an adequate transfer of knowledge to the users, customers, and the IT department.


Release and Deployment Management Phases:

  • Release & Deployment Planning: Where an organization should compile their plans to release and deploy their service/software. In this stage, the change management team authorizes both the plan and the creation of a release.
  • Release Build & Test: Where the Release Package is built, tested, and checked into the DML. Meticulous records of different builds must be documented within the DML to maintain governance over the release and deployment process. Again, the change management team is responsible for authorizing the release to be built and tested. This process is intimately related to the change management process due to the nature of making these authorized changes to new/operational services. It’s imperative that the change management team is kept in the loop.
  • Deployment: The Release Package is deployed into live operation. At this stage, the change management team authorizes its deployment into one or more target environments prior to handing the package over to the Service Operations.
  • Review and Close: Review the experience and feedback of the service to compare to the performance targets/achievements outlined in the R&D Planning phase. This where an organization learns from its operations to streamline operation and service delivery. Organizations should constantly evaluate and reevaluate their efforts to maintain continuous service improvement processes. It’s at this stage that most organizations can develop their knowledge base and make suggestions for changes/improvements for the change management to review prior to the cycle repeating itself. In this way, an organization should constantly be growing in terms of the lessons learned throughout the Release & Deployment Management Process.


Documentation:

If your goal is to have potentially shippable software every sprint, or better yet to have a potentially consumable solution every iteration, then you will need to keep your deliverable documentation in sync with your software/solution -- in other words, write deliverable documentation continuously throughout the project.

Agile software is built in iterations, as the team learns from their users what are the most valuable functionalities that are expected. As such, documentation must wait for the stabilization of the information, but not delay so much as to miss out on the opportunity to capture the knowledge as it is being digested. With the passage of time the team will face other challenges and may forget details of what was constructed in each iteration.

Continuous documentation attempts to capture the iteration's knowledge as it is solidified into a deliverable. Teams may choose to capture during each sprint, after a sprint is completed, or as epics are completed. The choice of the team depends on its composition, delivery cadence, maturity and other aspects - but documentation must be captured as the project matures.