Analysis / CI/CD and ZDD whitepaper

From Here to Continuous Delivery: A Roadmap for CI/CD and Zero-Downtime Deployment

Version 0.1, first draft for review Audience: engineering leadership, platform and DevOps teams, and stakeholders who fund or depend on release capability.

Executive summary

Travel Counsellors runs its platform across three environments moving at three speeds. The on-premises estate in Manchester carries roughly 80% of our systems, including the shared SQL Server estate and Phenix Back Office, and is released every three weeks as a single whole-platform deployment that requires a full shutdown and restart. Our AWS container platform releases without downtime, and one service (TC Co-Pilot) can ship several times a day, yet other AWS services still wait for the three-weekly release for no technical reason. A third, emerging platform (the agentic platform, built on AWS and Kubernetes with a developer-friendly abstraction, Qovery, to be confirmed) is being designed for multiple releases per day, per repository, with ephemeral environments to test changes in isolation before production.

The capability to change the on-prem picture already exists in-house. The Zero-Downtime Deployment (ZDD) programme has automated the stealth-release process end to end, running its first fully automated no-downtime production deployment in mid-2026. It is used today for bug fixes and urgent changes; this paper argues it should now carry feature change too, letting us shrink the three-weekly release, deploy by domain or application, and lower both risk and downtime. For the genuinely entangled legacy core (Phenix Back Office, Admin Studio), we propose the opposite: a deliberately slow cadence protected by a change freeze. In short, protect the core and let the rest release independently.

The roadmap drives four outcomes: no or very few downtime releases; more frequent, smaller, lower-risk deployments; delivery metrics (DORA) captured by default via Jellyfish; and retirement of the whole-platform regression cycle, which is what currently forces the fixed three-week release. This aligns with a wider shift: formal three-month Program Increment planning ends in July 2026, giving way to a continuous, pull-based delivery model (Express Delivery). Release capability is the technical foundation that model depends on.

1. Introduction

1.1 Two capabilities, two workstreams

CI/CD and zero-downtime deployment are related but distinct, and we treat them as parallel workstreams:

CI/CD is about the pipeline: how quickly, safely, and repeatably a change moves from commit to production, measured by lead time, deployment frequency, and change failure rate.
Zero-downtime deployment (ZDD) is about the release moment. At Travel Counsellors it has a specific meaning: the automated stealth-release process, deploying without taking the platform down.

You can have strong CI/CD and still take an outage on every deploy, or zero-downtime releases and still deploy quarterly. Both must be understood per environment, because our three environments start from very different places.

We treat them as two workstreams because they mature on different timelines and should not hold one another back. ZDD is a capability we already have: it can let change ship without downtime now, on the existing estate, reducing our reliance on the three-weekly downtime release without waiting for other work. CI/CD is a longer maturity journey that differs by environment. Running them in parallel lets us realise the near-term reductions in downtime, and early progress on release decomposition, without waiting for full pipeline maturity. Both rest on the same foundations: test automation, environment provisioning, observability, and delivery metrics.

1.2 Strategic context: the delivery operating model

Release capability is not an end in itself. Product and delivery are moving to Express Delivery: a lighter, pull-based operating model that replaces quarterly commitment cycles with continuous prioritisation (a Now, Next, Later roadmap) and uses agentic AI across discovery, delivery, and testing while people validate and decide. A 90-day commitment starts it in Q4 2026, proving the newer domains first (TC Co-Pilot, myTC). Continuous, value-based delivery is only credible if we can release small changes frequently, safely, and without downtime, so CI/CD and ZDD are its technical foundation.

1.3 Scope

In scope: release capability across the three core environments. Adjacent programmes (containerisation, observability, cloud migration, event-driven architecture, database strategy) appear only where they enable or constrain release capability.

2. Where we are today

2.1 Three environments, three speeds of change

	1. On-prem (Manchester DC)	2. AWS container platform	3. Agentic platform (emerging)
