PMI Sites
Register
Disciplined Agile
Search

    Release Management Practices

    Some methods will choose to prescribe a single approach to Release Management, but the Disciplined Agile® (DA™) tool kit promotes an adaptive, context-sensitive strategy. DA does this via its goal-driven approach that indicates the process decision points that you need to consider, a range of techniques or strategies for you to address each decision point, and the advantages and disadvantages of each technique. Figure 1 shows the goal diagram for the release management process blade.
    Copyright Project Management Institute All Rights Reserved Release Management v5.6 Plan Release Schedule Communicate release scheduleIdentify blackout periodsIdentify release windowsManage release dependenciesSchedule as-needed releasesSchedule continuous releases (release stream)Schedule regular releases (release train) Schedule Solution Release Continuous delivery cadenceIncremental delivery cadenceInfrequent delivery Manage Infrastructure Configuration Manage software licensesTrack hardwareTrack solution dependencies Determine Production Readiness Verify solution consumabilityVerify stakeholder readinessVerify test results Support Delivery Teams Automate deploymentCoach and mentorDetermine deployment statusPlan deployment Govern Releases Audit solutionsDevelop release management metricsDevelop release policies and guidanceTrack progress

    Figure 1. The process goal diagram for release management.

    Click the diagram to open the interactive DA Browser, where you can learn more about the decision points and options of this goal.

    The process factors that you need to consider for release management are:

    • Plan release schedule. Your organization’s overall release schedule needs to be planned and communicated. Many organizations have blackout periods where teams are not allowed to deploy into production (for example, many retail organizations will not allow non-critical production releases near local holidays). There are many strategies that organizations may choose to adopt when it comes to scheduling releases, including release trains, release streams, ad-hoc releases, and release windows.
    • Schedule solution release. The release of an individual delivery team’s work needs to be scheduled so that it does not conflict with the releases of other teams who want to deploy into the same operational environment.
    • Manage infrastructure configuration. The release management team will work closely with your operations team, in fact they are often members of your operations team, to perform configuration management of your operational environment. To safely deploy into production you must know what is currently there and how those various elements depend on each other. The more complex your operational infrastructure, and the more delivery teams you have, the more important this process factor becomes.
    • Determine production readiness. Part of the release process is to verify that the solution is ready to be deployed and that the stakeholders are ready to have it deployed to them. The bigger and more infrequent your releases, the more this becomes an issue.
    • Support delivery teams. The release management team, when a separate one exists, will work closely with the delivery teams to help them deploy successfully. This help may take the form of coaching the team on deployment techniques, on planning, and even working with them to automate their deployments. The release management team will often help with deployment testing, the verification after the fact that a deployment was in fact successful.
    • Govern releases. Your organization’s overall release efforts should be governed, ideally with the aim to streamline those efforts as much as possible. This governance will include the development of policies and guidelines pertaining to the release process as well as the identification and collection of pertinent metrics. This is part of your overall governance efforts.

    It is important to note that most, if not all, of these activities can and should be automated. Automation is a key enabler of Disciplined DevOps.