🖼️ See the drawing + lab 🏠 Course home 🌿 Branch on GitHub ✏️ View source

🖼️ आकृती आणि labThe drawing + lab पूर्ण पानावर उघडा ↗Open full page ↗

🧹 धडा 12 — Pipeline hygiene & हस्तांतर: mailroom चे नियमपुस्तक

📍 तुम्ही इथे आहात: 12 पैकी धडा 12 — शेवटचा धडा! · मागील: lesson-11-four-dialects

🔗 पुढे: ArgoCD शाळेचा धडा 01 नेमका इथे हा धडा संपतो तिथून सुरू होतो.

📦 या ब्रँचमध्ये काय आहे

सगळे 12 धडे — संपूर्ण कोर्स. शेवट म्हणजे mailroom च्या भिंतीवरचे poster: नवलाई ओसरल्यानंतरही courier विश्वासार्ह ठेवणाऱ्या सवयी, एक प्रामाणिक गुणफलक, हा संपूर्ण कोर्स सोडवू शकत नाही अशी एक समस्या, आणि तुमची पदवी परीक्षा. खऱ्या files: सगळ्याच — आधीपासून असलेल्या hygiene च्या ओळी खाली दाखवल्या आहेत.

🧒 5 वर्षांच्या मुलाला समजावल्यासारखे

Courier robot चालतो. आता शाळा नियमपुस्तक poster 🧹 लिहिते, म्हणजे तो पुढच्या वर्षीही चालत राहील, जेव्हा तो कोणी set up केला ते कोणालाच आठवणार नाही:

फक्त मंगळवारी fail होणारी test ही test नाही 🎲 — ती वेगळी काढा, दुरुस्त करा, पास होईपर्यंत फक्त retry करू नका. Retries सडणे लपवतात.
तुम्ही नेमकी कोणती tools कामावर ठेवली ते जाणून घ्या 📌 — actions, orbs आणि base images एका fingerprint वर pin करा (commit SHA किंवा image digest), म्हणजे "v4" तुमच्या नकळत गुपचूप बदलू शकणार नाही.
Robot ला चालणारी सर्वात छोटी key द्या 🪪 — प्रत्येक workflow आणि job साठी permissions:, आणि master keys नाहीत (धडा 06).
मुख्य फलकाला कुलूप लावा 🔒 — हिरवा check आणि review शिवाय main वर काहीही उतरत नाही; pushes उतरण्याआधी secrets साठी scan करा.
पावत्या ठेवा 🧾 — lockfile सांगते आत काय गेले; build provenance सांगते ते कोणी build केले, कोणत्या commit वरून, कोणत्या pipeline ने.
घड्याळ लावा ⏱️ — अडकलेला job fail झाला पाहिजे; नवा push जुना run रद्द करायला हवा.

आणि एक गुणफलक 📊 जो दिखाऊ आकडा नाही: तुम्ही किती वेळा deliver करता, एखादा बदल किती वेळ वाट पाहतो, delivery किती वेळा काहीतरी मोडते, तुम्ही ते किती पटकन दुरुस्त करता. प्रामाणिकपणे मोजलेले चार आकडे कोणत्याही dashboard पेक्षा सरस.

🗺️ आकृती

flowchart TB
    flaky["🎲 flaky tests<br/>quarantine → fix"]
    pin["📌 pin actions, orbs, images<br/>SHA or digest"]
    perm["🪪 least privilege<br/>permissions: per job"]
    lock["🔒 protect main<br/>required checks + review"]
    prov["🧾 lockfiles + provenance<br/>SLSA, attestations"]
    clock["⏱️ timeout-minutes<br/>concurrency"]
    dora["📊 DORA: frequency · lead time<br/>failure rate · restore time"]
    argo["🤖 ArgoCD school<br/>drift, self-heal, git as truth"]
    flaky -->|"1"| dora
    pin -->|"2"| dora
    perm -->|"3"| dora
    lock -->|"4"| dora
    prov -->|"5"| dora
    clock -->|"6"| dora
    dora -.->|"7 what push cannot fix"| argo

❓ काय

