The story · about 10 minutes · no technical background needed

From one line of code to production

Follow one small fix through the seven stops every change takes: built, combined with the rest of the product, tested, approved, and released to customers on purpose.

State as of 28 October 2026The scenario is illustrative; every behaviour described is real or carries a status badge.

The fix

A finance team using one of our products notices that a report rounds a total the wrong way. A developer finds the cause in minutes:

reports service · one file changed

- var total = Math.Round(amount);

+ var total = Math.Round(amount, 2, MidpointRounding.AwayFromZero);

The hard part is getting that line to every customer without breaking anything else, and so that anyone can say exactly what is running in production at any time.

The analogy used on this pageOur products are run like a restaurant chain: kitchens with stations, a set menu, a test kitchen and a flagship restaurant. It is the only analogy here.

Stop 1

A product is several services, each owned by one team

The developer changes the reports service and nothing else. The screens, the calculation engine and the database setup are separate programs. Each of these programs is a service: it does one job, is owned by one team, and lives in that team's own repository, a versioned folder that records every change (who, when, why).

Splitting a product this way lets a team change its part without touching the others, and lets a busy part get more capacity on its own.

In the restaurantA kitchen has stations: soup, grill, pastry. Each station perfects its own dish and can change its recipe without asking the others. The guest still experiences one meal.

A typical product: a core team (API, database migrations, cache), a front-end team (web screens, importers), a reports team and a content team. Every product has its own list, but they follow the same pattern.

Stop 2

Every change is packaged once, with a version number

Nobody presses a button. When the change is merged, the team's build checks it and packages the reports service as a service chart: the program (a container image) plus the instructions for running it anywhere.

How to run it: copies, memory, health checks, updates without downtime.
How people reach it: its web address prefix.
Which settings and secrets it needs: declared by name; each place fills in the values (stop 5).
A version number from the build's date and time: 202610.17.093512 means 2026, October, day 17, built at 09:35:12.

Every service chart is built from one shared template, the platform chart, so security settings, health checks and zero-downtime updates are built once for everyone. A packaged version is never edited: a new change means a new version. Every version is kept, so we can always go back.

In the restaurantA recipe card plus prepared ingredients: any kitchen in the chain can produce the identical dish from it. A recipe card is never corrected in place; a new recipe gets a new card.

What this replaced: in the old setup, 62% of changes to these packaging files only copied a setting from one file to the next. A team now declares a setting once, next to the code that uses it.

Stop 3

All parts of a product move together as one version

