Lesson 117 — Advanced

CI/CD with GitHub Actions

Commit se deploy tak ka raasta automate hona chahiye — warna release ek insaan ki yaad par chalegi. Is lesson mein hum tests → eval gate → build wala order, commit-tagged images, pipeline secrets, staging auto aur production manual approval, aur rollback ko redeploy banaana dekhenge.

Pipeline kyun — order hi safety hai

Pipeline ka asli design decision order hai: sabse sasta check pehle (unit tests), phir mehnga (eval gate), phir build. Ulta kiya toh har chhoti typo ke liye bhi eval ka kharcha uthaoge. Aur yaad rakho — prompt change bhi isi pipeline se hi jaata hai, koi alag rasta nahi.

Workflow — tests, gate, build

# .github/workflows/ci.yml (conceptual)
name: ci
on:
  pull_request:
  push:
    branches: [main]

jobs:
  test-and-gate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Install pinned deps
        run: pip install -r requirements.txt
      - name: Unit tests
        run: pytest tests/unit -q
      - name: Eval gate (fast subset)
        run: pytest tests/eval -q
        env:
          PROVIDER_API_KEY: ${{ secrets.PROVIDER_API_KEY }}
      - name: Build image
        run: docker build -t registry.example/app:${{ github.sha }} ./backend
      - name: Push
        if: github.ref == "refs/heads/main"
        run: docker push registry.example/app:${{ github.sha }}

• github.sha se image tag commit se jud jaata hai — "kaunsa code chal raha hai" ka seedha jawab.
• Gate fail hua toh build/push steps kabhi chalte hi nahi — yahi order ka fayda.
• Fork PRs pe secrets available nahi hote — pull_request pe eval job ko skipped ya read-only rakho.
• Cache karo dependencies (aur eval dataset) — har push pe sab fresh install karna pipeline ko slow karta hai.
• Eval job ka report (kaunse metric fail) PR pe dikhao — warning ka intezar mat karao.

Pipeline secrets

• Provider keys aur registry credentials sirf CI secrets mein — repo mein kabhi nahi, log mein kabhi nahi.
• Secrets ko explicitly env mein pass karo — koi step utha ke print kar de toh mask laga ho (CI aksar khud mask karta hai, par dhyan phir bhi).
• Fork wale PRs: secrets bilkul mat do — untrusted code ko key mil gayi toh bill aur leak dono.
• Registry push ke liye short-lived credentials better hain — permanent token kabhi leak ho toh poora fleet khula.
• Rotation ek ritual banao: token ki expiry ho, rotation procedure likha ho, kisi ki yaad par nahi.

secret ka life-cycle:

banaya (dashboard/CLI) -> CI mein add -> workflow env se use
         |                                   |
         |                        print attempt -> masked logs
         |
rotate: naya banao -> CI update -> purana delete
         # aur: kabhi bhi log dump mein secret na dikhe — audit karke dekho

Manual approval aur rollback-to-tag

push (main)
  -> tests -> eval gate -> image:${sha} push
  -> staging deploy (automatic, har main push)
  -> staging smoke + eval on live config
  -> approval gate (insaan)  --- reject? -> wapas ek fix commit
  -> production deploy (same image tag)

rollback = production ko image:${purana_sha} dobara deploy
           # rebuild nahi — wahi bit-for-bit image, known behaviour

• Staging automatic, production manual — speed aur caution dono: har change turant staging pe, production pe ek insaan ki signature.
• Approval ke paas hona chahiye: last eval report, config diff, aur pichhli release ka comparison.
• Rollback = purane known tag ka redeploy. Naya build karna rollback nahi, ek aur experiment hai.
• Prometheus mein kaunsa tag production pe hai wo bhi ek metric ho — dashboard se pata chale aaj kya chal raha hai.
• Purane images ko delete mat karo jab tak unka rollback window chalu hai — retention policy likh do.

Exercise

Common mistakes

• Order ulta rakhna — pehle build, baad mein gate: Har typo pe mehnga eval + build chal gaya. Fix: sasta check pehle (unit tests), gate beech mein, build last.
• Secrets YAML mein likh dena: Repo history ke saath key sabke paas. Fix: CI secrets + masked env, fork PRs ko kabhi nahi.
• Production bina approval ke deploy: Automated acha hai, par production pe ek insaani review last line of defense hai. Fix: staging auto, production manual approval.
• Rollback ke liye rebuild karna: Naya build = naya behaviour possibility — rollback ka point hi khatam. Fix: known commit tag wali image hamesha deployable rakho.

print bana (build, tag: commit sha)
censor pass (tests + gate)
premiere (staging auto)
insaani approval (manual gate)
release (same print, production)
recall (rollback = purana print dobara)