मॉड्यूल 2 · Software development lifecycle

कंटीन्यूअस इंटीग्रेशन, डिलीवरी और डिप्लॉयमेंट

Mutqan Soft QA टीम द्वारा · · 17 मिनट · शुरुआती

Continuous integration (CI), continuous delivery और continuous deployment तीन practices हैं, और हर एक अपने से पहले वाली पर बनती है। CI में developers अपना काम कम से कम रोज़ एक साझा mainline में merge करते हैं, और हर merge को tests वाला एक automated build verify करता है। Continuous delivery pipeline पास करने वाले हर बदलाव को release के लायक बनाए रखती है, ताकि टीम जब चाहे उसे deploy कर सके। Continuous deployment यह फ़ैसला हटा देती है: हर पास होने वाला बदलाव अपने-आप production में जाता है।

Invoices पर VAT की rounding का एक fix लीजिए। CI के साथ वह उसी दिन merge होता है और मिनटों में verify होता है। Continuous delivery के साथ वह staging environment पर भी tests पास करता है और release candidate बनकर तब तक इंतज़ार करता है जब तक product owner उसे release न करे। Continuous deployment के साथ आख़िरी automated check पास होते ही वह customers तक पहुँच जाता है।

यह क्यों ज़रूरी है

कभी-कभार integrate करना और कभी-कभार release करना, दोनों जोखिम भरे हैं। जब कई लोगों का हफ़्तों का काम एक साथ मिलता है, तो conflicts और integration defects जमा हो जाते हैं और कोई नहीं बता पाता कि किस बदलाव से कौन-सा failure आया। ये practices बड़ी, कभी-कभार होने वाली घटनाओं की जगह छोटी, बार-बार होने वाली घटनाएँ लाती हैं, जिनमें हर बदलाव तब जाँचा जाता है जब उसे लिखने वाले को वह अभी याद हो।

Tester के लिए practice तय करती है कि pipeline पहले से क्या साबित करती है, और क्या users के देखने से पहले कोई व्यक्ति बदलाव को जाँचता है। आपकी टीम असल में कौन-सी practice अपनाती है, यह जानकर आप समझते हैं कि किन risks के लिए अब भी आपकी ज़रूरत है।

Continuous integration: बार-बार merge करें, हर merge verify करें

Martin Fowler का व्यापक रूप से उद्धृत विवरण CI को ऐसी practice बताता है जिसमें टीम का हर सदस्य अपने बदलाव साझा codebase में कम से कम रोज़ merge करता है, और हर integration को tests सहित एक automated build verify करता है। आज सुबह के दो बदलावों के बीच का conflict जल्दी ठीक होता है; तीन हफ़्ते बाद मिले तो नहीं।

CI टीम की आदत है जिसे एक tool सहारा देता है, ख़ुद tool नहीं। हफ़्ते में एक बार लंबे समय तक चलने वाली branch को build करने वाला CI server, या कई दिन लाल छोड़ी गई main branch जिस पर लोग merge करते जा रहे हैं, CI tool तो है पर continuous integration नहीं। ये आदतें इसे काम करने लायक बनाती हैं:

  • Version control में एक साझा mainline, जिसमें product को build और test करने के लिए ज़रूरी सब कुछ हो।
  • Mainline पर हर push से चलने वाला self-testing build: वह automated tests चलाता है और किसी एक के भी fail होने पर fail होता है। कई टीमें हर pull request को merge से पहले भी build करती हैं।
  • मिनटों में नापा जाने वाला build, ताकि developers दूसरे काम पर जाने की बजाय फ़ैसले का इंतज़ार करें।
  • टूटा build पहले ठीक होता है: लाल mainline पर कोई नए बदलाव नहीं जोड़ता।

Continuous delivery और continuous deployment

