# Separate release identity from feature exposure

Deploying code and enabling behaviour are related but different actions. Track both so an operator can tell what a request actually experienced.

By Cobnex editorial. Published 2026-09-10. Updated 2026-09-11.

## Name the two controls

A deployment selects an application build. A feature flag or routing rule selects which behaviour a caller receives. Either can change without the other.

Record the build and exposure configuration in diagnostics. If support only knows the current deployment version, it may be unable to reproduce a customer issue caused by a targeted flag.

Keep the flag's owner and removal condition close to its definition. Temporary release controls should not become undocumented product configuration.

## Choose a stable cohort rule

For a workflow spanning several requests, consider whether the same user or account should remain on one behaviour during the exercise. Per-request random assignment can create inconsistent steps if the two versions do not interoperate.

```json
{
  "release": "booking-example-42",
  "feature": "revised-delivery-estimate",
  "cohortKey": "account",
  "exposureStage": "pilot",
  "minimumRelevantObservations": 200,
  "onMissingTelemetry": "hold"
}
```

These are illustrative policy fields, not a configuration for a particular tool. The observation threshold must come from the behaviour and traffic being assessed rather than copying the example number.

Keep cohort assignment free of unnecessary personal information in logs. An internal stable identifier is usually more appropriate than an email address.

## Wire the decision to relevant evidence

Measure errors and task latency by release and exposure stage. Add a check that addresses the change itself, such as a known estimate calculation or a valid workflow transition.

Define success, failure and inconclusive outcomes. Configure missing data and monitoring errors deliberately so a broken analysis path does not promote the release.

Test the policy using synthetic metric results before relying on live automation. A reversed comparison operator can turn a carefully chosen threshold into the wrong action.

## Verify disabling and rollback separately

Turn the feature off while keeping the new build deployed and confirm the intended behaviour. Then test returning to the stable build where supported.

Inspect data written while exposure was enabled. The old behaviour must interpret it correctly or use the documented recovery path.

Record which control the operator should use for each failure. Disabling a feature may be the fastest safe response, while a process crash may require deployment rollback. Clear separation makes incident action more precise.

## Sources

- [Argo Rollouts: analysis](https://argo-rollouts.readthedocs.io/en/stable/features/analysis/)