Challenge 1: Add a Rollback Job for Staging — Possible Solution
====================================================================

  deploy-staging:
    needs: build-and-push
    runs-on: ubuntu-latest
    environment: staging
    steps:
      - run: ./deploy.sh staging ${{ github.sha }}
      - run: curl -f https://staging.example.com/health || ./rollback.sh ${{ github.sha }}

WHY THIS WORKS
--------------
- This mirrors deploy-production's own pattern EXACTLY: curl -f ...
  || ./rollback.sh ${{ github.sha }} — curl's -f flag makes it return a
  non-zero exit code if the HTTP response is a failure status (like
  4xx/5xx), and the || operator means rollback.sh only runs if that
  curl command actually failed.
- Passing ${{ github.sha }} to rollback.sh gives the rollback script
  the exact same traceable identifier used throughout this capstone's
  pipeline (Chapter 6's SHA-tagging) — the script can use this to know
  specifically which deployment attempt just failed and needs reverting,
  consistent with how the same variable is used identically in
  deploy-production.
- Adding this to staging (not just production) matters because,
  without it, a broken staging deploy would sit broken indefinitely,
  with no automatic recovery — someone would have to manually notice
  and fix it. Since deploy-production depends on deploy-staging
  succeeding (needs: deploy-staging), a staging environment stuck in a
  broken state could also block the entire pipeline from ever reaching
  the production approval gate at all, making this fix relevant to more
  than just staging's own health.
- This directly follows Chapter 7's own point that "regardless of
  strategy, a robust pipeline defines a health check... and
  automatically rolls back... if that check fails" — the chapter's
  guidance was never staging-specific or production-specific, it
  applies to any environment being deployed to, which is exactly why
  this gap existed in the original capstone workflow and is worth
  fixing here.