Continuous delivery CI को merge से आगे ले जाती है। Pipeline product को एक बार build करती है, उसी build को production जैसे test environments में deploy करती है और वहाँ आगे की जाँचें चलाती है, जैसे API, end-to-end और non-functional tests। इन्हें पास करने वाला हर build एक release candidate है जिसे एक बटन दबाकर production में deploy किया जा सकता है; वह असल में कब जाएगा, यह business का फ़ैसला है।

Continuous deployment यह फ़ैसला हटा देती है: सभी automated stages पास करने वाला हर बदलाव अपने-आप production में deploy होता है। इसलिए इसके लिए continuous delivery ज़रूरी है, और continuous delivery के लिए CI।

दो terms उलझन पैदा करते हैं। "CD" दोनों के लिए इस्तेमाल होता है, इसलिए जब कोई टीम कहे कि वह "CI/CD" करती है, तो पूछें कि कौन-सा। और कुछ टीमें deployment (नया version production में चल रहा है) को release (users feature देख सकते हैं) से अलग रखती हैं, जैसे तैयार feature को किसी तय तारीख़ तक बंद रखकर।

CI verified mainline पर ख़त्म होता है, continuous delivery ऐसे release candidate पर जिसे deploy करना कोई व्यक्ति चुनता है, और continuous deployment हर पास बदलाव को अपने-आप production में भेजती है।

Continuous integration

कम से कम रोज़ merge; हर merge का build और test अपने-आप

  1. 1Mainline में mergeछोटे बदलाव, कम से कम रोज़
  2. 2Automated build और testsStatic checks, unit और component tests, मिनटों में
  3. 3Verified mainlineलाल हो जाए तो नए काम से पहले उसे ठीक करें
अंत में:
Verified mainline
Production का फ़ैसला कौन करता है:
CI का हिस्सा नहीं: अलग release process
Automated tests क्या तय करते हैं:
बदलाव mainline में जुड़ेगा या नहीं
किस पर टिकी है:
साझा mainline और self-testing build

Continuous delivery

हर पास build release के लायक; कब, यह व्यक्ति तय करता है

  1. 1CI पासवही verified बदलाव
  2. 2Staging पर deploy, आगे की जाँचAPI, end-to-end और non-functional tests; लोग explore करते हैं
  3. 3Release candidateकभी भी production में जा सकता है
  4. 4व्यक्ति तय करता है: deployBusiness के चुने हुए समय पर
अंत में:
Release candidate
Production का फ़ैसला कौन करता है:
एक व्यक्ति, जैसे product owner
Automated tests क्या तय करते हैं:
Build release के लायक है या नहीं
किस पर टिकी है:
Continuous integration

Continuous deployment

हर पास build अपने-आप production में

  1. 1CI पासवही verified बदलाव
  2. 2Staging पर deploy, आगे की जाँचहर अहम जाँच automated होनी चाहिए
  3. 3Production में अपने-आप deployकोई approve नहीं करता
  4. 4Post-deployment checksऔर monitoring; fail हों तो rollback
अंत में:
बदलाव production में live
Production का फ़ैसला कौन करता है:
कोई नहीं: pipeline पास करना ही फ़ैसला है
Automated tests क्या तय करते हैं:
बदलाव users तक पहुँचे या नहीं, बिना किसी और जाँच के
किस पर टिकी है:
Continuous delivery, और इसलिए CI

Stages उदाहरण के लिए हैं: असली pipelines टीम-दर-टीम अलग होती हैं।

हर practice में automated tests की भूमिका

