Skip to content

release-process.md

Latest commit

 

History

History
50 lines (38 loc) · 2.48 KB

release-process.md

File metadata and controls

50 lines (38 loc) · 2.48 KB

Release Process

This project is built for interview storytelling, so the release model is intentionally simple while still demonstrating real governance controls.

Branching Strategy

  • main remains the source of truth for production-ready code.
  • Feature work happens on short-lived branches named feature/<topic> or fix/<bug>.
  • Pull requests into main require:
    • At least one reviewer approval.
    • Passing CI (lint → tests → CDK synth).
    • Clear summary highlighting risk, blast radius, and rollback plan.

Version Tagging

  • Semantic tags (vMAJOR.MINOR.PATCH) are created from main after a successful deploy run.
  • Tags are lightweight markers for demo purposes, enabling quick rollbacks.
  • Tagging workflow:
    1. Ensure main is green (CI successful, manual checks complete).
    2. Run the Deploy workflow with execute_deploy=false to dry-run packaging + synth.
    3. Trigger a second Deploy workflow with execution enabled once stakeholders approve.
    4. Create the release tag locally: git tag vX.Y.Z && git push origin vX.Y.Z.

Promotion Workflow

  1. Merge feature branch into main once CI is green.
  2. Trigger Deploy workflow via GitHub UI:
    • Select environment (dev, staging, or prod).
    • Decide whether to upload the model artifact (upload_artifacts).
    • Leave execute_deploy unchecked for dry-run validation.
  3. Review the workflow logs and generated stack diff.
  4. If approved, rerun Deploy with execute_deploy=true (requires the THREAT_DEPLOY_CONFIRM=I_UNDERSTAND_THE_COST guardrail).
  5. Capture outcomes in the runbook (success/failure, metrics, follow-up actions).

Rollback Expectations

  • Every deploy run produces the CDK diff and artifact bundle, so cdk deploy is always repeatable.
  • Rollback path is documented separately in the rollback playbook; typically it involves redeploying the previous tag or switching the SageMaker endpoint to the prior model package.
  • Tags and Deploy logs provide the audit trail needed for post-incident reviews and interview explanations.

Communication & Approvals

  • Dev/staging runs require at least a peer reviewer; prod runs require an additional stakeholder sign-off (e.g., team lead).
  • Include a summary in the PR or GitHub Deployment conversation covering:
    • Intended change.
    • Risk/mitigation (e.g., alarms, Model Monitor coverage).
    • Rollback plan.

This process demonstrates that even interview scaffolding can uphold enterprise governance: approvals, cost acknowledgements, and auditable releases.