शाळेच्या Ops ट्रॅकमधील कोर्स 4 पैकी 3 — Docker ने डबा पॅक केला आणि Kubernetes तो चालवते; प्रत्येक push वर कोणीतरी तो तपासायला, कॉपी करायला आणि पोहोचवायला हवा. तोच हा कोर्स: शाळेची मेलरूम आणि कुरिअर सेवा — continuous integration, continuous delivery, आणि तीच pipeline चार बोलींमध्ये (GitHub Actions, CircleCI, GitLab CI, Jenkins) लिहिलेली. त्यानंतर ArgoCD cluster ला प्रामाणिक ठेवते.
✅ प्रत्येक push वर चाचण्या🗄️ cache📎 artifact🪪 OIDC, साठवलेल्या keys नाहीत📦 image = commit SHA🛑 मंजुरीचे गेट🔁 rolling · blue/green · canary🚚 CI मधून kubectl🗣️ चार बोली
✅ भाग 1 — तपासा (मोफत, तुमच्या fork मध्ये)
सत्राच्या शेवटचा गृहपाठाचा ढीग म्हणजे integration hell का
trigger, job, step, runner — conveyor belt
प्रत्येक push वर हिरवी खूण; cache hit, matrix, artifact
secrets योग्य पद्धतीने: कुरिअरचा बॅज (OIDC), least privilege
🚚 भाग 2 — पोहोचवा (स्थानिक cluster किंवा AWS)
image build करा, smoke-test करा आणि फाइल करा: tag = commit SHA
staging → प्राचार्यांची सही → production
rolling, blue/green, canary — आणि 10 सेकंदांचे rollback
डिलिव्हरी व्हॅन: CI मधून kubectl, गेट म्हणून rollout status
🗣️ भाग 3 — खरे जग
एक Rosetta तक्ता: GitHub Actions · CircleCI · GitLab CI · Jenkins
hosted vs self-hosted; logic script मध्ये ठेवा, YAML पातळ
स्वच्छता: SHA ने pin करा, लहरी चाचण्या बाजूला ठेवा, DORA ची चार मापे
push pipeline जे दुरुस्त करू शकत नाही → ArgoCD शाळा
🎯 या कोर्सनंतर तुम्हाला जमले पाहिजे: CI vs continuous delivery vs continuous deployment समजावणे · कोणतीही pipeline फाइल वाचून तिचे trigger, job, step आणि runner ओळखणे · cache आणि matrix ने pipeline वेगवान करणे, तिला खोटे न बोलवता · job मध्ये फाइल हलवणे आणि चाचणी अहवाल प्रकाशित करणे · एकही साठवलेली key नसताना CI मधून cloud वर deploy करणे · production च्या पुढे मंजुरीचे गेट आणि staging पायरी ठेवणे · rolling, blue/green किंवा canary निवडणे आणि सेकंदांत rollback करणे · तीच pipeline चार CI प्रणालींमध्ये भाषांतरित करणे · push pipeline अजूनही काय करू शकत नाही आणि पुढचा कोर्स का आहे हे सांगणे.
🗺️ संपूर्ण चित्र — एक आकृती, संपूर्ण प्रवास
संपूर्ण कोर्स एका कॅनव्हासवर: तपासा (हिरवे, धडे 1–6), पोहोचवा (केशरी, धडे 7–10) आणि खरे जग (नीळसर जांभळे, धडे 11–12). 4K आवृत्तीसाठी क्लिक करा — एकाच संदर्भ-चित्रासाठी उत्तम.
✅ भाग 1 — तपासा: continuous integration (धडे 1–6)
इथले सगळे या repo च्या fork मध्ये GitHub च्या मोफत runner वर चालते — cloud खाते नाही, खर्च नाही. एक git branch = एक कल्पना; branch 04 मध्ये धडे 01–04 असतात.
1
📮 CI/CD का
गृहपाठाचा ढीग विरुद्ध प्रत्येक सादरीकरण त्याच दिवशी तपासणारी मेलरूम.lesson-01-why-cicdधडा वाचा →आकृती पहा ↗
2
🧩 pipeline ची रचना
Conveyor belt: घंटा (trigger), बाक (job), कामे (step), कारकून (runner) — तेच शब्द, चार बोली.lesson-02-pipeline-anatomyधडा वाचा →आकृती पहा ↗
3
✅ तुमची पहिली pipeline
तपासणी डेस्क प्रत्येक push वर ✅ किंवा ❌ चा शिक्का मारतो — fork करा आणि हिरवे होताना पहा.lesson-03-first-pipelineधडा वाचा →आकृती पहा ↗
4
⚡ वेगवान pipeline
टोक काढलेल्या पेन्सिलींचा ड्रॉवर (cache), एकाच वेळी अनेक बाक (parallel), तीन फूटपट्ट्या (matrix).lesson-04-cache-parallel-matrixधडा वाचा →आकृती पहा ↗
5
📎 Artifact & चाचणी अहवाल
बाकांमध्ये फिरणारे पाकीट, आणि फलकावर लावलेले प्रगतिपुस्तक.lesson-05-artifacts-reportsधडा वाचा →आकृती पहा ↗
6
🪪 Secrets & least privilege
कुरिअर कधीही मास्टर किल्ली नेत नाही — तो बॅज दाखवतो आणि डे पास मिळवतो (OIDC). 🔗 IAMlesson-06-secrets-oidcधडा वाचा →आकृती पहा ↗
🎯 भाग 1 नंतर तुम्हाला समजावता आले पाहिजे: pipeline चा run कशाचा बनलेला असतो · cache key ही input चा hash का असते · artifact vs cache · run च्या token कडे contents: read आणि आणखी काहीच का नसते · CI job ला एकही साठवलेली key नसताना cloud credentials कशी मिळतात.
🚚 भाग 2 — पोहोचवा: continuous delivery (धडे 7–10)
हिरव्या खुणेपासून चालू आवृत्तीपर्यंत: फोटोकॉपी मशीन, लॉकर, सही, व्हॅन. प्रयोग स्थानिक cluster वर (Docker Desktop किंवा kind) चालतात; AWS च्या पायऱ्या खुणा केलेल्या आणि ऐच्छिक आहेत.
7
📦 image build & push करा
फोटोकॉपी मशीन: तपासलेल्या गृहपाठाची प्रत काढा, commit च्या ठशाने लेबल लावा, लॉकरमध्ये फाइल करा. 🔗 Dockerlesson-07-build-push-imageधडा वाचा →आकृती पहा ↗
8
🛑 Environments & गेट
आधी सराव फलक; मुख्य फलकावर काही पोहोचण्याआधी प्राचार्य सही करतात.lesson-08-environments-gatesधडा वाचा →आकृती पहा ↗
9
🔁 Deploy च्या पद्धती & rollback
टाचण्या एक एक करून बदला, दोन फलकांमध्ये पलटा, किंवा सूचना आधी एकाच वर्गाला दाखवा. 🔗 Kuberneteslesson-09-deploy-strategiesधडा वाचा →आकृती पहा ↗
10
🚚 CI मधून Kubernetes वर deploy
डिलिव्हरी व्हॅन: डे पास घेऊन cluster पर्यंत जा, सूचना लावा, ती वाचनीय होईपर्यंत थांबा.lesson-10-deploy-to-kubernetesधडा वाचा →आकृती पहा ↗
🎯 भाग 2 नंतर तुम्हाला समजावता आले पाहिजे: image चा tag commit SHA का असतो · माणसाच्या मंजुरीपर्यंत production job काय थांबवते, आणि ती मंजुरी कुठे नोंदली जाते · readiness probe असलेले rolling update downtime कसे टाळते · डिलिव्हरी व्हॅन चालवते त्या चार आज्ञा, आणि ती गेल्यावर कोणी काय करत नाही.
🗣️ भाग 3 — खरे जग: चार बोली, एक नियमपुस्तक (धडे 11–12)
तीच pipeline या repo मध्ये चार वेळा आहे. भाषांतर करायला शिका, मग मेलरूम विश्वासार्ह ठेवणाऱ्या सवयी शिका — आणि हा कोर्स GitOps कडे कुठे सोपवतो ते पहा.
11
🗣️ तीच pipeline चार बोलींमध्ये
चार कुरिअर कंपन्या, तोच मार्ग, वेगळे फॉर्म: GitHub Actions, CircleCI, GitLab CI, Jenkins.lesson-11-four-dialectsधडा वाचा →आकृती पहा ↗
12
🧹 Pipeline ची स्वच्छता & हस्तांतरण
मेलरूमचे नियमपुस्तक, DORA चा गुणफलक — आणि ArgoCD कडे दंडुका सोपवणे.lesson-12-pipeline-hygieneधडा वाचा →आकृती पहा ↗
🎯 भाग 3 नंतर तुम्हाला जमले पाहिजे: कधीही न पाहिलेली CircleCI, GitLab किंवा Jenkins pipeline वाचणे · एखादा बदल DORA च्या चार मापांपैकी कोणते हलवेल हे सांगणे · push pipeline ला काय दिसत नाही (drift) आणि कोणता कोर्स ते दुरुस्त करतो हे ओळखणे.
# take the course locally (a GitHub account for Part 1; Docker Desktop or kind for the local labs):
gh repo fork BaluRaut/learn-cicd-school --clone
cd learn-cicd-school
git checkout lesson-01-why-cicd # then open lessons/01-why-cicd/README.md
🗣️ चार बोली, शेजारी शेजारी: या repo मध्ये .github/workflows/, .circleci/config.yml, .gitlab-ci.yml आणि एक Jenkinsfile आहे — सगळे एकाच conveyor चे वर्णन करतात. चार-बोली पान ते Rosetta तक्त्यासह tab मध्ये दाखवते — 03 ते 10 प्रत्येक धडाही आपली पायरी चारही बोलींमध्ये दाखवतो.
🎓 शाळेची मालिका: 0️⃣ AWS पाया → 1️⃣ Docker & ECR image पॅक करते → 2️⃣ Kubernetes ती मोठ्या प्रमाणावर चालवते → 3️⃣ हा कोर्स प्रत्येक push वर ती तपासतो, कॉपी करतो आणि पोहोचवतो → 4️⃣ ArgoCD cluster ला कायमचे प्रामाणिक ठेवते. तीच शैली, त्याच उपमांचे विश्व, तेच डेमो-ॲप कुटुंब.
📐 धड्यांच्या आकृत्या — क्रमांक अनुसरा
प्रत्येक धडा एक क्रमांकित बॉक्स-आणि-बाण आकृती म्हणून, एकामागोमाग एक — इथेच वाचता येईल (हिरवे = CI, केशरी = CD, नीळसर जांभळे = खरे जग). स्वतंत्र पानावरही, उडी मारायच्या दुव्यांसह.
1 📮 CI/CD का — गृहपाठाचा ढीग
सत्राच्या शेवटी एका अजस्र merge पेक्षा त्याच दिवशी तपासलेली छोटी सादरीकरणे सरस; pipeline हा तपासणारा, कॉपी करणारा आणि पोहोचवणारा conveyor आहे.
🧒 सोप्या शब्दांत
40 विद्यार्थ्यांनी सगळा गृहपाठ सत्राच्या शेवटच्या दिवशी दिला, तर शिक्षक त्यात बुडून जातात आणि कोणती चूक कुठून आली ते कळत नाही. प्रत्येक गृहपाठ आला त्याच दिवशी तपासला तर खूप सोपे जाते. CI/CD हा टपाल-खोलीचा conveyor आहे: प्रत्येक git push तपासला जातो (tests), त्याची copy बनते (Docker image) आणि तो पोहोचवला जातो (Kubernetes वर), छोट्या तुकड्यांत, म्हणून काहीच साचत नाही.
📖 नवे शब्दCI — continuous integration: प्रत्येक बदल आला त्याच दिवशी आपोआप तपासला जातोcontinuous delivery — तपासलेली copy एका click वर पाठवायला नेहमी तयार असतेcontinuous deployment — प्रत्येक तपासलेला बदल click शिवाय आपोआप बाहेर जातोpipeline — conveyor: प्रत्येक बदल ज्या ठरलेल्या पायऱ्यांतून जातो त्याintegration hell — खूप मोठे बदल एकदम merge करताना होणारा त्रास
⏪ आधी
चाळीस गृहपाठ शेवटच्या दिवशी merge: काहीच जुळत नव्हते, conflicts ना आठवडा लागायचा, आणि प्रत्येक release ची भीती वाटायची.
💡 काय
CI/CD म्हणजे mailroom conveyor, जो प्रत्येक submission आल्याच्या दिवशीच तपासतो, copy करतो आणि पोहोचवतो.
⚙️ कसे
प्रत्येक git push वर तपासण्यासाठी node --test, copy साठी docker build, आणि पोहोचवण्यासाठी kubectl apply चालते.
🎯 का
एकावेळी एक तपासलेले छोटे commits कधीच साचत नाहीत, म्हणून bug थेट त्याला कारणीभूत बदलाकडे निर्देश करतो.
🚀 पुढे
CI प्रत्येक push तपासते, continuous delivery एक copy तयार ठेवते, continuous deployment ती आपोआप पाठवते.
🧪 Try it here — दहा आठवड्यांचे काम एकदम merge करा, किंवा प्रत्येक submission आल्या दिवशी तपासा
घंटा वाजते (trigger), कारकून (runner) बाकावर (job) बसतो आणि आपली कामे (step) एक एक करून करतो — बाजूला ड्रॉवर, पाकिटे, तिजोरी आणि कुलूपबंद दार.
🧒 सोप्या शब्दांत
घंटा वाजली की कारकून टेबलावर बसतो आणि कामांची यादी पूर्ण करतो. Pipeline तसेच चालते: trigger, उदा. push, घंटा वाजवतो; runner, म्हणजे नंतर पुसले जाणारे नवे मशीन, प्रत्येक job वर बसून त्याच्या steps क्रमाने करते. एक job दुसऱ्यावर अवलंबून नसेल तर jobs शेजारी-शेजारी चालतात. टेबलांजवळ: ड्रॉवर (cache), पाकिटे (artifacts), तिजोरी (secrets).
📖 नवे शब्दtrigger — pipeline सुरू करणारी घटना, उदा. push किंवा ठरलेली वेळrunner — एक job चालवणारा नवा संगणक, जो नंतर पुसला जातोjob — एका टेबलाचे काम: एका runner वरच्या steps ची यादीstep — एक काम: shell command (run:) किंवा तयार action (uses:)needs: — दुसरा job पूर्ण होईपर्यंत हा job थांबवतो
⏪ आधी
Pipeline file म्हणजे YAML ची भिंत वाटायची, भागांना नावे नव्हती आणि प्रत्येक भाग काय करतो ते कळत नव्हते.
💡 काय
Pipeline म्हणजे घंटा (trigger), टेबलांवर (jobs) बसलेले clerks (runners) जे कामे (steps) एकामागून एक करतात.
⚙️ कसे
on: push घंटा वाजवतो, runs-on: ubuntu-latest प्रत्येक job ला नवीन मशीन देतो, आणि needs: jobs चा क्रम ठरवतो.
🎯 का
भाग कळले की तुम्ही कोणतीही pipeline वाचू शकता, आणि cache, artifact आणि secret यांतील फरक ओळखू शकता.
🚀 पुढे
पुढे तुम्ही स्वतः खरी pipeline चालवाल आणि ती तुमच्या commit वर हिरवा check किंवा लाल cross मारताना पाहाल.
🧪 Try it here — workflow चे तुकडे निवडा आणि त्याचे YAML पहा
3 ✅ तुमची पहिली pipeline — प्रत्येक push वर हिरवी खूण
Fork करा, push करा, तपासणी डेस्क commit वर ✅ किंवा ❌ चा शिक्का मारताना पहा — आणि लाल असेल तेव्हा log वाचायला शिका.
🧒 सोप्या शब्दांत
गृहपाठ दिला की शिक्षक त्यावर ✓ किंवा ✗ चा शिक्का मारतात. तुमची पहिली pipeline प्रत्येक push साठी तेच करते: ती tests चालवते आणि commit वर हिरवा ✅ किंवा लाल ❌ लावते. इथे तीन टेबलं एकाच commit ला Node 20, 22 आणि 24 वर एकाच वेळी तपासतात. एखादे लाल असेल, तर त्याचा log तीन प्रश्नांनी वाचा: कोणता job, कोणती step, कोणती ओळ.
📖 नवे शब्दworkflow — GitHub Actions ने काय आणि केव्हा चालवायचे ते सांगणारी YAML filecheck — run नंतर GitHub commit वर लावतो ती ✅ किंवा ❌ खूणlog — run चा पूर्ण छापील मजकूर; लाल ओळ काय बिघडले ते सांगतेexit code — command परत देते तो आकडा: 0 म्हणजे ठीक, बाकी काहीही म्हणजे अपयश
⏪ आधी
आपोआप तपासणीशिवाय, फक्त node 24 वर fail होणारा bug कोणाच्या लक्षात येण्याआधीच users पर्यंत पोहोचला असता.
💡 काय
तुमची पहिली pipeline प्रत्येक push वर चालते आणि commit वर हिरवा check किंवा लाल cross मारते.
⚙️ कसे
तीन टेबले एकाच commit साठी node 20, 22 आणि 24 वर checkout, prepare आणि node --test एकाच वेळी चालवतात.
🎯 का
लाल आले की log क्रमाने वाचा: कोणता job, कोणती step, कोणती ओळ, आणि दुरुस्ती पटकन होते.
🚀 पुढे
Pipeline चालू झाली की पुढे cache, parallel jobs आणि matrix वापरून ती जलद कराल.
🧪 Try it here — commit push करा आणि तीन डेस्क तपासताना पहा; एक node आवृत्ती मोडा
काम ठरवणाऱ्या फाइलवरून ड्रॉवरला किल्ली द्या; तीन फूटपट्ट्या शेजारी शेजारी चालवा; सगळ्यांना पूर्ण होऊ द्या.
🧒 सोप्या शब्दांत
गणिताची सोडवलेली पायरी प्रश्नाचे नाव लिहिलेल्या ड्रॉवरमध्ये ठेवली, तर प्रश्न तोच असेपर्यंत ती पुन्हा सोडवावी लागत नाही. Cache हा तो ड्रॉवर आहे: त्याची key काम ज्या file वर अवलंबून आहे तिच्यावरून बनते, म्हणून hit झाला तर ~10 s ऐवजी ~1 s लागतो. Matrix म्हणजे एकाच वेळी मोजणाऱ्या तीन पट्ट्या: एकच job व्याख्या Node 20, 22 आणि 24 वर शेजारी-शेजारी चालते.
📖 नवे शब्दcache — जपून ठेवलेल्या कामाचा ड्रॉवर, पुढच्या run मध्ये वापरता येतो; तो नाहीसाही होऊ शकतोcache key — ड्रॉवरचे label, input file वरून बनते म्हणून file बदलली की तेही बदलतेhit / miss — hit = जपलेले काम सापडले; miss = ते पुन्हा करावे लागेलmatrix — एकदाच लिहिलेला job अनेकदा चालतो, उदा. प्रत्येक Node version साठी एकदाfail-fast: false — एक matrix job अपयशी झाला तरी बाकीचे थांबवू नका, पूर्ण होऊ द्या
⏪ आधी
प्रत्येक run सावकाश काम पुन्हा सुरुवातीपासून करायचा, जसे सुमारे 8 ते 10 सेकंद घेणाऱ्या 12,000,000 hash rounds.
💡 काय
Cache म्हणजे input file वरून नाव दिलेला drawer, आणि matrix एकाच job definition चे अनेक jobs एकाच वेळी चालवतो.
⚙️ कसे
app/prepare.js वरचे hashFiles() key बनवते: तीच file म्हणजे सुमारे 1 s मध्ये HIT; node: [20, 22, 24] पसरते.
🎯 का
खऱ्या input वरून key दिल्याने cache प्रामाणिक राहतो, आणि fail-fast: false प्रत्येक ruler ला अहवाल पूर्ण करू देते.
🚀 पुढे
Cache नाहीसा होऊ शकतो, म्हणून पुढे artifacts शिकाल: jobs मध्ये निकाल नेणारे नावाचे लिफाफे.
🧪 Try it here — pipeline दोनदा चालवा, मग prepare.js बदला — key आणि वेळ पहा
cache job ला वेग देते आणि नाहीशी होऊ शकते; artifact हे नाव असलेले पाकीट आहे जे निकाल — image, प्रगतिपुस्तक — एका बाकावरून पुढच्या बाकावर नेते.
🧒 सोप्या शब्दांत
प्रत्येक टेबलाला नवे मशीन मिळते जे job संपल्यावर पुसले जाते, म्हणून दोन टेबलं कधीच एक disk वाटून घेत नाहीत. काम पुढे देण्यासाठी ते नाव असलेल्या पाकिटात, म्हणजे artifact मध्ये, बंद करता: build टेबल image आत ठेवते, push टेबल ती बाहेर काढते. Tests लाल असल्या तरी test report card सुद्धा upload होते, कारण नेमके तेव्हाच ते वाचायची गरज असते.
📖 नवे शब्दartifact — job नंतर ठेवलेली नाव असलेली file, जी दुसरा job किंवा माणूस download करू शकतोupload / download-artifact — file पाकिटात ठेवणे / नंतरच्या job मध्ये ती बाहेर काढणेtest report — कोणत्या tests पास आणि कोणत्या नापास झाल्या त्याची file (test-results.xml)if: always() — आधीची step अपयशी झाली तरी ही step चालवा
⏪ आधी
Jobs वेगवेगळ्या मशीनवर चालतात ज्या disk वाटत नाहीत, म्हणून machine A पुसले की बनलेली image हरवायची.
💡 काय
Artifact म्हणजे नाव दिलेला, जपलेला लिफाफा, जसे image.tar.gz किंवा test-results.xml, एका job कडून पुढच्या job कडे जाणारा.
सहीबंद बॅज दाखवा, संपणारा डे पास मिळवा: कुरिअरच्या खिशात AWS keys नाहीत, आणि पास फक्त या repo ला लागणारी दारेच उघडतो.
🧒 सोप्या शब्दांत
शाळेत येणाऱ्या पाहुण्याला कायमची किल्ली मिळत नाही; तो सही केलेले पत्र दाखवतो आणि ठराविक दारेच उघडणारा दिवसाचा pass मिळवतो. OIDC तसेच चालते: pipeline GitHub कडून सही केलेला badge मागते, तो याच repo आणि branch मधून आला आहे हे AWS तपासते, आणि सुमारे एका तासात संपणारा pass देते. चोरता येतील अशा AWS keys pipeline मध्ये ठेवलेल्याच नसतात.
📖 नवे शब्दsecret — सुरक्षित ठेवलेला password किंवा key; GitHub तो logs मध्ये लपवतोOIDC — keys साठवण्याऐवजी सही केलेल्या badge च्या बदल्यात थोड्या वेळाचा pass घेणेtrust policy — कोणत्या repo आणि branch ला pass मिळू शकतो हे सांगणारा AWS मधला नियमleast privilege — या job ला लागणारी दारेच द्या, त्याहून जास्त काहीच नाही
⏪ आधी
दीर्घकाळ टिकणाऱ्या AWS_ACCESS_KEY_ID आणि AWS_SECRET_ACCESS_KEY प्रत्येक repo मध्ये copy व्हायच्या, आणि log मध्ये छापल्या की कायमच्या leak व्हायच्या.
💡 काय
OIDC courier ला signed badge देतो, जो तो AWS कडे छोट्या day pass साठी बदलतो, कोणत्याही साठवलेल्या keys शिवाय.
⚙️ कसे
permissions: id-token: write GitHub कडून JWT मागतो; AWS STS role च्या trust policy नुसार aud आणि sub तपासते.
🎯 का
Credentials सुमारे एका तासात संपतात, आणि fork किंवा दुसऱ्या branch ला वेगळा sub मिळतो, म्हणून AWS नाही म्हणते.
🚀 पुढे
Day pass हातात आल्यावर पुढे pipeline image build करते, ती चालते हे सिद्ध करते आणि ECR मध्ये ठेवते.
🧪 Try it here — वेगवेगळ्या ठिकाणांहून AWS कडे दिवसाचा पास मागा
तपासलेल्या गृहपाठाची फोटोकॉपी काढा, प्रत चालते हे सिद्ध करा, commit च्या ठशाने लेबल लावा, लॉकरमध्ये फाइल करा.
🧒 सोप्या शब्दांत
Photocopy फाईल करण्याआधी ती वाचता येते का ते पाहता आणि ती कोणत्या पानाची आहे ते तिच्यावर लिहिता. Pipeline image build करते, मग ती प्रत्यक्ष चालवून /healthz ला विचारते, म्हणजे फक्त कोड नाही तर डबाही चालतो हे सिद्ध होते. ती image ला पूर्ण commit SHA चे label लावते आणि ECR मध्ये ठेवते, म्हणजे नेमका कोणता कोड चालतो ते कोणालाही दिसते; :prod सारखे label काहीच सांगत नाही.
📖 नवे शब्दbuild — कोड आणि Dockerfile पासून image बनवणेsmoke test — image सुरू होते आणि उत्तर देते का याची झटपट तपासणीcommit SHA — एका git commit चा अनोखा ID; एक tag म्हणजे एक commitpush — cluster ला pull करता यावी म्हणून image registry (ECR) वर upload करणे
⏪ आधी
Runner वर unit tests pass व्हायचे, तरीही COPY मधील हरवलेली file किंवा चुकीच्या CMD मुळे image fail होऊ शकायची.
💡 काय
Photocopier step image build करते, copy चालते हे सिद्ध करते, तिला commit SHA चे लेबल लावते आणि ठेवते.
⚙️ कसे
docker build, smoke test म्हणून docker run -d -p 3000:3000 आणि curl /healthz, मग ECR ला docker push.
🎯 का
एक tag म्हणजे एक commit, म्हणून SHA वर git show नक्की कोणता कोड चालतो ते सांगतो; :prod काहीच सांगत नाही.
🚀 पुढे
ठेवलेली image अजून live नाही; पुढे ती आधी staging ला जाते आणि production साठी नावासह सही लागते.
🧪 Try it here — प्रत बनवा आणि डबा smoke-test करा; image मोडा
8 🛑 Environments & मंजुरीचे गेट — प्राचार्यांची सही
सूचना आधी सराव फलकावर लावा; मुख्य फलकावर पोहोचण्याआधी नावानिशी व्यक्ती सही करते — आणि प्रत्येक सही नोंदली जाते.
🧒 सोप्या शब्दांत
सूचना आधी सरावाच्या फलकावर लावली जाते, आणि मुख्याध्यापकांची सही झाल्यावरच मुख्य फलकावर जाते. Pipelines environments तसेच वापरतात: नवे version staging वर जाऊन तपासले जाते, मग production आधी ठरलेल्या reviewer ने Approve click करावे लागते, आणि ती सही log होते. Branch protection मुळे कोणीही, admin सुद्धा, तपासण्या टाळू शकत नाही.
📖 नवे शब्दenvironment — staging किंवा production सारखी deploy करण्याची नाव असलेली जागा, स्वतःच्या नियमांसहstaging — खऱ्या system ची सरावाची copy, खरे users पाहण्याआधी तपासली जातेapproval gate — ठरलेली व्यक्ती Approve click करेपर्यंत pipeline थांबतेbranch protection — main वरचे नियम: बदल फक्त review झालेल्या, हिरव्या check असलेल्या pull request मधून
⏪ आधी
बदल सराव न करता थेट production ला जायचे, आणि कोणी होकार दिला याची नोंद नसायची.
💡 काय
Environment म्हणजे स्वतःचे नियम आणि secrets असलेले नाव दिलेले target; production साठी reviewer आवश्यक करता येतो.
⚙️ कसे
Staging ला deploy करून curl /healthz करा, मग production चालण्याआधी required reviewer Approve वर click करतो.
🎯 का
प्रत्येक सही log होते, आणि branch protection मुळे कोणीही, admin सुद्धा, review टाळू शकत नाही.
🚀 पुढे
मंजुरी मिळाल्यावर पुढे जुने pods नव्यांनी कसे बदलायचे आणि सुरक्षित rollback कसा करायचा ते निवडाल.
🧪 Try it here — commit production पर्यंत न्या; reviewer ठरवतो
9 🔁 Deploy च्या पद्धती & rollback — टाचण्या एक एक करून बदला
फलकावरची सूचना बदलण्याचे चार मार्ग, आणि कालची परत लावण्याचा कंटाळवाणा, भरवशाचा मार्ग.
🧒 सोप्या शब्दांत
फलकावरच्या सूचना बदलायला एक-एक टाचणी बदलता येते, फलक रिकामा करून पुन्हा भरता येतो, दुसरा फलक तयार करून फिरवता येतो, किंवा नवी सूचना आधी काही विद्यार्थ्यांना दाखवता येते. हे आहेत rolling, recreate, blue/green आणि canary. इथे वापरलेले rolling pods एक-एक करून बदलते, म्हणून ॲप कधीच बंद पडत नाही. नवे वाईट निघाले तर rollback कालचे परत आणते.
📖 नवे शब्दrolling — जुने pods थोडे-थोडे करून नव्यांनी बदलणे, ॲप बंद न पडताblue/green — जुने आणि नवे शेजारी चालवणे, मग सगळ्यांना एकदम नव्याकडे वळवणेcanary — आधी थोड्याच users ना नव्या version कडे पाठवून errors वर लक्ष ठेवणेrollback — शेवटच्या चालणाऱ्या version कडे परत जाणेdowntime — ॲप कोणालाच उत्तर देत नाही असा वेळ
⏪ आधी
सगळ्या copies एकदम बदलल्या की काहीच serve न होण्याचा gap यायचा, आणि वाईट release मधून पटकन परत जाता येत नव्हते.
💡 काय
Deploy strategy म्हणजे notice कसा बदलायचा: rolling, recreate, blue/green किंवा canary.
⚙️ कसे
Rolling मध्ये readiness gates सह maxSurge: 1 आणि maxUnavailable: 0 वापरतात; kubectl rollout undo मागे नेतो.
🎯 का
Rolling मध्ये downtime नसतो, blue/green 2x खर्चात लगेच परत जाते, canary आधी काही users वर तपासते.
🚀 पुढे
पुढे delivery van CI मधून प्रत्यक्ष deploy करते आणि pods तयार होईपर्यंत rollout status ने थांबते.
🧪 Try it here — प्रत्येक पद्धतीने v2 आणा आणि उपलब्धता पहा
10 🚚 CI मधून Kubernetes वर deploy — डिलिव्हरी व्हॅन
व्हॅन डे पास घेऊन शाळेत जाते, manifest मध्ये image लिहिते, ती लावते, आणि नवी सूचना वाचनीय होईपर्यंत थांबते.
🧒 सोप्या शब्दांत
Delivery van ला gate pass मिळतो, ती नकाशावर शाळा शोधते, नवी सूचना देते आणि ती नीट लागली का ते पाहत थांबते. deploy.yml नेमके तेच करते: थोड्या वेळाचा AWS pass घेते, cluster चा पत्ता मिळवते, नवी image YAML मध्ये लिहिते, kubectl apply चालवते, आणि मग rollout status ने थांबून पाहते. ते थांबणे नसेल, तर नवे pods crash होत असतानाही pipeline हिरवी होते.
📖 नवे शब्दkubeconfig — cluster कुठे आहे आणि login कसे करायचे हे kubectl ला सांगणारी filekubectl apply — YAML cluster ला पाठवणे: "असे दिसू दे"rollout status — नवे pods खरोखर चालू होईपर्यंत थांबणे, नाही झाले तर अपयशpush model — pipeline बाहेरून cluster मध्ये जाऊन deploy करते
⏪ आधी
फक्त kubectl apply चालवणारी pipeline नवीन pods crash-loop होत असतानाही हिरवी व्हायची.
💡 काय
deploy.yml म्हणजे delivery van: ती day pass घेऊन cluster कडे जाते आणि तिथे नवीन image लावते.
⚙️ कसे
Pass घ्या, aws eks update-kubeconfig, sed ने image टाका, kubectl apply, मग rollout status --timeout=120s.
🎯 का
rollout status आणि cluster मधील curl /healthz मुळे नवीन pods निरोगी नसतील तर pipeline लाल होते.
🚀 पुढे
हे push model आहे; पुढे ArgoCD school ते उलटते, म्हणजे cluster मधील agent git मधून pull करतो.
🧪 Try it here — deploy job चालवा; rollout ची वाट वगळा किंवा नाही, आणि crash होणारी image पाठवा
11 🗣️ तीच pipeline चार बोलींमध्ये — चार कुरिअर कंपन्या, एक मार्ग
चार कुरिअर कंपन्या, एक मार्ग: फॉर्म वेगळे, तीन आज्ञा त्याच.
🧒 सोप्या शब्दांत
चार courier कंपन्या एकाच मार्गाने तोच parcel पोहोचवू शकतात; फक्त त्यांचे फॉर्म वेगळे दिसतात. GitHub Actions, CircleCI, GitLab CI आणि Jenkins तसेच आहेत: प्रत्येकाची स्वतःची file आणि cache, artifact, approval साठी स्वतःचा शब्द. पण आत चारही तेच तीन commands चालवतात: test, build, deploy. खरे काम scripts मध्ये ठेवा, म्हणजे बदलणे सोपे होते.
📖 नवे शब्दCI system — तुमच्या pipelines चालवणारी सेवा, उदा. GitHub Actions किंवा JenkinsJenkinsfile — Jenkins ची pipeline file; .gitlab-ci.yml आणि config.yml इतरांच्या filesstage — steps चा नाव असलेला गट, उदा. test किंवा buildportable — थोडेच बदल करून दुसऱ्या system वर नेता येते
⏪ आधी
फक्त एकच CI tool शिकले तर नवीन नोकरीतील CircleCI, GitLab किंवा Jenkins file परकी भाषा वाटते.
💡 काय
GitHub Actions, CircleCI, GitLab CI आणि Jenkins म्हणजे एकाच मार्गावर जाणाऱ्या चार courier कंपन्या.
⚙️ कसे
प्रत्येक जण cache, artifact आणि approval वेगळे लिहितो, जसे actions/cache@v4, save_cache, cache: key: किंवा stash.
🎯 का
Forms वेगळे पण तीन commands तेच, म्हणून logic scripts मध्ये ठेवले की कोणतीही pipeline सहज हलवता येते.
🚀 पुढे
कोणतीही बोली वापरली तरी पुढचा धडा कोणताही mailroom विश्वासार्ह ठेवणारे नियमपुस्तक देतो.
🧪 Try it here — CI system आणि एक कल्पना निवडा — तिथे ती कशी लिहितात ते पहा
12 🧹 Pipeline ची स्वच्छता & हस्तांतरण — नियमपुस्तकाचे पोस्टर
मेलरूमच्या भिंतीवरचे नियमपुस्तक, सगळे वाचतात तो गुणफलक, आणि ArgoCD शाळेकडे सोपवलेला दंडुका.
🧒 सोप्या शब्दांत
टपाल-खोलीच्या भिंतीवर नियमावली असते, आणि प्रत्येक नियम कधीतरी काहीतरी बिघडल्यामुळे आलेला असतो. Pipelines ची सुद्धा असते: actions नेमक्या version ला pin करा, default म्हणून फक्त read permission द्या, main सुरक्षित ठेवा, flaky tests बाजूला काढा, timeouts ठेवा. मग चार DORA आकड्यांचा scoreboard दाखवतो: किती वेळा ship करता, किती जलद, किती वेळा बिघडते, किती लवकर सावरता.
📖 नवे शब्दpin to a SHA — हलवता येणाऱ्या tag ऐवजी action चे नेमके, न बदलणारे version वापरणेflaky test — कोड न बदलता कधी पास तर कधी नापास होणारी test; retry नको, वेगळी काढाDORA metrics — चार आकडे: deploy frequency, lead time, change failure rate, recovery timelead time — commit पासून तो बदल production मध्ये चालू होईपर्यंत किती वेळ
⏪ आधी
हलवलेल्या tags मधून malware गेले, tokens प्रत्येक repo मध्ये लिहू शकत, आणि "just flaky" tests वर्षभर दुर्लक्षित राहिल्या.
💡 काय
नियमपुस्तक poster pipeline hygiene चे नियम सांगते, आणि DORA scoreboard delivery चे चार आकडे मोजतो.
⚙️ कसे
Actions SHA वर pin करा, default contents: read ठेवा, main protect करा, flaky tests वेगळ्या करा, timeout-minutes लावा.
🎯 का
प्रत्येक नियम खऱ्या घटनेतून आला आहे, आणि DORA दाखवते की तुम्ही वारंवार ship करता आणि पटकन सावरता का, दिखाऊ आकड्यांशिवाय.
🚀 पुढे
Image ECR मध्ये गेली की CI थांबते; ArgoCD school baton घेते आणि cluster ला git मधून pull करू देते.
🧪 Try it here — टीमच्या सवयी ठरवा आणि तिचा DORA scoreboard वाचा
एक डेव्हलपर pull request उघडतो. CI तीन Node आवृत्त्यांवर चाचण्या चालवते, cache पुन्हा वापरते आणि JUnit अहवाल upload करते. main मध्ये merge झाल्यावर pipeline image build करते, तिची smoke-test करते, commit SHA ने tag करते आणि तात्पुरत्या credentials ने ECR मध्ये push करते. Staging आपोआप अद्ययावत होते; reviewer मंजुरी देतो; production readiness probe मागे एका वेळी एक pod असे बाहेर पडते. CI बदल तपासते · image हा artifact · tag ही आवृत्ती · environment हे गेट · rollout ही पद्धत. आता उत्तर द्या, प्रत्येकी एक वाक्य:
run कशाने सुरू झाला, आणि कोणती फाइल त्यासाठी कान देऊन होती?
तीन चाचणी job समांतर का चालले?
cache hit आहे की नाही हे काय ठरवते?
JUnit अहवाल कुठे जातो, आणि "if: always()" का?
push job ला साठवलेल्या key शिवाय AWS credentials कशी मिळाली?
deploy झालेली image नेमकी कशाने ओळखली जाते?
production job ला कशाने थांबवले, आणि मंजुरी कुठे नोंदली आहे?
rollout ने सेवा कधीच का बंद पाडली नाही?
rollback कसे कराल, आणि त्याच पद्धतीने का?
pipeline संपल्यावर कोणीच कशावर लक्ष ठेवत नाही — आणि कोणता कोर्स ते दुरुस्त करतो?