तीनों practices में automated tests वह सबूत हैं जिस पर pipeline काम करती है; इनके बिना CI सिर्फ़ यह साबित करता है कि code build हो जाता है। बदलता यह है कि इस सबूत पर कितना कुछ टिका है। ISTQB Foundation syllabus यह भी कहता है कि DevOps में बहुत ज़्यादा automation के बावजूद user के नज़रिए से manual testing की ज़रूरत बनी रहती है।

  • CI: tests तय करते हैं कि बदलाव mainline में जुड़ सकता है या नहीं, इसलिए उन्हें तेज़ होना चाहिए: ज़्यादातर static checks, unit और component tests।
  • Continuous delivery: tests तय करते हैं कि build release के लायक है या नहीं। धीमे API, end-to-end और non-functional tests बाद में चलते हैं, सिर्फ़ उन builds पर जो तेज़ stages पास कर चुके हैं, और किसी के बटन दबाने से पहले लोग release candidate को explore कर सकते हैं।
  • Continuous deployment: users से पहले tests ही इकलौता gate हैं। जो risk pipeline नहीं जाँचती, वह कभी नहीं जाँचा जाता, इसलिए post-deployment checks, monitoring और तेज़ rollback safety net पूरा करते हैं।
  • हर practice में flaky test, यानी बेतरतीब ढंग से fail होने वाला test, safety net को कमज़ोर करता है: टीम re-run करना और लाल build को अनदेखा करना सीख जाती है, और असली failures निकल जाते हैं।

आज़माएँ: रिग्रेशन सिनेरियो जनरेटर

Worked example: एक बदलाव, तीन practices

एक online pharmacy free delivery की सीमा 200.00 SAR से घटाकर 150.00 SAR करती है। Log में pipeline का एक run दिखाया गया है; यह हिस्सा तीनों practices में एक जैसा है।

  • CI: 09:52 तक बदलाव merge हो चुका था और unit tests नई सीमा पर 149.99 और 150.00 जाँच चुके थे, और 199.99 भी, जिस पर पहले delivery charge लगता था और अब delivery free है। 09:44 पर कोई failure होता तो बदलाव main से बाहर रहता, जब वह developer के ज़हन में अभी ताज़ा था।
  • Continuous delivery: build 2.14.0+512 staging पर इंतज़ार करता है। Tester cart को explore करता है (free delivery का banner अब क्या कहता है? discount code के साथ ठीक 150.00 SAR का order?) और staging व production पर cart API के responses की तुलना करता है। Product owner इसे 14:00 बजे साप्ताहिक promotion के साथ release करता है।
  • Continuous deployment: वही build लगभग 10:12 पर बिना किसी के फ़ैसले के production में पहुँचता है। Post-deployment checks health endpoints को call करते हैं और cart का smoke test करते हैं; fail होने पर टीम rollback करती है। Exploratory सवाल merge से पहले पूछे जाने थे या automated checks में बदले जाने थे।
  • अगर 10:09 पर end-to-end stage fail होता, तो किसी भी practice में release candidate न बनता: बदलाव को pipeline रोकती है, कोई व्यक्ति नहीं।
Change: free delivery from 150.00 SAR (was 200.00 SAR)

09:40  pull request #418 opened
09:41  build .......................................... passed
09:44  static checks + unit tests ..................... passed
09:49  API tests against a temporary database ......... passed
09:52  merged to main
09:56  main: build + unit tests ....................... passed
10:01  build 2.14.0+512 deployed to staging
10:09  end-to-end checkout journeys on staging ........ passed
10:09  release candidate 2.14.0+512 is ready

आज़माएँ: API हेल्थ चेकर आज़माएँ: API रिस्पॉन्स कम्पेरेटर

आम गलतियाँ

  • CI server को ही continuous integration मान लेना: लंबे समय तक चलने वाली branches के हफ़्तेवार builds, या कई दिन लाल छोड़ी गई main branch, practice के बिना सिर्फ़ tool है।
  • "CD" बोलना पर यह न बताना कि कौन-सा। Continuous delivery में production से पहले किसी व्यक्ति का फ़ैसला रहता है, continuous deployment में नहीं, इसलिए test strategy भी अलग होती है।
  • यह मान लेना कि automation के बाद manual testing की ज़रूरत नहीं। Exploratory और acceptance testing अब भी वह पकड़ती हैं जिसका किसी ने अनुमान नहीं लगाया था; continuous deployment में ये merge से पहले की ओर खिसक जाती हैं।
  • धीमे end-to-end tests को पहले stage में रखना, जिससे developers फ़ैसले का इंतज़ार छोड़कर वैसे ही merge करने लगते हैं।
  • लाल build को हरा होने तक बार-बार re-run करना और उसे ठीक हुआ मान लेना।
  • Deployment और release को एक मान लेना: कोई feature production में चल रहा हो सकता है जबकि users के लिए अभी बंद है।

