# From a Green Suite to a Release

A green behavioral suite supports release when its evidence belongs to the build being advanced. Preserve execution receipts and verify deployed capabilities, configuration, and other release duties.

Published: 2026-06-15
Updated: 2026-09-27
Source: https://matlus.com/writing/from-a-green-suite-to-a-release/
Tags: acceptance-testing, verification

---
The required suite is green. The team has established the business requirements,
acceptance criteria, functional requirements, and non-functional requirements
and verified that its scenarios and expectations correctly cover them. The
assembled system has produced the required outcomes through the selected real
infrastructure and stable downstream arrangements.

> **About the examples:** Meridian Ordering is a private training reference project. The inline listings illustrate the techniques; the full C# and Python repositories are not currently public.

That is the confidence to go to production this discipline is designed to give
the team. The release process must preserve that evidence and address its other
responsibilities explicitly.

## Give the green result its prerequisites

Before advancing the build, verify that:

- Reviewed obligations are represented by the required scenarios.
- Arrangements still create the named conditions and expectations remain correct.
- The required suite passed for the build being advanced.
- The execution environment and provider choices are recorded.
- No required comparison was removed merely to obtain a green result.

The [completeness article](/writing/knowing-which-scenarios-a-feature-requires/) explains the
review, and [infrastructure](/writing/testing-against-real-infrastructure/) explains the
arrangements. Source inspection, local execution, CI execution, and deployed
verification are distinct evidence. Keep their receipts tied to the relevant
version rather than treating the most recent passing run as proof for any build.

## Assign the remaining release responsibilities

> Diagram: The green suite supplies the reviewed behavioral evidence for the build. Assign other release responsibilities explicitly, verify environment readiness, and return production lessons to the maintained suite.

| Responsibility | Evidence needed |
| --- | --- |
| Behavioral readiness | Correct required scenarios passing through the assembled system |
| Release configuration | Intended artifacts, settings, secrets, migrations, and provider choices |
| Deployed environment readiness | Required dependencies and capabilities available after deployment |
| Capacity and resilience | Required limits and recovery behavior under their specified conditions |
| Security and access | The release's required controls and review evidence |
| User experience | Intended human workflow and its acceptance |

Behavioral non-functional obligations belong in the appropriate scenarios too.
Bounded email reads, safe diagnostics, and concurrent reference handling are
examples in Meridian. Sustained-load capacity and production environment health
require additional arrangements and observations appropriate to those conditions.

The release gate needs business backing. Under schedule pressure, a known failed
obligation cannot become verified because the date is approaching. A business
decision to change scope or accept a risk must remain explicit rather than
being hidden by weakened assertions.

## Use onboard diagnostics for environment readiness

In systems I worked on, onboard diagnostics checked environment readiness after deployment.
These were a separate operational capability deployed with the system, used by
infrastructure, QA, and operations. They checked specific dependency capabilities
required by the application.

Infrastructure could run them after deployment. QA could check readiness before
beginning work. Operations could ask whether the required dependencies were
usable at that moment. Encoding those checks preserved operational knowledge
that otherwise stayed in individual engineers' memories.

One incident I encountered involved newly introduced tables and stored
procedures disappearing after a faulty nightly backup process restored an older
database. Diagnostics identified the missing artifacts. That is my experience
from another deployed system, not a diagnostics implementation claimed for Meridian.

A useful readiness check asks whether the deployed application can exercise a
specific required capability with controlled inputs and interpret its result.
Design its effects and permissions deliberately. Reaching a database port alone
does not establish that the necessary procedure or schema version exists.

Boundary tests verify the build's required behavior before release. Deployment
diagnostics verify the environment available after deployment. Those jobs happen
at different times and often have different owners.

## Keep configuration fidelity visible

Meridian's hosted tests retain the real domain but replace facade registration
with the testing service locator. Its CI workflow uses SQL Server and RabbitMQ.
Those runs establish behavior for those arrangements; they do not certify
every production setting or a different configured provider.

Use the intended infrastructure at the final gate where it is stable enough for
testing, and separately verify deployed configuration and dependency capabilities.
Record migrations and topology as part of release readiness. A provider switch
needs execution evidence for that provider rather than an assumption that
another adapter's green run supplies it.

## Use production observation without making customers the first check

Monitoring, canaries, and gradual exposure can reveal production-only conditions.
They complement the pre-release suite. A canary has already exposed some callers;
it cannot supply the before-exposure evidence missing from an unverified feature.

Rollback also has limits. Restoring old application code does not unsend an email,
withdraw a fulfillment instruction, or remove every record already consumed by
another system. Recovery and compensation need explicit policies and verification.
The [ambiguous completion scenario](/writing/refusals-failures-and-work-still-owed/#observe-acceptance-when-completion-recording-fails)
shows why durable state and an external effect can disagree.

## Return production lessons to the maintained suite

When a production-only condition reveals a behavioral obligation, establish its
requirement and preserve a scenario with the right arrangement and assertions.
When the failure was environmental, improve deployment readiness or diagnostics.
When capacity or recovery limits were wrong, update the corresponding requirements
and verification.

The release argument then remains understandable: the required behavior has
been verified, the deployment and environment have their own evidence, and
discovered lessons improve the next release. The team can take responsibility
for what it sends to production because those decisions are explicit.

---

[Previous article](/writing/refactoring-and-adopting-boundary-testing/) | [Series contents](/acceptance-testing/) | [Next article](/writing/questions-about-functional-acceptance-testing-at-the-boundary/)