Skip to main content
All Posts By

CD Foundation

Aug 01
Love0
Release on Demand

How to Shift from Fixed to On-Demand Release Cadence

By Blog, Community

Contributed by: Ajashe Nwapa, CDF Ambassador | Originally posted on medium.com

Release on Demand

As digital transformation picks up speed, organisations face mounting pressure to release software more frequently, with less risk and more business responsiveness. Traditional release schedules — monthly, quarterly, or biannual — often fall short. They don’t reflect how teams actually deliver value or how quickly priorities change.

Release on Demand (RoD) is a different approach. It lets teams release when the work is ready. Not when the calendar says so, but when the code is tested, stable, and valuable.

In this article, I’ll share lessons from implementing RoD in a large enterprise. It’s not a how-to. It’s a real-world view of what worked, what changed, and what we learned.

What is Release on Demand (RoD)?

RoD is a delivery model that shifts decision-making about releases from central schedules to autonomous teams. It allows teams to push changes to production independently, based on readiness and agreed governance.

It draws on Agile, DevOps, and Lean practices:

  • The main branch stays deployable at all times.
  • Teams decide what and when to release.
  • Automation covers everything from build to deployment to change control.
  • Governance is built into the process, not layered on top.

This gives teams the flexibility to release daily, weekly, or whenever it makes sense. The cadence adapts to the work, not the other way around.

To understand how this works in practice, let’s look at the typical RoD workflow. The diagram below shows how risk assessment drives the release path, with governance built into the process rather than layered on top.

Release on Demand Workflow

As the workflow demonstrates, the key difference lies in the risk-based routing and automated governance stages. This foundation enables the practical implementation elements we’ll explore next.

RoD in Practice: What You Actually Need

1. Culture First

RoD lives or dies on team culture. Autonomy without ownership causes problems. RoD works when teams are comfortable owning deployment, monitoring, and support.

You need:

  • Cross-functional teams that can ship and support their work.
  • A mindset that encourages testing, learning, and adjusting.
  • Leadership that sets guardrails, not barriers.

2. Automation Everywhere

You can’t do RoD manually. If you’re still copying scripts or raising manual change records, RoD won’t scale.

The essentials:

  • CI/CD pipelines that handle everything from build to deploy.
  • Infrastructure as Code so environments can be recreated quickly.
  • Strong automated test coverage.
  • Monitoring, logging, and alerting tied to each release.

If a team can’t see what happens after deployment, they’re not ready.

3. Governance Built In

RoD doesn’t remove governance. It changes how it’s done. The goal is to satisfy risk and compliance requirements without slowing down delivery.

You can:

  • Automate RFC creation and closure using ServiceNow APIs.
  • Use change templates to classify risk.
  • Add automated checks and approvals in the pipeline
  • Send release notifications through Teams, Slack, or email.

Good governance should feel invisible. It’s there, but it doesn’t block the work.

Case in Point: A Data Team’s RoD Journey

One of our data platform teams led the first RoD implementation in our environment. They used to work on a fortnightly release cadence. Even though they followed Agile practices, releases at the end of each sprint were often delayed. Change approvals, environment constraints, and coordination issues added friction.

The team decided to try RoD. They kept Azure DevOps as their pipeline tool and connected it with ServiceNow to automate change records. They introduced:

  • Pipelines triggered by readiness, not dates.
  • Built-in compliance and testing checks.
  • MS Teams alerts to keep stakeholders informed.
  • Post-deploy validation to catch issues quickly.

Within weeks, they were releasing to production daily. Smaller, more focused releases reduced the risk of failure and made debugging easier. The time spent on manual change records dropped significantly.

While the percentage of RoD releases has likely grown since, during the first year, most of their production deployments were already happening through RoD. That progress helped build trust and became a model for other teams.

Sustaining RoD: What Matters Most

1. For Developers

Keep code deployable. Always.

  • Use feature flags to manage partial releases.
  • Treat your tests as part of the release process, not an afterthought.

2. For Ops and Platform Teams

Standardise how environments are built and torn down.

  • Give teams easy access to observability.
  • Support fast, safe rollback paths.

3. For Governance and Change

Define what counts as a RoD-eligible change.

  • Use automation to enforce templates and policies.
  • Monitor trends and exceptions through dashboards, not forms.

4. For Leadership

Set expectations around autonomy and outcomes.

  • Invest in automation and platform consistency.
  • Measure flow, not just output.

Take away

RoD isn’t about speed. It’s about control. It gives teams the tools and responsibility to release safely, quickly, and when it makes sense. Done right, it reduces risk, improves quality, and makes delivery more responsive to real business needs.

It’s not easy. It takes time to get the foundations in place. But it’s worth it.

If you’re stuck in slow, inflexible release cycles, RoD offers a way out. Start with one team, build confidence, and evolve from there. Release when ready and know that you are.