What it is	Virtualised hosts in our Manchester data centre	Multi-account AWS (account per environment); ECS clusters pulling from ECR	New consolidated platform: AWS, likely EKS, with Qovery as a developer-friendly abstraction
What lives there	Around 80% of the estate; most legacy systems; the shared SQL Server estate; Phenix Back Office at the centre	Most new work of recent years: TC Co-Pilot, Payments Orchestration, and Room Normalisation are examples among many services not strongly dependent on the Phenix core	The agentic engineering harness and the applications it publishes; TC Co-Pilot and myTC backend migrating in the near term; the default home for greenfield work
How it releases	Every three weeks, whole platform, requiring a full shutdown and restart; stealth releases for urgent fixes	Mixed: TC Co-Pilot ships at will (several times per week or per day); others are bundled into the three-weekly release with no technical reason	Designed for multiple releases per day, per repository: ship when ready, behind feature toggles
Deployment downtime	Two or more hours per full release; holding page displayed	None	None (by design)
Comments	A fairly well-managed virtualised estate, but the release model is the problem	Ships reasonably quickly, but the structure is convoluted, observability could be better, the release process is not yet hardened, and it is not true CI/CD	The target state; largely still to be built

A snapshot of what runs where covers the on-prem and AWS estates and around 125 distinct APIs. The agentic platform has no registered services yet, though TC Co-Pilot is expected to move there soon.

Source: TC ConnectionBroker registry

Hosting	Count	URL pattern	Examples
AWS, containerised	36	subdomains under `*.prod.travelcounsellors.io` (phenix, public, cx, payments)	tc-copilot-api, tc-public-quote-api, destination-queries-api, phenix-cruise-odysseus-acl-api
On-prem, IIS	89	`phenix.travelcounsellors.com/api/<name>` and `/services/<name>`	PhenixSelling, FlightsConfiguration, CarHireGateway, P2PAclBedsonline, Ledger

A few things stand out:

The split is clean: every AWS service is containerised and every on-prem service runs on IIS, with no overlap. The on-prem estate is a single, consistent target, and the roughly 90 on-prem services line up with the "around 90 candidate systems" referenced later. This registration is a ready-made starting point for the estate-segmentation workstream (sections 5.5 and 9.2), not a list to build from scratch.
AWS holds the modern surface: TC Co-Pilot and its variants, the public API set (tc-public-*), query and margin services, and several anti-corruption layers (ACLs). Migration is visibly in progress: the cruise ACL already runs in AWS, while the majority of ACLs (P2PAclBedsonline, P2PAclDirectStock, P2PAclHolidayTaxis, and P2PAclMozio, the first automated ZDD release) are still on-prem.
The dependency signal is not yet captured: the registry also records "on-prem dependency" and "SQL dependency" flags, but neither is populated today. Filling them in would turn this registration into the dependency map the paper calls for, and close part of the dependency-visibility gap (section 2.4).

2.2 How we build and release today

Cadence: a two-week sprint plus a one-week regression cycle gives a release every three weeks, with formal test cycles on Test QA and Pre-Prod and a sign-off gate.
The release is the whole platform. Many systems are coupled; many are not, but everything ships together regardless. The coupling is by process, not technology: on the same AWS platform, TC Co-Pilot releases daily while other services (for example Payments Orchestration and Room Normalisation) wait for the three-weekly release.
Twelve downtime releases per year, each needing two or more hours of downtime. Urgent fixes go out between them as stealth releases, now automated by the Workflow Engine (section 5.1).
Regression is whole-platform: the one-week cycle tests everything, which is what forces a whole-platform release and holds the three-week cadence. Replacing it with regression by area is a central goal of this paper.
Tooling: hybrid Git Flow and trunk-based branching; Azure DevOps pipelines, orchestrated for stealth releases by the Workflow Engine via the DevOps Management Portal. End-to-end pipeline turnaround is 6 to 16 days today, against a target of 0 to 4.
Planning is changing: formal Scaled Agile and PI planning ends in July 2026, replaced by Express Delivery (section 1.2). The three-week cadence stays until whole-platform regression is removed.

2.3 The measurement gap

We do not systematically capture DORA metrics today (deployment frequency, lead time for changes, change failure rate, and mean time to restore). The current-value column below is largely empty as a result:

