ReleaseTwin

Case files

A case is a YAML file describing one release-critical check: what to run, what fixture it depends on, how to tell pass from fail, and how to clean up.

Anatomy

cases/example.yaml
id: MY-CASE-2
release: "4.2"                      # optional — groups this case in the release rollup
oracle:
  locator: tickets/MY-CASE-2        # where the human-readable expectation lives
fixture:
  locator: my-fixture.json          # resolved in a fixtures/ dir next to cases/
  sha256: <sha256 of the fixture file>
requires:
  - http:azure-devops               # capabilities this case needs installed
preconditions:
  - check: azdo.areaPathExists
    owner: QA claims fixtures        # who owns fixing this if it's not satisfied
pipeline:
  - operation: azdo.createWorkItem
  - operation: azdo.getWorkItem
cleanup:
  - operation: azdo.deleteWorkItem
resource_key: 'TeamProject\Area'    # optional — serializes cases sharing this key

Blocks

  • oracle.locator — a reference to where the expected behavior is documented. Carried through into every report.
  • fixture — a locator plus a SHA-256. The file is read locally and hashed before the pipeline runs; a mismatch fails the case immediately.
  • requires — capability strings that must be provided by an installed adapter, or the case reports missing-capability rather than crashing.
  • preconditions — three-state checks (satisfied / not satisfied / inconclusive), each naming an owner.
  • pipeline — ordered operations. State from one step (an ID, a token) is available to later steps and to cleanup.
  • cleanup — runs even if the pipeline fails; no-ops safely when there is nothing to undo.
  • resource_key — optional; cases sharing a key run serially instead of in parallel.
  • release — optional free-form label (a version, a sprint, an epic key). It has no effect on execution; the hosted platform groups cases by it into a per-release readiness rollup.

Operations available today

  • Generic HTTP (any REST API): http.request, http.assertJsonPath — fully data-driven from the case file.
  • Azure DevOps (fixed-shape): azdo.createWorkItem, azdo.getWorkItem, azdo.transitionWorkItemState, azdo.areaPathExists, azdo.deleteWorkItem, azdo.readFeatureVariable.
  • UI (Chromium via Playwright, opt-in with RELEASETWIN_UI_ENABLED=1): ui.navigate, ui.click, ui.fill, ui.waitFor, ui.assertVisible, ui.setCookie.

Flag proof

Add a flag_proof block to a case that also has a feature-state adapter configured. The CLI runs the case twice — once with the feature off, once on — and reports a single discriminating outcome instead of a plain pass/fail.

added to any case
flag_proof:
  feature_key: release-proof-feature   # the flag to toggle
  build_identity: build-123            # carried through the report

The outcome is Passed when the case's own pipeline correctly tells known-bad from known-good — or WeakOracle / BothFailed / Inverted / Ineligible when it can't. Today only Azure DevOps's variable-group controller can drive the toggle.

Next

Connect the hosted platform to keep run history and turn on the evidence viewer.