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

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

⏪ धडा 10 — Rollback आणि history: वही कालच्या पानावर उलटा

📍 तुम्ही इथे आहात: 12 पैकी धडा 10 · मागील: lesson-09-self-heal-drift · पुढील: lesson-11-helm-kustomize-envs

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

धडे 01–09, आणि त्यासोबत operations मधली सर्वात शांत महाशक्ती: GitOps मध्ये, rollback म्हणजे फक्त git revert — आणि तुमचा audit trail आपोआप लिहिला जातो.

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

वहीच्या मंगळवारच्या पानावर लिहिले होते "खोली 3B निळी रंगवा". खोली निळी झाली. बुधवारी सगळ्यांचे एकमत: तो निळा रंग भयंकर आहे. 🎨😱

जुने जग: घाबरगुंडी, जुना रंगाचा डबा शोधा, जुना रंग आठवा, मध्यरात्री हाताने पुन्हा रंगवा, आणि आपण बरोबर आठवले अशी आशा करा.

वहीचे जग: एक पान मागे उलटा. 📖⏪ सोमवारच्या पानावर जे लिहिले होते नेमके तेच सांगणारे नवे पान लिहा (हेच git revert — ते बुधवारची चूक पुसत नाही, ते "बुधवारचे उलटवा" असे एक पान जोडते). केअरटेकर ते वाचतो आणि शांतपणे पुन्हा रंगवतो. माणसाचे फक्त दहा सेकंदांचे काम.

आणि शाळेची नोंदवही? वहीच्या पानांचा इतिहास म्हणजे प्रत्येक विनंतीची नोंद: कोणी कोणते पान, केव्हा आणि का बदलले (commit message). केअरटेकर त्याने प्रत्यक्षात काय केले आणि केव्हा याची दुसरी, छोटी नोंद ठेवतो — ArgoCD ची sync history. Auditor 🕵️ दोन्ही वाचते आणि लवकर घरी जाते.

🗺️ आकृती

flowchart LR
    A["commit A<br/>image: v1 ✅"] --> B["commit B<br/>image: v2 💥 bad!"]
    B --> C["commit C = revert B<br/>image: v1 again ✅"]
    C -->|"3 robot syncs C<br/>cluster back on v1"| argo["🤖 ArgoCD"]
    B -.->|"1 bad version ships<br/>via git, at least!"| B
    C -.->|"2 git revert - 10 seconds"| C
    argo -.->|"4 git = desired-state history 🧾<br/>ArgoCD history = what actually synced"| argo

❓ काय

git revert <sha> जुना commit उलटवणारा एक नवा commit बनवतो — history जशीच्या तशी राहते (तुमच्या deploy repo वर कधीच force-push करू नका!). ArgoCD नवा commit पाहतो आणि sync करतो; cluster शांतपणे मागे जातो, कोणत्याही deploy सारख्याच rolling-update सुरक्षिततेसह.
ArgoCD चे स्वतःचे History & Rollback बटण देखील आहे (ते मागील revision पुन्हा sync करू शकते) — आगीच्या सरावात उत्तम. पण लक्षात ठेवा: automated sync चालू असताना UI मधून केलेला rollback वही पुन्हा उलटवून टाकते — टिकणारा rollback म्हणजे git revert. वहीच बदलली पाहिजे.
एक नव्हे, दोन histories. Git history = desired-state बदलांचा इतिहास (git log -p k8s/ — कोणी/काय/केव्हा; PR सांगतो का). ArgoCD ची sync history = प्रत्यक्षात काय sync झाले (argocd app history hello-school, किंवा History tab): एखादा sync fail होऊ शकतो, manual होकाराची वाट पाहू शकतो, किंवा काही मिनिटे उशिरा होऊ शकतो, आणि git ला त्याबद्दल काहीच माहीत नसते. मिळून त्या CI logs + kubectl events वरून timeline पुन्हा जुळवण्याची गरज संपवतात.

🤔 हे pipeline rollbacks पेक्षा सरस का

Pipeline rollback ही एक नवी पुढची कृती असते (जुन्या parameters सह पुन्हा चालवा — ते अजूनही valid असतील अशी आशा करा). GitOps rollback हे एक state घोषणा असते: "desired = जे आधी होते ते". Pipeline पुन्हा चालवायची नाही, शिळे parameters नाहीत, "deploy job बिघडला आहे आणि तोच rollback tool पण आहे" असा single point of failure नाही. आणि ते 1 किंवा 50 clusters वर अगदी सारखेच चालते.