Flaky test = त्याच commit वर कधी पास तर कधी fail. ती वेगळी काढा (ticket सह skip करा), कारण दुरुस्त करा (timing, shared state, network), मग पुन्हा चालू करा. आपोआप retries मुळे आकडा बरा दिसतो आणि समस्या अदृश्य होते.
Pinning = dependency चा उल्लेख अशा गोष्टीने करणे जी हलू शकत नाही: action साठी पूर्ण commit SHA, orb साठी नेमके x.y.z, image साठी sha256: digest. मग Dependabot किंवा Renovate pin पुढे सरकवतात, एका diff सह जो तुम्ही review करता.
Least privilege = प्रत्येक workflow च्या सुरुवातीला permissions: (default read-only) आणि id-token: write फक्त जिथे badge लागतो तिथेच.
Branch protection = required status checks हिरवे आणि review असेल तरच main merges स्वीकारते. Push protection सह secret scanning ओळखीच्या credential च्या आकाराचा मजकूर असलेला push उतरण्याआधीच अडवते (उपलब्धता plan वर आणि repo public आहे का यावर अवलंबून).
Lockfile = build मध्ये गेलेले नेमके dependency tree (या app मध्ये एकही नाही, कारण तिला dependencies नाहीत). Build provenance = artifact कसे build झाले याचे सही केलेले निवेदन; ते निवेदन किती भक्कम आहे याचे स्तर SLSA ठरवते; actions/attest-build-provenance असे एक निवेदन तयार करते.
timeout-minutes / concurrency = job किती वेळ अडकू शकतो याची कमाल मर्यादा, आणि नवा run जुन्याची जागा घेतो असा नियम.

🧠 गुणफलक — DORA चे चार metrics

metric	विचारतो	या कोर्समधला उपाय
deployment frequency	व्हॅन किती वेळा production पर्यंत पोहोचते?	छोटे बदल, कंटाळवाणी pipeline
lead time for changes	commit → production मध्ये चालू: किती वेळ?	वेगवान CI (L04), आपोआप deploy (L10)
change failure rate	किती टक्के deliveries ना fix किंवा rollback लागतो?	BOX वर tests (L07), आधी staging (L08), probes (L09)
time to restore service	बिघडले तर पुन्हा चालू व्हायला किती वेळ?	कालचा tag पुन्हा deploy करा (L09)

इथे जाणूनबुजून कोणतेही लक्ष्य-आकडे नाहीत: चांगले कशाला म्हणायचे ते team वर अवलंबून असते, आणि प्रकाशित संशोधन दरवर्षी बदलणाऱ्या श्रेणी सांगते. तुमचे स्वतःचे चार मोजा आणि कल पाहा.

🤔 का

Pipeline म्हणजे दीर्घकाळ चालणारे software ज्यावर इतर लोक डोळे झाकून विश्वास ठेवतात. Pin न केलेली action, सगळे पुन्हा पुन्हा चालवतात अशी flaky test, कधीच न वापरलेला write access असलेला token — प्रत्येक पहिल्या दिवशी ठीक असते आणि चारशेव्या दिवशी शांत धोका बनते. Docker शाळेचा L08 image tags साठी हाच युक्तिवाद करतो, आणि AWS शाळेचा L06 IAM साठी.

नियमपुस्तक काय दुरुस्त करू शकत नाही. व्हॅन निघून गेल्यावर या कोर्समधले काहीही फलकावर लक्ष ठेवत नाही. हाताने केलेले kubectl edit, घाईत केलेले rollout undo, भल्या हेतूने एखाद्या शिक्षिकेने scale केलेला Deployment — pipeline चा शेवटचा run तरीही ✅ म्हणतो. त्या फटीला एक नाव आहे, drift, आणि तिचा उपाय mailroom मध्ये नव्हे तर cluster च्या आत राहतो. तीच ArgoCD शाळा: L04 फटी मोजतो, L05 git ला सत्याचा एकमेव स्रोत आणि pull करून स्वतःला दुरुस्त करणारा agent यांची ओळख करून देतो.

🔧 कसे (या repo मध्ये)

Poster वर आधीच — ci.yml:

permissions:
  contents: read            # lesson 06: the job's own token gets the least it needs

concurrency:                # a newer push cancels the older run of the same branch
  group: ci-${{ github.ref }}
  cancel-in-progress: true

Jenkinsfile घड्याळ स्वतःच्या पद्धतीने लिहितो:

  options { timestamps(); disableConcurrentBuilds() }

      options { timeout(time: 2, unit: 'DAYS') }

Poster वर अजून नाही — files वाचायला सोप्या राहाव्यात म्हणून हा कोर्स @v4 major tags ठेवतो; production repo pin करते आणि pins पुढे सरकवण्याचे काम bot ला देते:

# illustrative — pinned and time-boxed
jobs:
  test:
    timeout-minutes: 10                                   # a hung job fails instead of waiting for hours
    steps:
      - uses: actions/checkout@<full-40-char-sha>         # v4.x — Dependabot/Renovate bump the pin