Metric	Current value	Notes
Deployment frequency (on-prem)	12 downtime releases per year, plus stealth releases (volume to be confirmed)	Stealth volume to be provided by App Support
Deployment frequency (AWS)	Mixed: TC Co-Pilot several per day; others every three weeks	Not instrumented
Lead time for changes	Not captured (pipeline turnaround of 6 to 16 days as a proxy)
Change failure rate	Not captured
Mean time to restore (MTTR)	Not captured
Deployment-caused downtime	About 24 hours per year or more (two or more hours across 12 releases)	AWS releases: none

The fix is scoped: call a Jellyfish endpoint from the pipelines to record these metrics, on-prem first, then AWS, and by default on the agentic platform. This is the roadmap's first step, because it makes every later improvement measurable.

2.4 Pain points and constraints

The release model: three-weekly, whole-platform, shutdown and restart. Large releases mean high risk, high coordination cost, and guaranteed downtime.
Whole-platform regression is the binding constraint on decomposing the release: until regression is scoped by area, a domain release cannot be verified in a domain-scoped way.
Coupling by process, not technology: much of the estate could release independently today but does not.
Limited dependency visibility: tooling gives partial insight and most knowledge sits with individuals.
Capacity: ZDD and containerisation share the same DevOps capacity, and ZDD has depended on a single senior engineer.
No delivery metrics (section 2.3), so we cannot yet evidence progress.

3. Where we want to be

3.1 The four outcomes

No downtime releases, or very few: downtime becomes exceptional and steadily reducing.
More frequent, smaller, lower-risk change, delivered when ready rather than on a fixed schedule.
Delivery metrics captured by default (DORA), so progress is evidenced, not asserted.
Whole-platform regression retired, replaced by regression by area. This is the change that unlocks outcomes 1 and 2.

From here, the wider modernisation programme (containerisation, cloud migration, event-driven architecture, database strategy) proceeds on measurable, low-risk foundations.

3.2 Target release model per environment

Environment	Target release model
On-prem, releasable subset	Domain- or application-scoped releases via ZDD, including feature change, verified by area-scoped regression; ad hoc, as required
On-prem, true legacy core (Phenix Back Office, Admin Studio, core SQL estate)	A deliberately slow scheduled cadence with a change freeze: minimal change flows through these systems, with few planned downtime releases (target 4 per year, then 2)
AWS ECS	All services separated from the three-weekly release; a hardened, repeatable release process; at-will cadence (TC Co-Pilot as the example)
Agentic platform	Multiple releases per day, per repository, by default; ZDD as a built-in platform property; DORA instrumentation by default

3.3 Guiding principles

Protect the core, release the rest: a change freeze and slow cadence for entangled legacy, independence for everything else.
Decouple deployment from release with feature toggles, so code can ship inactive and be activated when the business chooses.
Non-breaking change by default: backwards-compatible APIs and expand-contract schema changes (section 5.2).
Instrument first: no capability investment without the measurement to prove its effect.
Scoped verification for scoped releases: test decomposition and release decomposition move together.
Measure outcomes, not output: tickets, pull requests, and story points are diagnostics, not targets.

4. Workstream A: CI/CD

4.1 Three tracks, three starting points

CI/CD maturity differs by environment, so each has its own starting point:

On-prem (build): no modern CI/CD yet; the ZDD and Workflow Engine programme is building the automated deployment path, so on this estate ZDD also serves as the foundation for CI/CD. The long-term aim is merge-triggered build and test, automated staging with tests, a QA-lead gate to production, and automated zero-downtime release.
AWS ECS (harden): CI/CD is available in theory and proven by TC Co-Pilot. Work needed: simplify the structure, improve observability, harden the release process, and make at-will release the norm for every service, not just one.
Agentic platform (build it right first): true CI/CD as default behaviour, with pipeline, toggles, progressive deployment, and DORA instrumentation built in.

4.2 Capability areas

In priority order:

