Technical blueprint, not a client delivery

Designing releases around the artifact that passed testing

A release is harder to trust when the deployed artifact differs from what was reviewed or rollback ignores database changes.

This blueprint builds and tests an artifact once, then promotes that digest through explicit security and approval gates. It adapts identity and rollback behavior to five CI platforms.

The design would promote the tested artifact through explicit approvals and treat database compatibility as a separate release concern.

Teams often inherit a pipeline platform, but the failure modes are shared: long-lived cloud keys, mutable image tags, infrastructure plans that differ from what was approved, and rollback procedures that ignore database compatibility.

A pipeline blueprint that builds once, scans code and images, promotes by digest, ties Terraform apply to an approved plan, and defines rollback boundaries.

One artifact, explicit authority at each gate

The same tested digest advances only after source, scan, infrastructure and production controls pass.

The same tested digest advances only after source, scan, infrastructure and production controls pass.

OIDC claims, runner trust, approvals and secret mechanisms vary by CI provider; the implementation must use that provider’s actual guarantees.

  • Promote: Pull request: Protected branch checks run without cloud credentials for untrusted contributions. → Build and scan: Tests, code and dependency scans run; one versioned image and SBOM are produced. → Review infrastructure: Policy checks evaluate a saved Terraform plan tied to the same commit and inputs. → Deploy by digest: The staged image digest is promoted to an approved production canary.
  • Recover: Abort canary: Failed latency or error analysis returns traffic to the stable version. → Revert application: A later issue deploys the previous known digest, provided database compatibility remains. → Correct infrastructure: Terraform changes are reverted forward through a new reviewed plan, not an assumed undo.
  • Source controls: Protected pull requests require checks; untrusted fork workflows receive no cloud credentials. GitHub Actions, CircleCI, Bitbucket Pipelines, Jenkins, Azure Pipelines
  • Build and scan: Code and dependencies are scanned; a versioned image is built once and inspected before promotion. Unit tests, Static analysis, Dependency scan, Image scan, SBOM
  • Infrastructure approval: Terraform plans are policy-checked and saved against the commit and inputs that received approval. Terraform plan, Policy check, Plan artifact, Manual approval, S3 state
  • Short-lived identity: Each platform uses its supported OIDC federation or workload identity mechanism to assume a scoped AWS role. OIDC, Scoped roles, Staging boundary, Production approval
  • Progressive production release: A digest-pinned deployment advances through a canary with metrics-based analysis and a defined rollback path. Amazon ECR, Image digest, Argo Rollouts, CloudWatch
  • How do we know production runs what passed staging? Rebuilding or moving a mutable tag between environments can change the artifact after testing. Build once, use immutable versioned images and promote by digest. The production artifact can be tied to the exact content tested and the commit that created it.
  • What if Terraform inputs change after approval? A saved approval is invalid if the commit or inputs no longer match the reviewed plan. Bind the plan artifact to the exact revision and regenerate review when either changes. The apply remains coupled to the change that received approval.
  • Can every release be rolled back the same way? Application code, database schema and infrastructure have different state and compatibility constraints. Use traffic rollback for a canary, digest redeployment for an application, expand-and-contract for schema, and a new reviewed Terraform apply for infrastructure. Recovery is explicit at each layer; no automatic database down-migration or Terraform undo is assumed.

The operational failure modes this design addresses.

Security gates that fail on low-value findings encourage bypasses; calibrate enforcement to actionable severity and retain expiring exceptions. Self-hosted runners add network control and maintenance responsibility. Canary rollback depends on user-impacting signals. Expand-and-contract takes more releases but protects compatibility.

  • Trusted artifact: Promote what was tested. Build once, record a version and commit, then move the same immutable image digest from staging to production.
  • Change control: Apply the reviewed infrastructure plan. Save a Terraform plan tied to the commit and inputs; if those change, generate and review a new plan instead of applying stale approval.
  • Recoverable release: Make rollback match the failure layer. Canary rollback moves application traffic, application rollback uses a known digest, database changes remain backward compatible, and infrastructure changes are corrected forward through a new plan.
  • Protected branches, build and scan checks, and no cloud credentials on untrusted fork workflows.
  • Semantic version and commit are attached to one immutable image; environments promote that image by digest.
  • Policy-checked Terraform plans are saved against a commit and inputs; changed inputs require a new plan and approval.
  • Argo Rollouts can abort a canary on observed signals, while database compatibility and forward-only infrastructure correction are handled separately.

How the system is intended to work.

A pipeline blueprint that builds once, scans code and images, promotes by digest, ties Terraform apply to an approved plan, and defines rollback boundaries.

  • Required source checks: Protected branches, build and scan checks, and no cloud credentials on untrusted fork workflows.
  • Artifact provenance: Semantic version and commit are attached to one immutable image; environments promote that image by digest.
  • Reviewed infrastructure: Policy-checked Terraform plans are saved against a commit and inputs; changed inputs require a new plan and approval.
  • Layer-specific rollback: Argo Rollouts can abort a canary on observed signals, while database compatibility and forward-only infrastructure correction are handled separately.
  • Source controls: Protected pull requests require checks; untrusted fork workflows receive no cloud credentials. GitHub Actions CircleCI Bitbucket Pipelines Jenkins Azure Pipelines
  • Build and scan: Code and dependencies are scanned; a versioned image is built once and inspected before promotion. Unit tests Static analysis Dependency scan Image scan SBOM
  • Infrastructure approval: Terraform plans are policy-checked and saved against the commit and inputs that received approval. Terraform plan Policy check Plan artifact Manual approval S3 state
  • Short-lived identity: Each platform uses its supported OIDC federation or workload identity mechanism to assume a scoped AWS role. OIDC Scoped roles Staging boundary Production approval
  • Progressive production release: A digest-pinned deployment advances through a canary with metrics-based analysis and a defined rollback path. Amazon ECR Image digest Argo Rollouts CloudWatch

Test the boundaries before relying on the design.

The following checks define evidence to collect before implementation is accepted. None is represented as already run.

  • Required source checks: Protected branches, build and scan checks, and no cloud credentials on untrusted fork workflows.
  • Artifact provenance: Semantic version and commit are attached to one immutable image; environments promote that image by digest.
  • Reviewed infrastructure: Policy-checked Terraform plans are saved against a commit and inputs; changed inputs require a new plan and approval.
  • Layer-specific rollback: Argo Rollouts can abort a canary on observed signals, while database compatibility and forward-only infrastructure correction are handled separately.
  • Credential boundary: Confirm a pull request from a fork receives no cloud credentials and staging cannot assume the production role.
  • Plan integrity: Change an input after approval and confirm the pipeline refuses the saved plan and requires a new review.
  • Artifact continuity: Verify the digest running in production is the same image tested in staging and traces to its source commit.
  • Canary abort: Inject a failing latency or error signal and verify traffic returns to the stable version.
  • Database rollback compatibility: Deploy and revert an application version while verifying the schema remains compatible without a down-migration.
  • No measured performance, cost, recovery or compliance outcome is published for this project.

A design that makes operational boundaries reviewable.

The intended value is a release path in which the deployed image and infrastructure plan match what was reviewed. Application rollback still depends on compatible database changes and tested signals. No measured performance, cost, recovery or compliance outcome is published for this project.

  • Preserve artifact identity: Digest-pinned promotion would keep staging and production tied to the same tested image.
  • Make approval meaningful: A saved Terraform plan would be invalidated when its source revision or inputs change, requiring a new review.

Review the constraints before selecting the implementation.

Start with workload limits, owners and failure behavior. Then turn the validation plan into environment-specific tests and acceptance criteria.