Introduction
One of the key aspects of release management is how to organize and structure release phases. A release phase is a logical grouping of tasks that are part of a release. Release phases help to break down a release into manageable chunks and simplify tracking of release progress and quality. There are different ways to define and manage release phases, each with its own advantages and disadvantages - in this blog post we will compare two approaches to release management, timeline-oriented and stage-oriented, that are available using Digital Product Release (DPR).
Timeline-Oriented Release
A timeline-oriented release is a release that has predefined start and end dates for each release phase. For example, a timeline-oriented release could have the following phases and dates:
- Planning: 1st January - 15th January
- Development: 16th January - 15th February
- Testing: 16th February - 28th February
- Deployment: 1st March - 15th March
Image showing phases in a timeline oriented release
A timeline-oriented release assumes that the scope and duration of each release phase can be estimated and fixed in advance. This approach can be beneficial for the following reasons:
- It provides a clear and predictable roadmap for the release, which can help to align stakeholder expectations and commitments
- It facilitates the coordination and synchronization of the release activities across different teams and departments to occur at specified times
- It enables the measurement and monitoring of release performance and quality based on the predefined milestones and deadlines
Timeline-oriented releases are best suited for organizations that need predictable release plans and increased coordination between product teams.
Stage-Oriented Release
A stage-oriented release is a release that does not have predefined start and end dates for each release phase. Instead, a stage-oriented release has a set of criteria or conditions that determine when a release phase is completed and when the next one can start. For example, a stage-oriented release could have the following phases and criteria:
- Planning: The release scope and objectives are defined and agreed upon by the stakeholders
- Possible condition: All stories have an acceptance criterion
- Development: Release features are developed and integrated according to the release scope and objectives
- Possible condition: All stories are marked as completed
- Testing: Release features are tested and verified according to the release quality standards and expectations
- Possible condition: Quality summary report is clean
- Deployment: Release features are deployed and delivered to the customers according to the release communication and feedback plan
- Possible condition: Change is deployed to production environment
Image showing phases in a stage oriented release
A stage-oriented release assumes that the scope and duration of each release phase cannot or does not need to be estimated and fixed in advance. This approach can be beneficial for the following reasons:
- It provides a flexible and adaptive roadmap for the release, which can accommodate changes and stakeholder feedback
- It empowers the release team to make decisions and prioritize release activities based on the actual progress and value
- It potentially enhances the quality and value of a release, as it allows the release team to focus on customer needs and expectations rather than the schedule
Stage-oriented releases are best suited for teams that are only constrained by adhering to release requirement and can move at their own pace.
A quick look at how both releases approaches compare in DPR
|
Feature |
Timeline |
Stage |
|
Starting a release |
Automatically starts on release planned start date with an option to start on-demand as well. |
Manual start |
|
Release readiness target selection |
Mandatory. Calculations for planned start dates revolve around the selected readiness target. |
Optional. |
|
Retargeting a release |
Allowed |
Allowed |
|
Phase start and end dates |
Automatically generated based on template and release target |
No start and end date for phases. |
|
Restart phase |
Not allowed |
Allowed. |
|
Phase completion |
Automatically completes and moves to next phase when planned end date is met and policies are compliant (if any). |
Can be configured to automatically complete phase when policies are compliant or can be configured to be fully manual completion. |
|
Add policies on demand |
Allowed |
Allowed |
|
Run policies on demand |
Allowed |
Allowed |
|
Add tasks on demand |
Allowed |
Allowed |
|
Completing a release |
Manual |
Can be configured to auto complete. |
Conclusion
Timeline- and stage-oriented are two approaches to release phase management, and each has its pros and cons. There is no one-size-fits-all solution for release management, and the best approach depends on the context and goals of a release. Hopefully this blog helps you understand the trade-offs and implications of each approach and enables you to better choose the approach that best suits the needs and expectations of your release stakeholders.