✅ खड्डा 4 बुजला. "खोली 3B मध्ये आत्ता काय आहे?" याचे उत्तर आता काय पाठवले गेले याच्या टपालखान्याच्या नोंदीतून मिळत नाही: वही हेच live सत्य आहे (Synced ✅ म्हणजे खोली == पान), आणि sync history सांगते की प्रत्येक पान प्रत्यक्षात केव्हा apply झाले.

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

Demo Deployment k8s/deployment.yaml मध्ये image: nginxdemos/hello:plain-text pin करते. git मधली ती ओळ बदलणे हाच deploy; तो commit revert करणे हाच rollback. एवढीच संपूर्ण यंत्रणा. (म्हणूनच GitOps repos ठराविक tags pin करतात, कधीच :latest नाही — बदलणारा tag प्रत्यक्षात काय चालू आहे ते लपवतो, आणि "revert" काहीच उलटवणार नाही.)

🧪 करून पाहा (तुमच्या fork वर)

# point your Application at YOUR fork first (lesson 07), then:

# 1) ship a "bad" version — change the image tag in k8s/deployment.yaml:
#      image: nginxdemos/hello:latest        # pretend this one is broken
git add k8s/deployment.yaml && git commit -m "ship v2" && git push
kubectl -n gitops-school get pods -w          # rollout happens by itself; Ctrl+C

# 2) uh oh. roll back in one move:
git revert --no-edit HEAD && git push
kubectl -n gitops-school get pods -w          # ...and it calmly walks back. 🎉

# 3) read your free audit log:
git log --oneline -- k8s/                     # every desired-state change, forever
argocd app history hello-school 2>/dev/null || echo "or: UI → hello-school → History"   # what actually synced

✅ तपासा — तुम्हाला काय दिसायला हवे

चुकीच्या commit नंतर: kubectl -n gitops-school get deploy hello-school -o jsonpath='{.spec.template.spec.containers[0].image}' ~3 मिनिटांत नवा tag दाखवते. git revert + push नंतर: पुन्हा जुना tag, नेहमीच्या rolling update द्वारे. argocd app history hello-school (किंवा History tab) दोन्ही syncs त्यांच्या git SHAs सह दाखवते — प्रत्यक्षात काय चालले याची तीच नोंद आहे.

🧹 स्वच्छता

तुमच्या fork मध्ये आता दोन जास्तीचे commits आहेत — बदल आणि त्याचा revert. तोच audit trail आहे; तो ठेवा. Cluster मध्ये साफ करण्यासारखे काही नाही.

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

automated sync चालू असताना UI च्या Rollback बटणाने rollback करणे — वही काही मिनिटांत चुकीचा commit पुन्हा apply करते; टिकणारा rollback म्हणजे revert
"undo" करण्यासाठी git reset --hard + force-push — ज्या history मुळे rollback विश्वासार्ह होता तीच तुम्ही नष्ट करता
:latest pin करणे — tag बदललाच नाही म्हणून revert काहीच बदलत नाही
git history ला एखादी गोष्ट चालली याचा पुरावा समजणे — प्रत्यक्षात काय sync झाले, आणि केव्हा, हे sync history सांगते

🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे: GitOps rollback हा इतर कोणत्याही PR सारखाच एक PR असतो, आणि म्हणूनच तो शांत असतो: तेच review, तेच checks, तोच audit. Image tag एका छोट्या वेगळ्या file मध्ये (किंवा values file मध्ये) ठेवा, म्हणजे revert फक्त एक ओळ बदलेल.

⏭️ पुढे

एका खोलीत एक app छान आहे — पण प्रत्यक्ष जीवनात dev/staging/prod आणि दहा services असतात. Templates आणि app-of-apps pattern.

git checkout lesson-11-helm-kustomize-envs

⏪ Lesson 10 — Rollback & history: flip the book to yesterday's page

📍 You are here: Lesson 10 of 12 · Previous: lesson-09-self-heal-drift · Next: lesson-11-helm-kustomize-envs

📦 What's in this branch

Lessons 01–09, plus the calmest superpower in operations: in GitOps, rollback is just git revert — and your audit trail writes itself.

🧒 Explain like I'm 5

Tuesday's page of the book said "paint Room 3B blue". The room turned blue. Wednesday everyone agrees: the blue is hideous. 🎨😱

Old world: panic, find the old paint can, remember the old color, repaint by hand at midnight, hope you remembered right.

Book world: flip back one page. 📖⏪ Write a new page that says exactly what Monday's page said (that's git revert — it doesn't erase Wednesday's mistake, it adds a page "undo Wednesday"). The caretaker reads it and calmly repaints. Ten seconds of human work.