Automated testing and quality gates are the foundation: unit, integration, API, and regression testing, shifted earlier, and regression decomposed by area to retire the whole-platform cycle.
Dynamic test environments: on-demand and consistent, including ephemeral environments per change.
Pipeline observability and delivery metrics: Jellyfish DORA across all pipelines.
AI-assisted PR review: automatically flag ZDD-incompatible changes, addressing the dependency-visibility gap.
Foundations: build automation and artefact management; integrated load and performance testing; configuration and secrets via a secret manager (never in code or pipelines); branching revisited as decomposition matures.

5. Workstream B: zero-downtime deployment

5.1 What we have already built

ZDD is not a proposal; it is a delivered capability being bedded in:

Phase	Scope	Status
1: "Create Stealths" workflow	Automated the manual process for creating stealth releases; developer self-serve	Complete (Feb 2026)
2: "Maintenance Drain" workflow	Server maintenance mode plus load-balancer drain and return, with health-check gating and user-intervention steps	Complete (May 2026, ahead of schedule)
3: full stealth-release coordination	End-to-end automated no-downtime deployment; multi-server concurrent stages	First successful production run (around June 2026, P2PAclMozioApi); now being monitored across further releases

Known follow-ons: the Phenix UI mono-repo release process; Workflow Engine fixes and features; L4 NAT load balancing (replacing L4 DSR) to shorten drain time; extending the workflow to the full downtime release; and reinstating the release-management UI for in-system sign-off.

5.2 The engineering discipline that makes ZDD safe

Today's stealth releases already achieve zero downtime for a single system through a rolling update, but they rely on accepting fix-forward risk during the roll rather than on every change being safe to run in two versions at once. Extending ZDD to feature and major changes needs that stricter discipline applied consistently, so old and new code can run side by side. It is an engineering investment, not only a pipeline one.

ZDD rests on a four-stage discipline (pre-deployment, deployment, feature activation, post-release cleanup):

Backwards-compatible API changes, or explicit new versions.
Feature flags for anything affecting compatibility, tested in both off and on states.
Non-breaking schema changes (expand-contract: add, bridge, validate, remove later).
Front and back ends decoupled for independent deployment; cache compatibility checked.
Compatible serialized data: new code must read state and messages (for example Redis or queues) written by the previous version.
Stateless services with externalised session state, so a user can move between nodes mid-session without disruption.
Observability-gated activation with automated rollback: enable features only when release health is proven, and roll back automatically if alerts such as error-rate spikes fire soon after a release.

These principles, with the full database, API, and shared-client patterns, are set out in the ZDD engineering standard (zdd-engineering-standard.md). The near-term priority is to make them the working practice of every team.

5.3 The first evolution: ZDD for feature change

ZDD is used today for stealth releases (fixes). The first evolution is to route feature change through the same path:

Carve feature changes out of the whole-platform release and ship them by domain or application.
Prerequisite: regression by area, with scoped packs that verify a domain release without the full one-week cycle.
Prerequisite: the automated deployment path, delivered by the Workflow Engine and now being hardened.
Prerequisite: the non-breaking, dual-version discipline (section 5.2) applied consistently, so a feature change is safe to run alongside the current version.

The release then shrinks over time, risk falls with deployment size, and the case builds for a formally reduced downtime schedule.

5.4 Containerisation is the destination, not the precursor

It is often assumed that containerising the platform is a prerequisite for CI/CD and zero downtime. Containerisation is part of the long-term answer (standard rolling deployments, isolation, portability), but as a precursor it would leave roughly 80% of the estate on three-weekly downtime for the length of a multi-year migration.

The question is what to do in the meantime, and ZDD is the answer: increase release frequency now, on the existing estate, and build the practices the container platform will need anyway. That means segregating the release chain by domain or application, across QA ownership, regression packs, deployment units, and release governance. None of this is wasted: it transfers directly into containerised operation and de-risks the migration, because workloads then move with a proven release model rather than changing platform and operating model at once.

5.5 The on-prem question, and our answer

The on-prem estate is tied to the shared SQL Server estate, with Phenix Back Office at the centre, and carries roughly 80% of our systems. Four options present themselves:

