CI/CD क्या है? Continuous Integration और Delivery आसान भाषा में
CI/CD सॉफ़्टवेयर भेजने का एक तरीका है, जिसमें हर कोड बदलाव अपने आप बनाया और टेस्ट किया जाता है, और अगर वह पास हो जाए तो रिलीज़ के लिए तैयार या जारी कर दिया जाता है। CI (continuous integration) का मतलब है कि बदलाव बार-बार मिलाए जाते हैं और हर बार स्वचालित टेस्ट से जाँचे जाते हैं। CD (continuous delivery या deployment) का मतलब है कि जो बदलाव पास होते हैं, उन्हें पैक करके बहुत कम या बिना मैनुअल काम के यूज़र्स की ओर भेजा जाता है।
मकसद सीधा है: गलतियाँ किए जाने के कुछ मिनट बाद पकड़ लें, हफ़्तों बाद नहीं, जब कोई ग्राहक उन्हें खोजे।
AI से ऐप बनाते समय CI/CD क्यों मायने रखता है
AI बिल्डर कोड बदलाव तेज़ी से करते हैं। एक प्रॉम्प्ट दस फ़ाइलों को छू सकता है। यह गति तब तक अच्छी है जब तक चेकआउट पेज में बदलाव चुपचाप लॉगिन पेज को तोड़ न दे, और कोई यूज़र ईमेल न करे तब तक किसी को पता न चले।
CI/CD ठीक इसी के लिए सुरक्षा जाल है। यह मानने के बजाय कि हर बदलाव ठीक है, एक पाइपलाइन हर बार वही जाँचें चलाती है:
- क्या ऐप अब भी बिना एरर के बनता है?
- क्या स्वचालित टेस्ट अब भी पास होते हैं?
- क्या कोड प्रोजेक्ट के नियमों का पालन करता है (टाइप, फ़ॉर्मैटिंग, सुरक्षा जाँच)?
अगर कोई जाँच विफल हो, तो बदलाव यूज़र्स तक पहुँचने से पहले रुक जाता है। आपके कोड बदलाव जितने तेज़ होंगे, उतनी ही कीमती वह जाँच होगी जो न थकती है और न कोई कदम छोड़ती है।
रोज़मर्रा की एक मिसाल
एक बेकरी की कल्पना कीजिए जो हर सुबह दुकानों को ब्रेड बेचती है।
- CI/CD के बिना, हर बेकर एक हफ़्ते तक अपनी रेसिपी में अपने हिसाब से बदलाव करता है, फिर शुक्रवार रात सब मिलाते हैं और उम्मीद करते हैं कि ब्रेड अब भी फूलेगी। जब नहीं फूलती, तो किसी को नहीं पता कि किसका बदलाव गड़बड़ी की वजह है।
- CI के साथ, हर छोटा रेसिपी बदलाव तुरंत एक टेस्ट लोफ़ में बनाया जाता है और जाँचा जाता है: स्वाद, वज़न, आकार। गलत बदलाव उसी दिन पकड़ा जाता है, और आपको ठीक-ठीक पता होता है कि वह कौन सा था।
- CD के साथ, जाँच पास करने वाली ब्रेड सीधे डिलीवरी वैन में जाती है, हर बार एक ही तरीके से पैक और लेबल होकर, न कि सुबह 5 बजे कोई हाथ से डिब्बे भरता है।
जाँच बेकरों को बेहतर नहीं बनाती। वह उनकी गलतियों को सस्ता बना देती है।
CI/CD पाइपलाइन कैसे काम करती है
पाइपलाइन चरणों की एक सूची है जिसे CI/CD सेवा अपने आप चलाती है जब कुछ होता है, आमतौर पर तब जब कोई GitHub जैसे रिपॉज़िटरी पर कोड पुश करता है। एक आम पाइपलाइन ऐसी दिखती है:
| चरण | क्या होता है | क्या पकड़ती है |
|---|---|---|
| 1. ट्रिगर | कोड पुश होता है या pull request खुलता है | — |
| 2. इंस्टॉल | एक नई मशीन कोड और उसकी डिपेंडेंसी डाउनलोड करती है | गायब या टूटे पैकेज |
| 3. बिल्ड | ऐप को compile या bundle किया जाता है | सिंटैक्स और टाइप एरर, टूटे imports |
| 4. टेस्ट | स्वचालित टेस्ट चलते हैं | वे फ़ीचर जो अब काम नहीं करते |
| 5. जाँच | Linting, फ़ॉर्मैटिंग, सुरक्षा स्कैन | स्टाइल की समस्याएँ, ज्ञात कमज़ोर पैकेज, लीक हुई keys |
| 6. स्टेजिंग पर डिप्लॉय | ऐप प्रोडक्शन की टेस्ट कॉपी पर जाता है | ऐसी समस्याएँ जो सिर्फ़ असली वातावरण में दिखती हैं |
| 7. प्रोडक्शन पर डिप्लॉय | ऐप लाइव होता है, अपने आप या मंज़ूरी के बाद | — |
हर चरण किसी की लैपटॉप पर नहीं, एक साफ़ मशीन पर चलता है, इसलिए “मेरे कंप्यूटर पर चल रहा है” बहाना नहीं रह जाता। अगर कोई चरण विफल हो, तो पाइपलाइन रुक जाती है और बदलाव करने वाले को बताती है।
चरण एक कॉन्फ़िगरेशन फ़ाइल में तय होते हैं जो कोड के साथ रहती है। उदाहरण के लिए GitHub Actions में यह रिपॉज़िटरी के .github/workflows फ़ोल्डर में एक YAML फ़ाइल होती है।
Continuous delivery बनाम continuous deployment
“CD” शब्द अस्पष्ट है, और लोग इसे दोनों तरह से इस्तेमाल करते हैं:
| Continuous delivery | Continuous deployment | |
|---|---|---|
| टेस्ट अपने आप चलते हैं | हाँ | हाँ |
| रिलीज़ अपने आप पैक होती है | हाँ | हाँ |
| अपने आप लाइव होती है | नहीं — कोई इंसान “release” दबाता है | हाँ — हर पास हुआ बदलाव जारी होता है |
| किसके लिए अच्छा | ज़्यादातर छोटी टीमें, पैसे देने वाले यूज़र्स वाले ऐप्स | मज़बूत टेस्ट कवरेज और मॉनिटरिंग वाली टीमें |
Continuous deployment तभी अच्छा काम करता है जब टेस्ट अच्छे हों। अगर आपके टेस्ट चेकआउट को कवर नहीं करते, तो continuous deployment खुशी-खुशी एक टूटा हुआ चेकआउट भेज देगा।
एक उदाहरण: पाइपलाइन वाला बुकिंग ऐप
मान लीजिए आपके पास एक सैलून बुकिंग ऐप है, और उसका कोड एक GitHub रिपॉज़िटरी में है। आप AI बिल्डर से कहते हैं: “पहली बार आने वाले ग्राहकों के लिए 10% छूट जोड़ो।”
- बदलाव एक नई ब्रांच पर पुश होता है और एक pull request खुलता है।
- पाइपलाइन शुरू होती है। वह पैकेज इंस्टॉल करती है और ऐप बनाती है — यह पास होता है।
- वह टेस्ट चलाती है। एक टेस्ट, “लौटने वाला ग्राहक पूरी कीमत देता है”, विफल होता है: छूट हर किसी पर लग रही है।
- Pull request पर लाल निशान दिखता है। बदलाव merge नहीं हो सकता।
- आप AI से इसे ठीक करने को कहते हैं। वह एक सुधार पुश करता है; पाइपलाइन फिर चलती है और सब कुछ पास होता है।
- बदलाव merge होता है। पाइपलाइन उसे एक स्टेजिंग वातावरण पर डिप्लॉय करती है, जहाँ आप एक टेस्ट बुकिंग करके देखते हैं।
- आप मंज़ूरी देते हैं, और वह प्रोडक्शन पर डिप्लॉय होता है।
पाइपलाइन के बिना, चरण 3 वाली गलती आपके ग्राहकों की जेब तक पहुँच जाती।
मुख्य शब्द
| शब्द | मतलब |
|---|---|
| पाइपलाइन | हर बदलाव पर चलने वाले चरणों का स्वचालित क्रम। |
| Build | सोर्स कोड को ऐसी चीज़ में बदलना जो चल सके। |
| स्वचालित टेस्ट | ऐसा कोड जो जाँचता है कि दूसरा कोड वही करता है जो उसे करना चाहिए। |
| Pull request (PR) | प्रस्तावित बदलाव, जिसे merge से पहले दूसरे (और पाइपलाइन) जाँचते हैं। देखें GitHub क्या है। |
| Branch | बदलावों की एक अलग लाइन, ताकि अधूरा काम मुख्य कोड को प्रभावित न करे। |
| Staging | आपके ऐप की एक निजी कॉपी जो प्रोडक्शन जैसी दिखती है, ताकि यूज़र्स से पहले बदलाव जाँचे जा सकें। |
| Production | लाइव ऐप जिसे आपके यूज़र्स इस्तेमाल करते हैं। |
| Rollback | रिलीज़ गड़बड़ होने पर पिछले काम करने वाले वर्ज़न पर वापस जाना। |
| हरा / लाल build | पाइपलाइन चलने का पास होना / विफल होना। |
आम गलतफ़हमियाँ
- “CI/CD का मतलब है मेरे ऐप की टेस्टिंग हो रही है।” पाइपलाइन सिर्फ़ वही टेस्ट चलाती है जो आपके पास हैं। अगर कोई टेस्ट नहीं हैं, तो CI सिर्फ़ यह साबित करता है कि ऐप बनता है, इससे ज़्यादा कुछ नहीं। अपने AI से सबसे ज़रूरी फ़्लो के लिए टेस्ट लिखवाएँ।
- “CI/CD सिर्फ़ बड़ी कंपनियों के लिए है।” GitHub Actions जैसे होस्टेड टूल को सेट करने के लिए एक छोटी कॉन्फ़िगरेशन फ़ाइल लगती है, और छोटी टीमें इन्हें लगातार इस्तेमाल करती हैं। मेहनत टूलिंग की नहीं, टेस्ट की लगती है।
- “अपने आप डिप्लॉय होने का मतलब है कि कोई कुछ नहीं जाँचता।” अच्छी पाइपलाइन जाँचें जोड़ती हैं, हटाती नहीं। कई टीमें प्रोडक्शन से पहले एक इंसानी मंज़ूरी का कदम रखती हैं।
- “अगर पाइपलाइन हरी है, तो ऐप काम करता है।” इसका मतलब है कि स्वचालित जाँचें पास हुईं। फिर भी बदलाव खुद आज़माएँ, आदर्श रूप से प्रिव्यू या स्टेजिंग पर।
- “CI/CD बैकअप की जगह ले लेता है।” ऐसा नहीं है। टेस्ट पास करने वाला खराब डेटाबेस माइग्रेशन फिर भी असली डेटा खराब कर सकता है। बैकअप और rollback का तरीका रखें।
अपने AI बिल्डर से क्या पूछें
- “साइन-अप, लॉगिन और चेकआउट के लिए स्वचालित टेस्ट लिखो, और दिखाओ कि उन्हें कैसे चलाया जाए।”
- “एक GitHub Actions workflow सेट करो जो हर pull request पर डिपेंडेंसी इंस्टॉल करे, ऐप बनाए और टेस्ट चलाए।”
- “पाइपलाइन में type check और linter जोड़ो, और एरर पर उसे विफल करो।”
- “पाइपलाइन का हर चरण सरल भाषा में समझाओ।”
- “अगर डिप्लॉय बीच में विफल हो जाए तो क्या होगा? मैं rollback कैसे करूँ?”
- “जाँचो कि रिपॉज़िटरी में या पाइपलाइन लॉग में कोई सीक्रेट सीधे लिखा हुआ न हो।”
अगर आपके ऐप में API keys हैं, तो पाइपलाइन को भी उनकी ज़रूरत होगी, CI टूल में एन्क्रिप्टेड सीक्रेट्स के रूप में, कॉन्फ़िगरेशन फ़ाइल में कभी नहीं। देखें एनवायरनमेंट वेरिएबल और सीक्रेट्स।
CI/CD और Mythex
Mythex आपके लिए CI पाइपलाइन नहीं चलाता, लेकिन अपने तरीके से इनमें से कुछ ज़रूरतें पूरी करता है:
- चेकपॉइंट। हर सफल एजेंट टर्न के बाद Mythex एक git चेकपॉइंट सहेजता है, और अगर कोई बदलाव गलत गया तो Revert to this point प्रोजेक्ट को वापस ले जाता है। देखें Chat।
- App Testing।
/testटाइप करें और एजेंट आपके लाइव प्रीव्यू में एक यूज़र की तरह क्लिक करके चलता है और टूटे फ़्लो की रिपोर्ट देता है, जो हर पब्लिश से पहले उपयोगी है। देखें App Testing। - पब्लिश करना एक जानबूझकर किया गया कदम है। बदलाव पहले निजी प्रिव्यू में दिखते हैं; आपका सार्वजनिक ऐप सिर्फ़ तब अपडेट होता है जब आप दोबारा पब्लिश करते हैं, यानी यह continuous deployment से ज़्यादा continuous delivery के करीब है।
- GitHub sync (Pro)। प्रोजेक्ट को GitHub रिपॉज़िटरी से sync करें, तो हर push पर टेस्ट चलाने के लिए अपने GitHub Actions workflows जोड़ सकते हैं। देखें GitHub और export।
लाइव होने से पहले हाथ से क्या टेस्ट करें, उसकी चेकलिस्ट के लिए देखें लॉन्च से पहले अपने ऐप को कैसे टेस्ट करें, और वर्ज़न कंट्रोल के लिए AI से बने ऐप के साथ Git कैसे इस्तेमाल करें।
सवाल
CI/CD का पूरा नाम क्या है?
CI का मतलब है continuous integration: हर कोड बदलाव बार-बार मिलाया जाता है और अपने आप बनाया और टेस्ट किया जाता है। CD का मतलब है continuous delivery या continuous deployment: जो बदलाव टेस्ट पास करते हैं, वे रिलीज़ के लिए अपने आप तैयार किए जाते हैं (delivery), या बिना किसी मैनुअल कदम के यूज़र्स तक भेज दिए जाते हैं (deployment)।
Continuous delivery और continuous deployment में क्या फ़र्क है?
Continuous delivery में हर बदलाव जो पाइपलाइन पास करता है, रिलीज़ के लिए तैयार होता है, लेकिन उसे लाइव कब करना है यह अब भी कोई इंसान तय करता है। Continuous deployment में हर पास हुआ बदलाव अपने आप लाइव हो जाता है, बिना किसी मानवीय मंज़ूरी के।
क्या AI से बने छोटे ऐप के लिए मुझे CI/CD चाहिए?
पहले ही दिन नहीं। कुछ यूज़र्स वाला छोटा ऐप प्रिव्यू में टेस्टिंग और हाथ से पब्लिश करके काम चला सकता है। CI/CD तब फ़ायदेमंद होता है जब कई लोग कोड बदलने लगें, जब असली ग्राहक ऐप पर निर्भर हों, या जब पहले चलने वाली चीज़ें बार-बार टूटने लगें।
CI/CD के लिए कौन से टूल इस्तेमाल होते हैं?
आम टूल्स में GitHub Actions, GitLab CI/CD, CircleCI और Jenkins शामिल हैं, साथ ही होस्टिंग प्लेटफ़ॉर्म की अपनी बिल्ट-इन डिप्लॉय पाइपलाइन। इन सबका बुनियादी काम एक ही है: कोड बदलने पर चरणों की सूची अपने आप चलाना।