भाग 1: तपासा (हिरवे, धडे 1–6) · भाग 2: पोहोचवा (केशरी, धडे 7–10) · भाग 3: खरे जग (नीळसर जांभळे, धडे 11–12). प्रत्येक चित्रातील वर्तुळातील क्रमांक 1 → 2 → 3 अनुसरा.
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 वाचा