← कोर्सच्या मुख्य पानाकडे परत

⏮️ आधी काय होते & फायदे-तोटे

प्रत्येक साधनाने काहीतरी वाईट गोष्ट बदलली — आणि तेच साधन कुठेतरी चुकीचे ठरते. या कोर्समधील प्रत्येक मोठ्या कल्पनेसाठी: ती येण्याआधी जीवन कसे होते, तिचे प्रामाणिक फायदे ✅ आणि तोटे ❌, आणि कुठे वापरावी 👍 विरुद्ध कुठे नाही 👎.

📮 Continuous Integration — धडे 01–05

⏮️ CI च्या आधी

मर्ज-डे चे युग: प्रत्येक जण आठवडे-आठवडे स्वतःच्या खाजगी प्रतीवर काम करत असे, मग सत्राच्या शेवटी सगळे एकत्र जोडले जाई — conflict, compile न होणारे build, दिवसच्या दिवस ते चिकटवण्यात घालवणारा एक 'build master', आणि कोणीतरी विसरलेली छापील चाचणी-यादी. रात्रीच्या build ने थोडी मदत केली; CI सर्व्हर (CruiseControl 2001, Hudson/Jenkins 2005–2011) आणि नंतरच्या hosted सेवांनी प्रत्येक push तपासणे ही कामाची सामान्य पद्धत बनवली.

✅ फायदे

  • आठवड्यांऐवजी मिनिटांत अभिप्राय
  • छोटे merge → छोटे conflict
  • 'पूर्ण झाले' ची एकच सामायिक व्याख्या: हिरवे = merge करण्यायोग्य
  • प्रत्येक run साठी स्वच्छ, पुन्हा पुन्हा तसेच वातावरण

❌ तोटे

  • pipeline हा आता तुम्ही सांभाळायचा कोड आहे
  • संथ किंवा लहरी (flaky) चाचण्या हिरव्या खुणेवरचा विश्वास घालवतात
  • मोठ्या प्रमाणावर runner ची मिनिटे पैसे खातात
  • प्रत्येक विक्रेत्याचे YAML ही स्वतःची बोली आहे (धडा 11)

👍 वापरा जेव्हा

  • कोडला एकापेक्षा जास्त माणसे हात लावतात
  • जे एकापेक्षा जास्त वेळा ship होते ते काहीही
  • चालवण्यालायक चाचण्या असलेला कोणताही repo

👎 दोनदा विचार करा जेव्हा

  • फेकून द्यायचा prototype
  • अजून चाचण्याच नाहीत — आधी तीन लिहा, मग pipeline
  • एका कॉफीपेक्षा जास्त वेळ घेणारा run — आणखी पायऱ्या जोडण्याआधी वेग सुधारा

आकृती ↗

📜 कोड म्हणून pipeline — धडे 02, 11

⏮️ कोड म्हणून pipeline च्या आधी

Build job एका सर्व्हरवर web UI मध्ये क्लिक करून करून बनवले जात, आणि तो सर्व्हर अपग्रेड करायची कोणाची हिंमत नसे; 'job 37' काहीतरी महत्त्वाचे करत असे आणि ते फक्त बॉबला माहीत असे. Jenkinsfile (2016), .gitlab-ci.yml, .circleci/config.yml आणि workflow फाइलींनी pipeline repo मध्ये, कोडच्या शेजारी आणली.

✅ फायदे

  • आवृत्तीबद्ध आणि pull request मध्ये review करण्याजोगे
  • प्रत्येक branch स्वतःची pipeline घेऊन येते
  • नव्या सर्व्हरवर पुन्हा तसेच उभे करता येते
  • काही बिघडले की diff करता येते

❌ तोटे

  • YAML चा पसारा आणि repo-repo मध्ये copy-paste
  • स्थानिक पातळीवर चालवणे अवघड (act, gitlab-ci-local — अपूर्ण)
  • YAML मध्ये लपलेले logic चाचणीला अवघड
  • बोलीत अडकणे (dialect lock-in)

👍 वापरा जेव्हा

  • नेहमी — ज्या pipeline वर एकापेक्षा जास्त माणसे अवलंबून आहेत तिच्यासाठी
  • जेव्हा 'हे आपण build कसे करतो?' ला एकच उत्तर असायला हवे: ती फाइल

👎 दोनदा विचार करा जेव्हा

  • YAML मध्ये logic लिहू नका — script किंवा package.json ला हाक मारा, म्हणजे YAML पातळ आणि portable राहते
  • लॅपटॉपवरून एकदाच चालवायची एखादी script