QA का नज़रिया

शुरुआत यह पता करके करें कि आपकी टीम असल में क्या करती है: काम कितनी बार mainline तक पहुँचता है, pipeline का हर stage क्या टेस्ट करता है, और क्या production deployment को कोई व्यक्ति approve करता है। हाल के pipeline runs पढ़ें: वे कहाँ fail होते हैं, हर stage कितना समय लेता है, और कितनी बार लाल build को बिना जाँच के re-run किया जाता है। इससे पता चलता है कि automation कौन-से risks कवर करता है और आपकी testing सबसे ज़्यादा कहाँ काम आती है।

फिर सही stage पर सही tests रखने में मदद करें: unit tests के लिए boundary और negative cases सुझाएँ, तय करें कि कौन-सी critical journeys end-to-end stage में जाएँ, और flaky test को owner वाले defect की तरह लें। Continuous delivery में exploratory testing release candidate के आसपास plan करें और लिखें कि कौन-सा build टेस्ट किया; continuous deployment में इसे story और pull request reviews में ले जाएँ, और पक्का करें कि rollback ख़ुद भी टेस्ट हो चुका है।

अभ्यास

Practice पहचानें और testing की कमी खोजें

आपका काम

चार टीमें बताती हैं कि वे कैसे काम करती हैं। हर टीम के लिए तय करें कि वह continuous integration, continuous delivery या continuous deployment अपनाती है, या इनमें से कुछ भी नहीं। फिर लिखें कि टीम C के automated tests को क्या कवर करना चाहिए, क्योंकि users के देखने से पहले कोई व्यक्ति उसके बदलाव नहीं जाँचता।

सामग्री
Team A  Developers दो से तीन हफ़्ते feature branches पर काम करते हैं। एक server
        हर रात main branch को build और test करता है। Branches हर monthly
        release से पहले merge होती हैं।

Team B  Developers दिन में कई बार छोटे pull requests main में merge करते हैं।
        हर pull request और हर merge लगभग 12 मिनट में build और test होता है।
        हर पास build अपने-आप staging पर deploy होता है और production में
        जा सकता है। Product owner हर गुरुवार "Deploy" दबाता है।

Team C  Developers दिन में कई बार main में merge करते हैं। Pipeline के सभी
        stages पास करने वाला हर merge अपने-आप production में deploy होता है,
        आम तौर पर 30 मिनट के अंदर।

Team D  Jenkins हर commit को build करता है, पर main चार दिन से लाल है।
        टीम merge करती जा रही है और "release से पहले tests ठीक करने" की सोच रही है।
चरण
  1. देखें कि काम कितनी बार mainline तक पहुँचता है और क्या हर merge tests वाले automated build से verify होता है।
  2. देखें कि क्या हर पास होने वाला build deployable है, और production में कब जाएगा यह कौन या क्या तय करता है।
  3. Practice का नाम लिखें, फिर टीम C के लिए ज़रूरी automated checks और उस टीम से एक सवाल लिखें।
मॉडल उत्तर दिखाएँ
मॉडल उत्तर

टीम A: तीनों में से कोई नहीं। काम सिर्फ़ हर release से पहले merge होता है और nightly build हर integration को नहीं, main को टेस्ट करता है, इसलिए समस्याएँ हफ़्तों जमा होती हैं। अकेला CI server, CI नहीं है।