Accept that three-weekly downtime is fixed.
Identify the releasable subset that can release independently, and build the faster path for it (ZDD with scoped regression).
Slow the true core down: put the entangled legacy (Phenix Back Office, Admin Studio, the core schema) on a deliberately slow cadence behind a change freeze.
Migrate the on-prem estate into containers on AWS: rehost the estate onto the AWS container platform, which means tackling the central SQL Server dependency and the on-prem couplings head on rather than working around them. This is a substantially larger and longer effort than the ZDD-led path, but it removes the underlying constraint at source and leaves the estate in a materially better end state.

Our position is options 2 and 3 together, not option 1: protect the core, release the rest. The change freeze is a deliberate control, not a concession. It contains risk in the highest-risk systems, requires new capability to be built outside the core (supporting the strangler-pattern decomposition already under way), and makes the remaining downtime releases rare and predictable. Segmenting the estate (genuinely coupled versus merely co-released) is the first analysis, starting from the roughly 90 containerisation candidate systems.

A concrete illustration of why parts of the core still need downtime: the BackOffice ecosystem depends on a shared WCF client (PhenixServicesClient) used by more than 100 applications. Because WCF enforces strict serialization contracts, adding a value to a shared enum breaks every consumer that has not yet been recompiled and redeployed with the updated client, and coordinating a single zero-downtime rollout across all of them is not safe. Changes like this are scheduled into a coordinated maintenance window until the contract is made additive or the dependency is decoupled, for example by moving from WCF to REST or gRPC.

Option 4 is set out here as a genuine alternative rather than a recommendation. It is the more fundamental fix and the stronger long-term end state, but it carries significantly more effort, cost, and risk, and it does not deliver the near-term reductions in downtime that options 2 and 3 do. The two directions are not mutually exclusive: the release decomposition and estate segmentation under the ZDD-led path also prepare the ground for a later migration (section 5.4), so choosing 2 and 3 now does not foreclose option 4.

The downtime path (from 12 to 4 to 2 releases per year) is reached not by thinning the same whole-platform release, but by moving volume out of it: ZDD for the on-prem subset, at-will releases on AWS, and continuous delivery on the agentic platform, until only the frozen core remains scheduled.

5.6 Deployment mechanisms

Environment	Mechanism	Notes
On-prem	Workflow Engine: drain, deploy, health-check, then return	Drain-time improvement via L4 NAT under exploration
AWS ECS	Rolling deployments via ECS	Release process to be hardened
Agentic platform	Rolling and progressive delivery as the platform default (Qovery/EKS)	ZDD as a built-in property rather than a later addition

A change freeze must also cover schema: a frozen core with an unfrozen database is not truly frozen. Expand-contract migration applies (section 5.2), and the shared SQL Server estate needs a dedicated migration approach.

6. The roadmap

6.1 Phases

Milestones map to the new sprint-by-sprint cycles rather than to Program Increments. The phases below are sequenced but not yet dated; producing a time-bound plan, with milestones on the sprint calendar and a capacity view, is a required next step (section 8).

graph LR
    subgraph "Phase 0: Instrument"
        M1[Jellyfish DORA endpoints<br/>in all pipelines]
    end
    subgraph "Phase 1: Decompose"
        D1[Regression by area]
        D2[ZDD for feature change<br/>on-prem subset]
        D3[Separate AWS services<br/>from the release train]
        D4[Non-breaking change<br/>discipline adopted]
    end
    subgraph "Phase 2: Two-speed model"
        T1[Change freeze on<br/>legacy core]
        T2[Reduced downtime<br/>schedule: 12 to 4 per year]
        T3[Hardened AWS<br/>release process]
    end
    subgraph "Phase 3: Target state"
        G1[Agentic platform:<br/>CI/CD + ZDD by default]
        G2[Workload migration:<br/>TC Co-Pilot, myTC backend,<br/>greenfield]
        G3[Downtime releases<br/>towards 2 per year]
    end
    M1 --> D1
    D1 --> D2
    M1 --> D3
    D4 --> D2
    D2 --> T1
    D2 --> T2
    D3 --> T3
    T1 --> G3
    T2 --> G3
    T3 --> G2
    G1 --> G2