आकृती ↗

🪪 अल्पायुषी credentials (OIDC) — धडा 06

⏮️ OIDC च्या आधी

दीर्घकालीन cloud keys CI च्या secrets मध्ये चिकटवलेल्या, पाच repo मध्ये copy केलेल्या, क्वचितच बदललेल्या, आणि log, fork किंवा जुन्या लॅपटॉपमधून गळालेल्या — सार्वजनिक घटना-अहवालांमध्ये पुन्हा पुन्हा दिसणारी गोष्ट. OIDC federation मुळे CI run सहीबंद ओळख-token दाखवते आणि काही मिनिटांत संपणारी credentials मिळवते.

✅ फायदे

  • गळायला काहीच नाही — credentials एका job पुरती जगतात
  • trust policy ने एका repo/branch पुरती मर्यादित
  • प्रत्येक वापर run च्या ओळखीसह CloudTrail मध्ये नोंदला जातो
  • बदलण्याची (rotation) कटकट नाही

❌ तोटे

  • प्रत्येक cloud खात्यासाठी आणि CI विक्रेत्यासाठी एकदाची उभारणी
  • sub अट सूक्ष्मपणे चुकणे सोपे (खूप रुंद = कोणताही repo role घेऊ शकतो)
  • काही जुनी साधने अजूनही स्थिर keys अपेक्षितात

👍 वापरा जेव्हा

  • CI मधून AWS, GCP किंवा Azure वर कोणतीही deploy (तिन्ही support करतात)
  • जेव्हा एरवी एखादी key secret मध्ये चिकटवली गेली असती तो क्षण

👎 दोनदा विचार करा जेव्हा

  • आधीच cloud च्या आत असलेले self-hosted runner instance किंवा pod ओळख वापरू शकतात
  • जपण्यासारखे काहीच नसलेला वैयक्तिक sandbox — सुरुवातीला ठीक, पण त्याला पदवी देऊ नका

आकृती ↗

🛑 Environments & मंजुरीचे गेट — धडा 08

⏮️ गेटच्या आधी

ज्याच्याकडे production चा पासवर्ड असे तो deploy करत असे; बदलांच्या वेळा एका सामायिक spreadsheet मध्ये असत; 'शुक्रवारी deploy करू नका'; आणि कोणी काय मंजूर केले हे कोणीच सांगू शकत नसे. संरक्षण-नियम असलेली Environments production च्या पुढे एक नावानिशी माणूस, एक staging पायरी आणि एक audit नोंद उभी करतात.

✅ फायदे

  • प्रत्येक production बदलासाठी जबाबदार नावानिशी माणूस
  • आधी staging उघड चुका पकडते
  • audit नोंद फुकटात मिळते
  • स्फोटाच्या व्याप्तीवर नियंत्रण (कोणती branch कुठे deploy करू शकते)

❌ तोटे

  • गेट कालांतराने नुसते शिक्के बनतात
  • मंजुऱ्यांची रांग लागते आणि lead time ताणला जातो
  • कधीच नाही न म्हणणारे गेट म्हणजे निव्वळ विलंब
  • रात्री 2 वाजता माणसे वाईट मंजुरी देतात

👍 वापरा जेव्हा

  • production आणि नियमबद्ध (regulated) असे काहीही
  • नव्या pipeline चे पहिले काही महिने, विश्वास उभा राहत असताना

👎 दोनदा विचार करा जेव्हा

  • staging आणि dev — पूर्ण automate करा
  • महिनोन्महिने काहीच नाकारले नसलेले गेट: त्याच्या जागी स्वयंचलित तपासणी ठेवा आणि मोजा

आकृती ↗

🔁 टप्प्याटप्प्याने delivery — धडा 09

⏮️ rolling / blue-green / canary च्या आधी

'देखभालीची वेळ 02:00–04:00', सगळे एकाच वेळी deploy करणारे big-bang deploy, आणि मागच्या आठवड्याचा tarball परत ठेवून केलेले rollback. Rolling update, blue/green आणि canary टाचण्या हळूहळू बदलतात — आणि कालची सूचना काही सेकंदांत परत लावू देतात.

✅ फायदे

  • वापरकर्त्यांसाठी downtime नाही
  • जलद rollback: परत पलटा किंवा आधीचा SHA पुन्हा deploy करा
  • सगळ्यांना दिसण्याआधी छोट्या तुकड्यातून शिका
  • readiness probe सोबत जोडी जमते — बिघडलेल्या pod ला traffic मिळतच नाही