And the school's logbook? The book's page history is the record of every request: who changed which page, when, and why (the commit message). The caretaker keeps a second, shorter note of what it actually did and when — ArgoCD's sync history. The auditor 🕵️ reads both and goes home early.

🗺️ Diagram

flowchart LR
    A["commit A<br/>image: v1 ✅"] --> B["commit B<br/>image: v2 💥 bad!"]
    B --> C["commit C = revert B<br/>image: v1 again ✅"]
    C -->|"3 robot syncs C<br/>cluster back on v1"| argo["🤖 ArgoCD"]
    B -.->|"1 bad version ships<br/>via git, at least!"| B
    C -.->|"2 git revert - 10 seconds"| C
    argo -.->|"4 git = desired-state history 🧾<br/>ArgoCD history = what actually synced"| argo

❓ What

git revert <sha> creates a new commit that undoes an old one — history stays intact (never force-push your deploy repo!). ArgoCD sees the new commit and syncs; the cluster walks backward calmly, with the same rolling-update safety as any deploy.
ArgoCD's own History & Rollback button exists too (it can re-sync a previous revision) — great in a fire drill. But note: rolling back via the UI while automated sync is on gets overridden by the book again — the durable rollback is the git revert. The book must change.
Two histories, not one. Git history = desired-state change history (git log -p k8s/ — who/what/when; the PR says why). ArgoCD's sync history = what was actually synced (argocd app history hello-school, or the History tab): a sync can fail, wait for a manual nod, or land minutes later, and git knows nothing about that. Together they replace reconstructing a timeline from CI logs + kubectl events.

🤔 Why this beats pipeline rollbacks

A pipeline rollback is a new forward action (re-run with old parameters — hope they're still valid). A GitOps rollback is a state declaration: "desired = what it was". No pipeline re-run, no stale parameters, no "deploy job is broken and it's also the rollback tool" single point of failure. And it works identically across 1 or 50 clusters.

✅ Gap 4 closed. "What's in Room 3B right now?" is no longer answered by a mailroom log of what was sent: the book is the live truth (Synced ✅ means room == page), and the sync history says when each page was actually applied.

🔧 How (in this repo)

The demo Deployment pins image: nginxdemos/hello:plain-text in k8s/deployment.yaml. Changing that line in git IS a deploy; reverting that commit IS a rollback. That's the entire mechanism. (This is also why GitOps repos pin specific tags, never :latest — a floating tag hides what's actually running, and "revert" would revert nothing.)

🧪 Try it (on your fork)

# point your Application at YOUR fork first (lesson 07), then:

# 1) ship a "bad" version — change the image tag in k8s/deployment.yaml:
#      image: nginxdemos/hello:latest        # pretend this one is broken
git add k8s/deployment.yaml && git commit -m "ship v2" && git push
kubectl -n gitops-school get pods -w          # rollout happens by itself; Ctrl+C

# 2) uh oh. roll back in one move:
git revert --no-edit HEAD && git push
kubectl -n gitops-school get pods -w          # ...and it calmly walks back. 🎉

# 3) read your free audit log:
git log --oneline -- k8s/                     # every desired-state change, forever
argocd app history hello-school 2>/dev/null || echo "or: UI → hello-school → History"   # what actually synced

✅ Verify — what you should see

After the bad commit: kubectl -n gitops-school get deploy hello-school -o jsonpath='{.spec.template.spec.containers[0].image}' shows the new tag within ~3 minutes. After git revert + push: the old tag again, through a normal rolling update. argocd app history hello-school (or the History tab) lists both syncs with their git SHAs — that is the record of what actually ran.

🧹 Clean up

Your fork now carries two extra commits — the change and its revert. That is the audit trail; keep it. Nothing in the cluster to clean.

⚠️ Common mistakes

rolling back with the UI's Rollback button while automated sync is on — the book re-applies the bad commit within minutes; the durable rollback is the revert
git reset --hard + force-push to "undo" — you destroy the history that made the rollback trustworthy
pinning :latest — a revert changes nothing because the tag did not change
reading git history as proof that something ran — sync history says what actually synced, and when

🏭 Why this matters in production: a GitOps rollback is a PR like any other, which is exactly why it is calm: same review, same checks, same audit. Keep the image tag in a small separate file (or a values file) so a revert touches one line.

⏭️ Next

One app in one room is lovely — but real life is dev/staging/prod and ten services. Templates and the app-of-apps pattern.

git checkout lesson-11-helm-kustomize-envs

← Previousself heal drift Next →helm kustomize envs

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