Phase 0, Instrument (immediate): Jellyfish DORA from on-prem pipelines, then AWS, and by default on the agentic platform. Low-cost, and it makes everything after it measurable.
Phase 1, Decompose (very short term): regression by area; ZDD carrying feature change on the on-prem subset; AWS services separated from the three-weekly release (a process change, no technical blocker); non-breaking-change discipline adopted.
Phase 2, Two-speed model: change freeze on the legacy core; whole-platform regression retired in favour of regression by area; downtime cut from 12 to 4 per year; AWS release process hardened.
Phase 3, Target state: agentic platform live with CI/CD and ZDD by default; TC Co-Pilot and myTC backend migrated; greenfield lands there; downtime towards 2 per year.

6.2 Key risks

Capacity: ZDD and containerisation share DevOps capacity, with a single-engineer dependency on the Workflow Engine.
Regression decomposition effort is unknown until the test-estate inventory is done.
Process and mindset: unbundling the habitual whole-platform release is as much cultural as technical.
Parallel environments: running three release models at once carries overhead until migration consolidates them.

7. Measuring progress

The metric set is the four DORA metrics plus downtime, from the Phase 0 instrumentation:

Metric	Baseline (to capture)	Direction of success
Deployment frequency	Phase 0	Increasing, and shifting from scheduled releases to ad hoc
Lead time for changes	Phase 0 (proxy: 6 to 16 days)	Decreasing towards 0 to 4 days
Change failure rate	Phase 0	Decreasing as deployments get smaller
MTTR	Phase 0	Decreasing, supported by the observability programme
Deployment-caused downtime	About 24 hours per year or more	Approaching zero; downtime releases from 12 to 4 to 2 per year
Share of releases via ZDD or at-will paths	Around 0% for features	Increasing; this is the decomposition indicator

Leading indicators: pipelines instrumented; regression packs decomposed by area; AWS services separated from the release; feature changes shipped via ZDD; systems under change freeze. These sit under the product metrics of the new operating model, adoption, flow, and outcomes, where DORA is part of flow. The rule across both: measure outcomes, not output.

8. Recommendations and next steps

Instrument now. Add the Jellyfish DORA endpoint calls to on-prem pipelines this sprint, then AWS, and make them default for the agentic platform.
Adopt the two-speed strategy formally: protect the core and release the rest (section 5.5).
Commission the estate segmentation: genuinely coupled versus co-released by process, starting from the roughly 90 containerisation candidate systems.
Start regression decomposition. Inventory the regression estate and pick the first domain to scope-test, aligned with the first ZDD feature-release candidate. This is what releases the fixed three-week cadence.
Separate the AWS services from the three-weekly release: a process decision available now, with TC Co-Pilot as the internal example.
Document the non-breaking-change discipline and make it the standard for all teams.
Produce a dated roadmap. The phases in section 6 are sequenced but not yet time-bound; the next planning step is to place milestones on the sprint calendar with a capacity view, and to confirm the roadmap owner.

Ownership, and the approach for turning these into a detailed plan, is set out in section 9.

9. Delivery approach and ownership (draft plan)

This is a plan for producing the detailed plan. It names a lead for each workstream and the first deliverable that lead owns, so the roadmap is built by the people accountable for each area. It follows the Now, Next, Later approach of the operating model (section 1.2) and starts with instrumentation. Owners named below are a draft for confirmation.

9.1 How we will run it

Each workstream has a named lead accountable for a first deliverable, usually a scoped proposal or assessment, not the full build.
Steering and governance sit within the wider project or programme and are to be confirmed; they will resolve cross-cutting trade-offs such as sequencing, dependencies, and the capacity shared across ZDD and containerisation.
Instrument first, and pull work in Now, Next, Later order.

9.2 Workstreams, owners and first deliverables