❌ तोटे

  • जुने आणि नवे शेजारी शेजारी चालतात → release मागे-सुसंगत (backward compatible) असावी लागते
  • blue/green ला काही काळ दुप्पट क्षमता लागते
  • canary तुम्ही पाहत असलेल्या metrics इतकाच चांगला
  • database schema बदलांना expand/contract ची शिस्त लागते

👍 वापरा जेव्हा

  • वापरकर्त्यांसमोरच्या सेवा
  • SLO असलेले काहीही
  • वारंवार deploy करणारे संघ

👎 दोनदा विचार करा जेव्हा

  • batch job आणि एकदाच चालणाऱ्या script
  • schema मोडणारे बदल — आधी migrate करा
  • छोटी अंतर्गत साधने, जिथे क्षणभराचा खंड चालतो

आकृती ↗

🚚 Push-model CD (vs GitOps) — धडे 10, 12

⏮️ कोणतीही pipeline deploy करण्याआधी

ज्या लॅपटॉपकडे योगायोगाने kubeconfig असे त्यावरून kubectl apply — 'माझ्या cluster वर चालते'. Push pipeline ने ते पुन्हा पुन्हा करण्याजोगे केले: कुरिअर cluster पर्यंत जातो आणि apply करतो. ही मोठी सुधारणा आहे — एका आंधळ्या जागेसह, जिथून ArgoCD शाळा सुरू होते.

✅ फायदे

  • build आणि deploy साठी एकच साधन
  • run चा log हाच deploy चा log — समजायला सोपे
  • कोणत्याही लक्ष्यासाठी चालते: Kubernetes, VM, Lambda, S3 साइट

❌ तोटे

  • pipeline कडे cluster चा प्रवेश असतो — मौल्यवान लक्ष्य
  • नंतर cluster वर कोणीच लक्ष ठेवत नाही → drift
  • deploy ची स्थिती git मध्ये नाही, CI च्या इतिहासात राहते
  • अनेक cluster = CI मध्ये अनेक kubeconfig

👍 वापरा जेव्हा

  • सुरुवात करताना
  • Kubernetes नसलेली लक्ष्ये
  • एका संघाच्या मालकीचा एकच cluster

👎 दोनदा विचार करा जेव्हा

  • अनेक cluster किंवा अनेक संघ — ती ArgoCD शाळा (pull, self-heal, drift-मुक्त)
  • जेव्हा 'prod हाताने कोणी बदलले?' हा प्रश्न एकापेक्षा जास्त वेळा आला आहे

आकृती ↗

🏢 Hosted vs self-hosted CI — धडा 11

⏮️ hosted CI च्या आधी

टेबलाखाली ठेवलेला एक Jenkins बॉक्स, कधीच अपग्रेड न केलेला, release च्या दिवशी disk भरलेली. Hosted सेवा (Travis CI 2011, CircleCI 2011, GitLab CI 2012, GitHub Actions 2019) मेलरूम सेवा म्हणून विकतात; self-hosted runner मुळे यंत्रे तुमच्याकडे राहतात आणि वेळापत्रक SaaS कडे.

✅ फायदे

  • hosted: शून्य देखभाल, लवचिक, open source साठी मोफत कोटा
  • self-hosted: खाजगी network चा प्रवेश, खास hardware, मोठ्या प्रमाणावर अंदाज करता येणारा खर्च
  • दोन्हीतले उत्तम: hosted control plane + self-hosted runner

❌ तोटे

  • hosted: मिनिटे/credits ची बिले वाढतात, गोंगाट करणारे शेजारी, विक्रेत्याच्या मर्यादा
  • self-hosted: patch करणे, वाढवणे आणि सुरक्षित ठेवणे तुमचे काम
  • तडजोड झालेल्या self-hosted runner कडे तुमची secrets असतात

👍 वापरा जेव्हा

  • बहुतेक संघांसाठी, बहुतेक वेळा hosted
  • build ला खाजगी network, GPU लागत असतील किंवा compliance म्हणत असेल तेव्हा self-hosted runner

👎 दोनदा विचार करा जेव्हा

  • कोणी मालक नसताना स्वतःचा controller (अख्खा Jenkins) चालवणे
  • मिनिटे मोजण्याआधी 'पैसे वाचवायला' self-hosting

आकृती ↗