Release on-Demand

Published date: April 15, 2024, Version: 1.0

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.

The traditional Scheduled Releases approach has several disadvantages:

1. Requirement of predefined release dates and scopes:

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

2. Dependency on completion and testing of all features within the release scope:

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

3. Synchronization of releases:

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

4. Complex and time-consuming release processes:

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

5. Lengthy wait time for business feature releases:

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

6. Dependencies on pending features:

  • 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:

1. Faster time-to-live:

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

2. Eliminating release scope management:

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

3. Seamless integration of subsequent fixes:

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

4. Minimal differences between production and development versions:

  • 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.

5. Eliminating overhead from managing multiple release or hot-fix branches:

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

Enablers

1. Trunk-based branching approach:

  • 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.

2. Reliable automated quality gates:

  • 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.

3. Feature toggles:

  • 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.

4. Backward compatibility:

  • 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.

5. Decoupling deployment and release:

  • 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.

6. Loosely coupled architecture:

  • 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