Skip to content

Release and Supply Chain

The release workflows build binaries, container images, checksums, SBOMs, and provenance attestations for tagged component releases. Treat these files as release evidence, not as a substitute for environment-specific deployment review.

Release Evidence

For each release, keep:

  • Git tag and commit SHA.
  • Release notes with compatibility notes and rollback guidance.
  • Binary archives and checksums.txt.
  • Container image tag and digest.
  • SBOM file generated by Syft.
  • GitHub build provenance attestation.
  • Any migration or config changes required by the release.

Compatibility Policy

  • Patch releases should preserve API, artifact, and config compatibility.
  • Minor releases may add fields, endpoints, metrics, artifact kinds, or config options in a backward-compatible way.
  • Breaking changes require explicit release notes, migration steps, and rollback notes.

Image Signing

The workflows already request OIDC and provenance permissions. If your deployment requires signed images, add a signing step in the release workflow after image push and before deployment promotion. Keep the signature verification policy in the target cluster or admission controller, not in application code.

Upgrade Checklist

  1. Read release notes and migration notes.
  2. Render Helm values with the target image tag.
  3. Confirm secrets and production validation requirements.
  4. Run the pipeline against a non-production tenant/surface and keep the previous manifest.
  5. Run evaluation and load-test gates.
  6. Promote service and manifest separately so each rollback lever remains clear.