Team A merges to trunk nine times a day and ships to production once a month after a three-day release-branch stabilisation. Team B deploys every merge automatically, about thirty times a day. Both tell an auditor they practise continuous delivery. Which claim survives a test, and what is the test?

What is being tested

Whether you can separate deployment frequency, which is an output, from releasability, which is the property being claimed. Most people answer by comparing the two numbers, and the numbers are not the discriminator.

The mechanism

Continuous delivery is a property of the trunk: every commit produces an artifact that could be released now, and the decision to release is a business decision rather than an engineering project. Continuous deployment is the narrower practice of making that decision automatic.

Team B's thirty deploys a day prove releasability, because they exercise it thirty times. Team A's monthly release does not disprove it, and the three-day stabilisation does. Stabilisation time is the honest measure of how far trunk sits from releasable. Those three days exist because a month of changes has accumulated into one batch, so the first failure in the batch is ambiguous: with 300 changes in flight, bisecting is the only way to attribute a regression, and the cost of that search is why the window is three days rather than three hours.

The test that settles it

Pick a green build from the last 24 hours at random and release it, now, without preparing it. Record two numbers: elapsed minutes, and manual steps that are not in the pipeline. A team whose answer is "we would have to run the release checklist first" has a release process, not continuous delivery. Team A will discover that its artifact cannot be released without the stabilisation work, which means the claim fails on the artifact it actually produces, not on its cadence.

The same test is what an auditor should ask for, because it is observable. "We practise continuous delivery" is not.

When continuous deployment is the wrong target

Releasability is always worth having. Automatic release is not.

• An external gate sets the floor. Mobile app review takes roughly a day or two, so a mobile client is continuous delivery behind a train, whatever the server does.
• Customers pay a per-release cost. Installed software with migration notes and retraining cannot ship thirty times a day into a customer's change window, however healthy trunk is.
• A change class has no rollback. Where the only reversal is a restore from backup, the release decision belongs to a human who has read the change.

The decision rule: make trunk releasable always, and automate the release only for the change classes whose reversal is cheap and whose failures are loud.

Common weak answers

• "Team B is more advanced, it deploys more often." Frequency follows from releasability and is easy to fake: a team can deploy thirty times a day behind a flag that nothing reaches, and the flag debt is a separate problem.
• "Continuous delivery means the tests are automated." Automated tests are a prerequisite. The claim is about the state of the artifact, and a team with a large suite and a three-day stabilisation window has the tests and not the property.
• "Team A has a pipeline, so it qualifies." The pipeline is the mechanism. The property is whether its output is deployable without further work, which is why the question has an answer you can measure in minutes.