Release on-Demand

Overview

The Release On-Demand Capability refers to the ability to deploy frequent updates to production, regardless of whether all functionalities are fully developed. For instance, this can involve daily deployments. It serves as an alternative to the traditional approach of scheduled releases, where changes are accumulated over a period (e.g., a couple of months), tested as a fixed set, and then released.

Quick Links

Access Checklists Visibility of Work in the Value Stream Change Management Onboarding a New Team Member

The traditional Scheduled Releases approach has several disadvantages:

It can be challenging for businesses that lack fixed priorities to determine release dates and scope across all affected components in the coming months.

Managing multiple components and teams in large solutions becomes difficult, as delays or incomplete tasks require rescheduling the entire release.

Coordinating releases across different components and teams adds complexity and potential synchronization issues.

Large releases often involve intricate steps, prolonged downtime, and challenging roll-back procedures in case of failures.

Even minor changes can take significant time to reach production due to the scheduled release cycle.

Development and release of functionalities that depend on features pending in previous releases become challenging, even if those features belong to different teams or components.

In contrast, the Release On-Demand approach aims to address these disadvantages and offers the following benefits:

Once code passes quality assurance (QA), it can be deployed to production during the next deployment cycle, often within a day.

Everything in the development trunk can be deployed without explicitly defining release scopes or tracking task completion.

Any fixes following the initial deployment can be included in the next deployment cycle without hot-fixing.

The time gap between the latest and production versions are significantly reduced, making it easier to develop and build new features that depend on previous ones.

The complexity associated with maintaining multiple release or hot-fix branches is avoided, streamlining the development and release processes.

Enablers

Each component maintains a trunk branch and short-lived feature branches, typically lasting only a few days. Developers frequently merge changes without relying on long-lasting branches.

QA automation extensively covers most use cases. Automated tests accompany new features, following a Behavior-Driven Development (BDD) approach. Regular testing executions on the QA environment, such as daily tests, demonstrate the stability of the Trunk branch. Passing the automated tests is sufficient to promote this version to production, following business review and approval, without the need for extensive manual testing over multiple days.

The ability to deploy versions with partially completed functionality is enabled by feature toggles. This allows specific features to be turned off and turned on in real-time in the production environment without requiring a new code deployment.

When a feature depends on multiple integrated components, backward compatibility allows changes to be deployed for one component, even if changes for another component are not yet ready. The unaffected piece retains its previous behavior until the necessary changes are deployed, at which point it switches to the new behavior. This decoupling of deployments enables components to be deployed independently without requiring simultaneous deployments.

Frequent deployments of the latest stable version from the Trunk branch become possible without aligning them with specific business feature releases. On the desired release date, managers can enable features on the production environment without needing another version deployment, leveraging the Feature Toggle solution.

Components are developed, tested, and deployed independently, thanks to a loosely coupled architecture. Integrations between components are covered by contract testing, ensuring compatibility and minimizing dependencies.

By introducing and implementing these capabilities collectively, organizations can achieve the Release On-Demand capability, enabling frequent deployments of the latest stable version while offering flexibility, reliability, and reduced time-to-market for new features.

Adoption expectations

System Components	MVP	MVP+
Trunk based branching approach	+	+
Automated quality gates	+	+
Feature toggle	+	+
Contract testing	+	+
Decouple deployment and release	+	+
Backwards compatibility		+
Loosely coupled architecture		+
BDD approach for new features		+

Tools

Functionality	Tool Name
Version Control System	Git
CI/CD tools	Azure DevOps, Jenkins, GitHub Actions
Test Automation	JUnit, NUnit, Rest Assured, Selenium
Artifact Management System	JFrog Artifactory, Azure Artifacts, Azure Container Registry
Documentation Collaboration	Atlassian Confluence
Contract Testing	PACT
Architecture design tools	Microsoft Visio, Draw.io, Miro, Lucidchart, Archi

Roles

Name	Responsibilities
Scrum Master/Team Coach	Coach and support usage of the best engineering practices to support release on demand
Solution Architect	Design solution in a way to allow easy components and feature decoupling
System Architect	Design systems in a way to allow easy components and feature decoupling
Product Owner	Define scope and provide acceptance of new features on the earliest stages of the process
Developer	Adopt practices to develop new changes in a small easy to test steps
Build Engineer	Integrate automated quality gates and deployment process
Test Automation Engineer (TAE)	Implement automated tests in advance allowing continuous testing process