# illustrative — the same idea for an image, an orb, and a provenance statement
FROM node:22-alpine@sha256:<digest>
orbs: { aws-cli: circleci/aws-cli@5.1.<patch> }           # full x.y.z, not a floating 5.1
- uses: actions/attest-build-provenance@<pinned>          # after the image push; needs attestations: write

Branch protection आणि secret scanning हे repository settings आहेत, files नाहीत: तुमच्या fork मध्ये, Settings → Branches (किंवा Rules) main साठी असा नियम जोडते जो pull request आणि test (node 20|22|24) checks आवश्यक करतो; Settings → Code security secret scanning आणि push protection चालू करते. Menu ची नावे बदलतात; कल्पना बदलत नाही.

🧪 करून पाहा

# 1) how pinned are we? list the floating references in the four dialects
grep -nE "uses: .*@v[0-9]" .github/workflows/*.yml                  # major tags — readable, not pinned
grep -nE "image: cimg|aws-cli@|^FROM " .circleci/config.yml app/Dockerfile   # image tags and an orb, no digest

# 2) resolve one digest so you know what a pin looks like (needs Docker)
docker pull node:22-alpine >/dev/null && docker inspect --format '{{index .RepoDigests 0}}' node:22-alpine

# 3) the flaky-test drill: run the suite 10 times; one ❌ means quarantine + fix, not retry
for i in $(seq 1 10); do (cd app && node --test >/dev/null 2>&1) && printf ✅ || printf ❌; done; echo

# 4) a rough deployment-frequency baseline from your fork's run history
gh run list --workflow=ship.yml --limit=20 --json conclusion,createdAt,updatedAt

⚠️ नेहमीच्या चुका

flaky job ला retry count जोडून पुढे जाणे — failure rate कमी झाला नाही, तो अंधारात गेला
actions/checkout SHA वर pin करणे पण node:22-alpine, cimg/aws:2024.03 आणि orb तरंगते ठेवणे — pin हा सर्वात सैल pin इतकाच चांगला असतो
हिरवी pipeline म्हणजे cluster git शी जुळतो याचा पुरावा मानणे — ती फक्त शेवटची व्हॅन फेरी यशस्वी झाली हे सिद्ध करते; त्यानंतर फलकावर काय घडले ती ArgoCD शाळेची समस्या आहे

🎓 पदवी परीक्षा — हे समजावता येते का?

एक developer pull request उघडते. CI Node 20, 22 आणि 24 वर tests चालवते आणि JUnit report upload करते. main मध्ये merge झाल्यावर pipeline एक image build करते, container ची smoke-test करते, पूर्ण commit SHA चा tag लावून ती ECR ला push करते, staging ला deploy करते, rollout ची वाट पाहते, आणि reviewer production approve करेपर्यंत थांबते.

पहिला run कोणत्या event ने सुरू झाला, आणि दुसरा कोणत्या?
Cache step hit आहे की miss हे काय ठरवते?
Build job आणि push job यांच्यामध्ये काय प्रवास करते, आणि तो cache का नाही?
साठवलेल्या key शिवाय push job ला AWS credentials कसे मिळतात?
Image tag काय आहे, आणि latest ऐवजी तोच का?
APP_VERSION ला काय value दिली जाते, आणि ती परत कुठे वाचता येते?
कोणती ओळ, आणि त्यासोबत कोणते repository setting, production ला approval gate बनवते?
नवा pod तुटलेला असेल तर rolling update कशामुळे थांबतो?
Rollback चे दोन मार्ग कोणते, आणि आधी कोणता वापरावा?
यशस्वी production job नंतर एका तासाने pipeline ला cluster बद्दल काय माहीत असते?

प्रत्येक उत्तर एका वाक्यात आले, तर तुमची ही शाळा पूर्ण झाली.

🎓 मालिका — तुम्ही आता कुठे आहात

तुम्ही Ops track चा थांबा 3️⃣ पूर्ण केला आहे. एक थांबा उरला आहे:

0️⃣ ☁️ Learn AWS School — account, IAM, robots साठी badges
1️⃣ 🍱 Learn Docker School — डबा भरते आणि तो ECR मध्ये ठेवते
2️⃣ ☸️ Learn Kubernetes School — तो चालवते: pods, Services, probes, rollouts
3️⃣ 📮 Learn CI/CD School — हा कोर्स — तपासतो, copy करतो, पोहोचवतो
4️⃣ 🤖 Learn ArgoCD School — नंतर cluster प्रामाणिक ठेवते: git हेच सत्य, self-heal, drift संपला

तपासा. Copy करा. पोहोचवा. मग git ला ते तसेच ठेवू द्या. 📮🚚🤖

git checkout main

🧹 Lesson 12 — Pipeline hygiene & the handoff: the mailroom rulebook

📍 You are here: Lesson 12 of 12 — the final lesson! · Previous: lesson-11-four-dialects

🔗 Next: the ArgoCD school's lesson 01 starts exactly where this one ends.

📦 What's in this branch

All 12 lessons — the complete course. The finale is the poster on the mailroom wall: the habits that keep the courier trustworthy after the novelty wears off, an honest scoreboard, the one problem this whole course cannot solve, and your graduation test. Real files: all of them — the hygiene lines already present are called out below.

🧒 Explain like I'm 5

The courier robot works. Now the school writes the rulebook poster 🧹 so it keeps working next year, when nobody remembers who set it up:

A test that fails only on Tuesdays is not a test 🎲 — quarantine it, fix it, do not just retry until it passes. Retries hide rot.
Know exactly which tools you hired 📌 — pin actions, orbs and base images to a fingerprint (a commit SHA or an image digest), so "v4" cannot quietly change under you.
Give the robot the smallest key that works 🪪 — permissions: per workflow and job, and no master keys (lesson 06).
Lock the main board 🔒 — nothing lands on main without a green check and a review; scan pushes for secrets before they land.
Keep receipts 🧾 — a lockfile says what went in; build provenance says who built it, from which commit, with which pipeline.
Set a clock ⏱️ — a job that hangs should fail; a newer push should cancel the older run.

And one scoreboard 📊 that is not a vanity metric: how often you deliver, how long a change waits, how often a delivery breaks something, how fast you fix it. Four numbers, honestly measured, beat any dashboard.

🗺️ Diagram

flowchart TB
    flaky["🎲 flaky tests<br/>quarantine → fix"]
    pin["📌 pin actions, orbs, images<br/>SHA or digest"]
    perm["🪪 least privilege<br/>permissions: per job"]
    lock["🔒 protect main<br/>required checks + review"]
    prov["🧾 lockfiles + provenance<br/>SLSA, attestations"]
    clock["⏱️ timeout-minutes<br/>concurrency"]
    dora["📊 DORA: frequency · lead time<br/>failure rate · restore time"]
    argo["🤖 ArgoCD school<br/>drift, self-heal, git as truth"]
    flaky -->|"1"| dora
    pin -->|"2"| dora
    perm -->|"3"| dora
    lock -->|"4"| dora
    prov -->|"5"| dora
    clock -->|"6"| dora
    dora -.->|"7 what push cannot fix"| argo

❓ What

Flaky test = passes and fails on the same commit. Quarantine it (skip with a ticket), fix the cause (timing, shared state, network), then un-skip. Auto-retries make the number look better and the problem invisible.
Pinning = referencing a dependency by something that cannot move: a full commit SHA for an action, an exact x.y.z for an orb, a sha256: digest for an image. Dependabot or Renovate then bump the pin with a diff you review.
Least privilege = permissions: at the top of each workflow (read-only by default) and id-token: write only where the badge is needed.
Branch protection = main accepts merges only with required status checks green and a review. Secret scanning with push protection blocks a push that contains a known credential shape before it lands (availability depends on the plan and on whether the repo is public).
Lockfile = the exact dependency tree that went into the build (this app has none because it has no dependencies). Build provenance = a signed statement of how an artifact was built; SLSA defines levels for how strong that statement is; actions/attest-build-provenance produces one.
timeout-minutes / concurrency = a ceiling on how long a job may hang, and a rule that a newer run replaces an older one.

🧠 The scoreboard — DORA's four metrics

metric	asks	this course's lever
deployment frequency	how often does the van reach production?	small changes, a boring pipeline
lead time for changes	commit → running in production: how long?	fast CI (L04), automated deploy (L10)
change failure rate	what share of deliveries need a fix or a rollback?	tests on the BOX (L07), staging first (L08), probes (L09)
time to restore service	when it breaks, how long until it works again?	redeploy yesterday's tag (L09)

No target numbers here on purpose: what counts as good depends on the team, and the published research reports ranges that shift from year to year. Measure your own four and watch the trend.

🤔 Why

A pipeline is long-lived software that other people trust blindly. An unpinned action, a flaky test everyone re-runs, a token with write access it never uses — each is fine on day one and a quiet liability on day four hundred. The Docker school's L08 makes the same argument for image tags, and the AWS school's L06 for IAM.

What the rulebook cannot fix. After the van drives away, nothing in this course watches the board. A kubectl edit by hand, a rollout undo in a hurry, a Deployment scaled by a well-meaning teacher — the pipeline's last run still says ✅. That gap has a name, drift, and its fix lives inside the cluster rather than in the mailroom. That is the ArgoCD school: L04 counts the gaps, L05 introduces git as the single source of truth and an agent that pulls and self-heals.

🔧 How (in this repo)

Already on the poster — ci.yml:

permissions:
  contents: read            # lesson 06: the job's own token gets the least it needs

concurrency:                # a newer push cancels the older run of the same branch
  group: ci-${{ github.ref }}
  cancel-in-progress: true

The Jenkinsfile spells the clock its own way:

  options { timestamps(); disableConcurrentBuilds() }

      options { timeout(time: 2, unit: 'DAYS') }

Not yet on the poster — this course keeps @v4 major tags so the files stay readable; a production repo pins and lets a bot bump the pins:

# illustrative — pinned and time-boxed
jobs:
  test:
    timeout-minutes: 10                                   # a hung job fails instead of waiting for hours
    steps:
      - uses: actions/checkout@<full-40-char-sha>         # v4.x — Dependabot/Renovate bump the pin

# illustrative — the same idea for an image, an orb, and a provenance statement
FROM node:22-alpine@sha256:<digest>
orbs: { aws-cli: circleci/aws-cli@5.1.<patch> }           # full x.y.z, not a floating 5.1
- uses: actions/attest-build-provenance@<pinned>          # after the image push; needs attestations: write

Branch protection and secret scanning are repository settings, not files: in your fork, Settings → Branches (or Rules) adds a rule for main that requires a pull request and the test (node 20|22|24) checks; Settings → Code security turns on secret scanning and push protection. Menu names move; the idea does not.

🧪 Try it

# 1) how pinned are we? list the floating references in the four dialects
grep -nE "uses: .*@v[0-9]" .github/workflows/*.yml                  # major tags — readable, not pinned
grep -nE "image: cimg|aws-cli@|^FROM " .circleci/config.yml app/Dockerfile   # image tags and an orb, no digest

# 2) resolve one digest so you know what a pin looks like (needs Docker)
docker pull node:22-alpine >/dev/null && docker inspect --format '{{index .RepoDigests 0}}' node:22-alpine

# 3) the flaky-test drill: run the suite 10 times; one ❌ means quarantine + fix, not retry
for i in $(seq 1 10); do (cd app && node --test >/dev/null 2>&1) && printf ✅ || printf ❌; done; echo

# 4) a rough deployment-frequency baseline from your fork's run history
gh run list --workflow=ship.yml --limit=20 --json conclusion,createdAt,updatedAt

⚠️ Common mistakes

adding a retry count to a flaky job and moving on — the failure rate did not drop, it went dark
pinning actions/checkout to a SHA but leaving node:22-alpine, cimg/aws:2024.03 and the orb floating — a pin is only as good as the loosest one
treating a green pipeline as proof the cluster matches git — it proves the last van trip succeeded; what happened at the board since is the ArgoCD school's problem

🎓 Graduation test — can you explain this?

A developer opens a pull request. CI runs the tests on Node 20, 22 and 24 and uploads a JUnit report. After the merge to main, the pipeline builds an image, smoke-tests the container, pushes it to ECR tagged with the full commit SHA, deploys it to staging, waits for the rollout, and holds until a reviewer approves production.

Which event started the first run, and which the second?
What decides whether the cache step is a hit or a miss?
What travels between the build job and the push job, and why is it not a cache?
How does the push job get AWS credentials without a stored key?
What is the image tag, and why that and not latest?
What is APP_VERSION set to, and where can you read it back?
Which line, plus which repository setting, turns production into an approval gate?
What makes the rolling update pause if the new pod is broken?
What are the two ways to roll back, and which one should you reach for first?
After a successful production job, what does the pipeline know about the cluster an hour later?

If every answer comes out in one sentence, you are done with this school.

🎓 The series — where you are now

You have finished stop 3️⃣ of the Ops track. One stop remains:

0️⃣ ☁️ Learn AWS School — the account, IAM, badges for robots
1️⃣ 🍱 Learn Docker School — packs the lunchbox and files it in ECR
2️⃣ ☸️ Learn Kubernetes School — runs it: pods, Services, probes, rollouts
3️⃣ 📮 Learn CI/CD School — this course — checks it, copies it, delivers it
4️⃣ 🤖 Learn ArgoCD School — keeps the cluster honest afterwards: git as truth, self-heal, no more drift

Check it. Copy it. Deliver it. Then let git keep it that way. 📮🚚🤖

git checkout main

← Previousfour dialects Finished! Take the quiz →check what stuck

This page is the lesson's README from the lesson-12-pipeline-hygiene branch, shown here so the whole School stays on one site. Code files open on GitHub at the same branch.