टीम B: continuous delivery। काम दिन में कई बार main तक पहुँचता है और हर merge verify होता है (यही CI है), हर पास होने वाला build deployable है, और release कब हो यह एक व्यक्ति तय करता है।

टीम C: continuous deployment। यह टीम B जितनी ही बार integrate करती है, पर pipeline पास करना ही release का फ़ैसला है।

टीम D: practice के बिना CI tool। टूटा build पहले ठीक नहीं होता, इसलिए हर नया merge लाल mainline पर आता है और उसके नतीजे का कोई मतलब नहीं। इलाज है merge रोककर अभी main ठीक करना।

टीम C को हर अहम risk के लिए automated checks चाहिए: business rules के लिए unit और API tests, critical flows (sign-in, checkout, payment) के लिए कुछ end-to-end journeys, ज़रूरी non-functional checks, और पहले से आज़माए गए rollback के साथ post-deployment checks। एक अच्छा सवाल: ख़राब deployment को कितनी जल्दी rollback किया जा सकता है, और क्या किसी ने इसे आज़माया है?

अक्सर पूछे जाने वाले सवाल

क्या CI/CD एक tool है?

नहीं। Continuous integration और continuous delivery या deployment practices हैं। GitHub Actions, GitLab CI/CD या Jenkins जैसे tools वे pipelines चलाते हैं जो इन्हें सहारा देती हैं, लेकिन जो टीम कभी-कभार merge करती है या लाल build को अनदेखा करती है, वह कोई भी tool इस्तेमाल करे, CI नहीं कर रही।

क्या continuous deployment का मतलब है कि टीम में कोई tester नहीं?

नहीं। Tester का काम पहले की ओर खिसकता है और उसका रूप बदलता है: stories और pull requests review करना, automated checks design करना, post-deployment checks और rollback टेस्ट करना, और features को merge से पहले या users के लिए अभी बंद रहते हुए explore करना।

टीम को कौन-सी practice चुननी चाहिए?

CI दोनों का आधार है। Continuous delivery उन टीमों के लिए ठीक है जिनके release को business फ़ैसले, regulatory approval या दूसरी घटनाओं के साथ तालमेल की ज़रूरत होती है। Continuous deployment उन टीमों के लिए ठीक है जिन्हें अपने automated tests, monitoring और rollback पर इतना भरोसा है कि production से पहले कोई व्यक्ति कोई असली जाँच नहीं जोड़ेगा। एक टीम एक service के लिए continuous delivery और दूसरी के लिए continuous deployment भी अपना सकती है।

संदर्भ

  • Continuous Integration (Martin Fowler)martinfowler.com · 2024continuous integration का व्यापक रूप से संदर्भित विवरण: बार-बार integrate करें, build को self-testing और तेज़ रखें, टूटा build तुरंत ठीक करें।
  • ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
  • Eradicating Non-Determinism in Tests (Martin Fowler)martinfowler.com · 2011flaky टेस्ट सूट का मूल्य क्यों नष्ट करते हैं, उनके आम कारण (isolation, asynchrony, remote services, समय, resource leak) और जवाब के रूप में quarantine।
टूल्स

Mutqan tools से अभ्यास करें

रिग्रेशन सिनेरियो जनरेटर

बदलाव के विवरण और प्रभावित तथा संबंधित मॉड्यूल की सूची से रिग्रेशन सिनेरियो जनरेट करें।

टेस्ट डिज़ाइन

API हेल्थ चेकर

एक साथ कई API health endpoint जाँचें और स्टेटस, latency तथा pass/fail सारांश पाएँ।

API टेस्टिंग

API रिस्पॉन्स कम्पेरेटर

दो API रिस्पॉन्स (जैसे staging बनाम production) की तुलना करें और हर संरचनात्मक तथा वैल्यू का अंतर देखें।

API टेस्टिंग

और गहराई से

इस topic में आपकी प्रगति

QA रोडमैप का हिस्सा

इस topic से पहले