Workstream	Lead(s)	First deliverable	Reference	Horizon
DORA instrumentation (Jellyfish)	Chris Brookes, with DevOps	Approach for applying the pipeline changes that call the Jellyfish endpoint, with agreed metric definitions	2.3, 6	Now
Regression decomposition	Mike M, Juhi	Proposal to break whole-platform regression into area-scoped packs, with a first domain to pilot	4.2, 5.3	Now
Estate segmentation and domain independence	Chris Brookes, Joe Palin, John Elliot, with domain leads	Classification of systems as freeze, release independently in place, harden on ECS, migrate, or retire, starting from the list of around 90 candidate systems	5.4, 5.5	Now to Next
ZDD for feature change (Workflow Engine)	James Cavendish	Plan to route a first feature change through ZDD on the on-prem releasable subset	5.1, 5.3	Next
Non-breaking change discipline	Wes Potter, James Cavendish, Chris Brookes, Joe Palin	Documented engineering standard for backwards-compatible APIs, expand-contract schema, and feature flags (drafted: `zdd-engineering-standard.md`)	5.2	Now to Next
Change freeze for the legacy core	Paul Adams, PMs, Eng Leads	Change-freeze policy and exception process for Phenix Back Office, Admin Studio, and the core schema	3.3, 5.5	Next
AWS ECS unbundling and hardening	DevOps with the AWS service owners, for example Payments Orchestration (Tom Warren, John Elliot). Many services run on the AWS estate, Room Normalisation being one of several	Plan to separate the AWS-resident services from the three-week release and harden the release process	2.1, 4.1	Next
AI-assisted PR review for ZDD compatibility	Wes Potter with Jeremy Smith	An automated check in PR review that flags whether a change is ZDD compatible or incompatible	4.2	Next
Agentic platform and workload migration	Steve Holder, with Tom Allard and Paul Adams	Target-state platform definition (Qovery and EKS) and a migration plan for TC Co-Pilot and myTC backend	2.1, 6	Later
Overarching roadmap, cadence and capacity	To confirm	Dated roadmap with milestones on the sprint calendar, a capacity view, and the reduced downtime schedule	6	Now
Benefits and baseline evidence	App Support (Hayley) with Product	Uptime-release effort and downtime impact data to support the benefits case	2.3, 7	Now
Product and delivery alignment (Express Delivery)	Chris Barker, Vick Tracey	Mapping of release capability to the Now, Next, Later operating model and the product metrics	1.2, 7	Next

Glossary

Term	Definition
CI	Continuous integration: merging and automatically verifying changes on a shared mainline, many times a day
CD (delivery)	Continuous delivery: every green build is deployable; production deployment is a manual decision but an automated action
CD (deployment)	Continuous deployment: green builds deploy to production without human intervention
ZDD	Zero-downtime deployment. At TC, the automated stealth-release process: releasing without taking the platform down
Stealth release	A deployment made without platform downtime, historically manual and used for urgent fixes
WFE	Workflow Engine: the in-house orchestrator that drives automated stealth releases
DMP	DevOps Management Portal: the interface for the Workflow Engine and deployment operations
Whole-platform regression	The one-week regression cycle that tests the entire platform before a release; the constraint that forces the fixed three-week release
Regression by area	Regression scoped to a domain or application, so that area can be verified and released independently
Change freeze	A deliberate policy preventing new change flowing through designated legacy-core systems
Two-speed model	A slow scheduled cadence for the frozen legacy core, and ad hoc ZDD or at-will releases for everything else
Express Delivery	The emerging product and delivery operating model: continuous, pull-based flow with agentic AI assistance, replacing quarterly commitment cycles
Now, Next, Later	A continuous-prioritisation roadmap format that replaces fixed quarterly commitments
Expand-contract	A database migration pattern: add the new schema alongside the old, migrate consumers, then remove the old
DORA metrics	Deployment frequency, lead time, change failure rate, and MTTR: the four standard delivery metrics
Jellyfish	An engineering-metrics platform; the target for pipeline-emitted DORA data
Qovery	A developer-friendly abstraction layer over Kubernetes (EKS); the probable basis of the agentic platform
Ephemeral environment	A short-lived, temporary environment for testing a change in isolation; key for safe CI/CD
Sprint	Two weeks of work within the current three-week release cycle, and from July 2026 the unit of planning
PI	Program Increment: the three-month Scaled Agile planning cadence. Formal use ends in July 2026