Customers use the product, not the reports service. The product pipeline checks every 30 minutes whether anything changed since the last approved version (a change to the product's own files starts it straight away). It finds the new reports package and builds a new product version.

A product can have three kinds of component, each built with different tools:

Component	What it is	Status
Application (`helm`)	Everything that runs in the cluster: one product chart holding every service chart.	built
Data pipelines (`adf`)	The product's Azure Data Factory pipelines, packaged as one data package.	package built · deploy planned
Analytics (`databricks`)	One or more Databricks bundles, each from its own repository.	package built · deploy planned

The product version is written down in a composition: every component, its exact version, and a fingerprint (digest) proving nothing was swapped. Every deployment reads the composition first and installs exactly what it lists. That is how we can say with certainty what runs anywhere.

In the restaurantGuests order a set menu. The menu card names the exact version of every dish and drink served together.

Illustrative numbers. Only the reports line is new. Each line also carries a fingerprint.
Product version 202610.18.101530 (candidate)	Version
Core	`202610.17.141502`
Front end	`202610.16.081144`
Reports (our fix)	`202610.18.093512`
Content	`202610.12.120400`
Data pipelines	`202610.16.110230`

Why combine? Parts depend on each other, so the exact combination is what gets tested. One number then describes everything, and a release or a roll-back moves every part together.

Tree diagram: a product made of components, the application component made of service charts and services

What a product is made of (interactive diagram, opens full screen)

Stop 4

Test environments pick up a new version by themselves

Each place a product runs is an environment, with its own web addresses, database and keys. Environments are grouped into landscapes that share rules, for example every development environment uses the development login system. Inside each environment, a controller called Flux watches for new versions.

In a test environment, Flux sees the new version (a candidate) and installs it. No ticket, no request.

In the restaurantEach location has an on-site manager. In the test kitchen the instruction is "always serve the newest menu". In the flagship restaurant it is "serve menu X until head office says otherwise".

Landscape	Environments	How it moves	Status
dev	app01	Follows every new candidate ("track")	built
qa, prod	–	Stays on one chosen version ("pin") until promoted	planned no environments yet; greenfield IaC will create them
nonprod, preview	–	Pinned	planned placeholders only

Each product in each environment gets its own walled-off space (a namespace) named <environment>-<product>-<landscape>, for example app01-<product>-dev.

Stop 5

The same package runs everywhere; each place adds its own settings

The new version needs answers when it starts: which database, which login system, what is the reports service's address here? None of these are inside the package. They are settings (engineers say values), added by the place it runs in. Three rules cover almost everything.

1. The most specific setting wins

In the restaurantThe chain's standard recipe says bake 20 minutes; a mountain location's rule says 25; one oven runs hot, so that kitchen's sheet says 23. The cook follows the most specific instruction.

Example: how long may a database query run? Illustrative numbers. Layers 1–3 are sealed into the package; layers 4–6 are added by the environment, so it can change a setting without a new build.
Layer (later wins)	Set by	Example
1. Platform defaults	platform team	30 s
2. The service's own file	service team	–
3. Product	product team	60 s
4. Landscape (every dev environment)	platform operations	90 s
5. This environment (app01)	platform operations	120 s, this wins
6. Identity (name, landscape, tier)	automatic, cannot be changed	–

2. Every setting has one owner and one place

A service declares which settings it needs, with a sensible default or the marker "$required" ("each place must fill this in"). Shared packs (login, error tracking) are filled in once per landscape. A setting that is the address of another part of the product is written "$url:reports/api" and worked out automatically. Details: Reference: where settings come from.

3. Passwords are never in a file

Files hold only the names of secrets. The product keeps the list of allowed names; the real values stay in Azure Key Vault and are fetched when a service starts. A missing "$required" value, an unlisted secret name or anything that looks like a password stops the release before it reaches any environment.

For the first product, this model cut product configuration from about 366 lines with 37 templates to 187 lines with none.

Stop 6

Only a version that ran well is approved

The product pipeline watches the first test environment (dev/app01) until every part of the new version has started and is healthy. Only then does it mark the version approved. Nobody presses a button: a healthy test run is the approval, because the human decisions come later. A version that fails is never approved and cannot reach production by the normal route.

In the restaurantThe head chef tastes the new menu in the test kitchen and signs the card if it is right. Signing does not change the flagship's menu; that is a separate decision.

Lifecycle diagram of a product version from candidate to approved and promoted

The life of a product version (interactive diagram)

Stop 7

Production changes on purpose, through a recorded change built, not live

Someone asks the product pipeline to promote an approved version to a landscape such as prod. The pipeline writes that version into the environment's file as a recorded change; the environment pipeline applies it, and the product pipeline checks that it runs. Going back works the same way: choose an earlier approved version.

Not live yet

Promotion is built but has not completed a run. Only dev/app01 exists today. Promotion to qa and prod is not possible until greenfield IaC creates those environments: CD · Promote and CD · Release stop at their first step. The environment pipeline is also failing, and the approval gates have no reviewers yet. See where things stand.

There are two pipelines on purpose:

	Product pipeline	Environment pipeline
Answers	Is this new version good?	What should this place look like?
Lives in	the product repository	the environment repository (cloud-config)
Does	combines, tests and approves versions; promotes approved ones	creates environments, changes their settings, applies promoted versions
Never	changes an environment's settings	builds a version

Opening a new environment never needs a new build, and a new build never quietly changes production. The only place they touch is promotion. More: Reference: where the two pipelines meet.

In the restaurantHead office's menu team decides which menu is good; operations for each location decides what that location looks like. The flagship changes its menu only when head office's decision is written into its instructions.

What if…

The new version does not start in the test environment

It is never approved, so it cannot be chosen for production. The developer fixes it; the fix becomes a new version. Customers never saw the broken one.

A release needs undoing

Someone promotes an earlier approved version. It is recorded like any change; nothing is rebuilt, because every earlier version is still stored. Going back uses the same steps as going forward.

A new customer needs an environment

Add one short file describing it to the environment repository and run the environment pipeline. It creates the private spaces and access to secrets, then installs the products. No new build.

One setting must change in one place

Change it in that environment's file. The environment pipeline applies it; the product package stays the same.

Someone pastes a password into a settings file

The checks reject anything that looks like a credential, and the release stops before it reaches any environment. The password goes into Key Vault; the file keeps only its name.

The safety nets

A missing "$required" setting stops the release.
Credential-like values and unlisted secret names are rejected.
Only versions that ran well in test are approved.
Promotion takes approved versions only, and every production change is a recorded commit.
Parts are published in a fixed order, the application last, so a half-finished run is never picked up.
Fingerprints prove the deployed package is the tested one; versions are never overwritten.

Questions

How do we know exactly what runs in production?

Production's file in the environment repository names one approved version of each product. Its composition lists every component with exact versions and fingerprints.

How long does a fix take to reach a test environment?

Usually within about 30 minutes of the service being built: the product pipeline checks every 30 minutes and test environments pick the candidate up right after. Production is a business decision, not a timer.

What is a release number?

A human-friendly number such as 1.4.0 given to an approved version for QA and customers. The contents are identical; nothing is rebuilt. Deploying a release number to qa is planned.

Where are the stored versions kept?

Deployable packages are in the Azure container registry; compositions are in GitHub Packages, next to the product repository.

Glossary

Service: One working part of a product, owned by one team.
Repository: A versioned folder on GitHub; every change records who, when and why.
Container image: A program packaged ready to run.
Service chart: A team's services packaged with their run instructions and a version number.
Platform chart: The shared template every service chart is built from (platform-services).
Component: One deployable part of a product: the application (helm), data pipelines (adf) or analytics (databricks).
Product version: All components at one version, deployed together.
Version number: The build's date and time, YYYYMM.D.HHMMSS, for example 202610.17.093512.
Composition: The record of a product version: every component, its version and fingerprint. Every deployment reads it first.
Digest: A fingerprint of a package; change one byte and it changes.
Candidate: A new product version, ready to be tried in test environments.
Approved: A version that ran well in the first test environment and may be promoted.
Release number: A human-friendly number (1.4.0) given to an approved version; same contents.
Promote: Write an approved version into a later landscape's environment files, through a recorded change.
Environment: One place a product runs, such as app01, with its own addresses, data and keys.
Landscape: A family of environments that share rules: dev, qa, prod.
Namespace: A walled-off space for one product in one environment.
Flux: The controller in each environment that keeps it on the version it was told to run.
Track / pin: Track: follow the newest candidate (test). Pin: stay on one chosen version (later landscapes).
Settings (values): What differs from place to place, layered from general to specific.
Secret: A password or key. Only in Azure Key Vault; files hold names.
Product pipeline: Combines, tests, approves and promotes product versions (in the product repository).
Environment pipeline: Creates and updates environments and installs their products (in cloud-config).