CI/CD म्हणजे काय? Continuous Integration आणि Delivery सोप्या भाषेत
CI/CD ही सॉफ्टवेअर पाठवण्याची अशी पद्धत आहे जिथे प्रत्येक कोड बदल आपोआप build, test केला जातो आणि — जर तो पास झाला तर — release साठी तयार केला जातो किंवा प्रसिद्ध केला जातो. CI (continuous integration) म्हणजे बदल वारंवार मर्ज केले जातात आणि प्रत्येक वेळी स्वयंचलित चाचण्यांनी तपासले जातात. CD (continuous delivery किंवा deployment) म्हणजे पास झालेले बदल कमी किंवा शून्य मॅन्युअल कामासह वापरकर्त्यांकडे पाठवले जातात.
मुद्दा साधा आहे: चूक केल्यानंतर काही मिनिटांत पकडा, आठवड्यांनंतर जेव्हा ग्राहक ती शोधतो तेव्हा नाही.
AI सह बनवताना CI/CD का महत्त्वाचे आहे
AI बिल्डर्स कोड बदल वेगाने करतात. एक prompt दहा फाइल्सना स्पर्श करू शकतो. हा वेग उत्तम आहे, जोपर्यंत चेकआउट पेजमधील बदल शांतपणे लॉगिन पेज तोडत नाही आणि एखादा वापरकर्ता ईमेल करेपर्यंत कोणाच्या लक्षात येत नाही.
नेमक्या याच गोष्टीसाठी CI/CD हे सुरक्षा जाळे आहे. प्रत्येक बदल ठीक आहे असे गृहीत धरण्याऐवजी, pipeline प्रत्येक वेळी तेच तपासणी चालवते:
- ॲप अजूनही त्रुटींशिवाय build होते का?
- स्वयंचलित चाचण्या अजूनही पास होतात का?
- कोड प्रोजेक्टचे नियम पाळतो का (types, formatting, सुरक्षा तपासण्या)?
कोणतीही तपासणी अयशस्वी झाली, तर बदल वापरकर्त्यांपर्यंत पोहोचण्याआधीच थांबवला जातो. तुमचे कोड बदल जितके वेगवान, तितकी न थकणारी आणि कोणतीही पायरी न वगळणारी तपासणी जास्त मौल्यवान.
दैनंदिन उदाहरण
रोज सकाळी दुकानांना ब्रेड पुरवणाऱ्या बेकरीचा विचार करा.
- CI/CD शिवाय, प्रत्येक बेकर आठवडाभर स्वतःच्या रेसिपीत बदल करतो, आणि मग शुक्रवार रात्री सर्व बदल एकत्र करून आशा करतो की ब्रेड अजूनही फुगेल. ती फसली, तर कोणाच्या बदलामुळे हे झाले हे कोणालाच कळत नाही.
- CI सह, प्रत्येक छोटा रेसिपी बदल लगेच एका चाचणी पावात भाजला जातो आणि तपासला जातो — चव, वजन, आकार. वाईट बदल त्याच दिवशी पकडला जातो, आणि कोणता बदल होता ते नक्की कळते.
- CD सह, तपासणी पास झालेल्या पाव नेहमीच्या पद्धतीने पॅक आणि लेबल केलेले थेट डिलिव्हरी व्हॅनवर जातात, पहाटे ५ वाजता कोणीतरी हाताने खोके भरत बसण्याऐवजी.
तपासणी बेकर्सना चांगले बनवत नाही. ती त्यांच्या चुका स्वस्त करते.
CI/CD pipeline कसे काम करते
Pipeline म्हणजे CI/CD सेवेने काहीतरी घडल्यावर आपोआप चालवलेल्या पायऱ्यांची यादी — सहसा कोड GitHub सारख्या repository मध्ये push केल्यावर. एक सामान्य pipeline असा दिसतो:
| पायरी | काय होते | काय पकडते |
|---|---|---|
| १. Trigger | कोड push केला जातो किंवा pull request उघडला जातो | — |
| २. Install | नवीन मशीन कोड आणि त्याची dependencies डाउनलोड करते | गहाळ किंवा तुटलेली packages |
| ३. Build | ॲप compile किंवा bundle केले जाते | Syntax आणि type errors, तुटलेले imports |
| ४. Test | स्वयंचलित चाचण्या चालतात | जी वैशिष्ट्ये आता चालत नाहीत |
| ५. Checks | Linting, formatting, सुरक्षा स्कॅन | Style समस्या, ज्ञात असुरक्षित packages, गळती झालेल्या keys |
| ६. Staging वर deploy | ॲप production च्या चाचणी प्रतीवर जाते | फक्त खऱ्या वातावरणात दिसणाऱ्या समस्या |
| ७. Production वर deploy | ॲप लाइव्ह होते — आपोआप किंवा मंजुरीनंतर | — |
प्रत्येक पायरी कोणाच्या लॅपटॉपवर नव्हे तर स्वच्छ मशीनवर चालते, त्यामुळे "माझ्या संगणकावर चालते" हे कारण उरत नाही. पायरी अयशस्वी झाली की pipeline थांबते आणि बदल करणाऱ्याला सांगते.
पायऱ्या एका configuration फाइलमध्ये परिभाषित केलेल्या असतात, जी कोडबरोबरच राहते. उदाहरणार्थ GitHub Actions मध्ये ती repository च्या .github/workflows फोल्डरमधील YAML फाइल असते.
Continuous delivery विरुद्ध continuous deployment
"CD" हा शब्द संदिग्ध आहे, आणि लोक तो दोन्ही प्रकारे वापरतात:
| Continuous delivery | Continuous deployment | |
|---|---|---|
| चाचण्या आपोआप चालतात | हो | हो |
| Release आपोआप पॅक होतो | हो | हो |
| आपोआप लाइव्ह होतो | नाही — व्यक्ती "release" वर क्लिक करते | हो — प्रत्येक पास झालेला बदल पोहोचतो |
| यासाठी चांगले | बहुतेक लहान टीम्स, पैसे देणारे वापरकर्ते असलेले ॲप्स | मजबूत चाचणी कव्हरेज आणि monitoring असलेल्या टीम्स |
Continuous deployment फक्त चांगल्या चाचण्या असतील तरच नीट चालते. जर तुमच्या चाचण्या चेकआउट कव्हर करत नसतील, तर continuous deployment आनंदाने तुटलेला चेकआउट पाठवत राहील.
एक उदाहरण: pipeline असलेले booking ॲप
समजा तुमचे सलून booking ॲप आहे, आणि त्याचा कोड GitHub repository मध्ये आहे. तुम्ही AI बिल्डरला सांगता: "पहिल्यांदा येणाऱ्या ग्राहकांसाठी १०% सूट जोडा."
- बदल नव्या branch मध्ये push केला जातो आणि pull request उघडला जातो.
- Pipeline सुरू होते. ते packages इन्स्टॉल करते आणि ॲप build करते — हे पास होते.
- ते चाचण्या चालवते. एक चाचणी, "परत येणारा ग्राहक पूर्ण किंमत देतो", अयशस्वी होते: सूट सर्वांना लागू होत आहे.
- Pull request वर लाल क्रॉस दिसतो. बदल merge करता येत नाही.
- तुम्ही AI ला दुरुस्ती करायला सांगता. ते सुधारणा push करते; pipeline पुन्हा चालते आणि सर्व पास होते.
- बदल merge होतो. Pipeline ते staging environment वर deploy करते, जिथे तुम्ही एक चाचणी booking करता.
- तुम्ही मंजुरी देता, आणि ते production वर deploy होते.
Pipeline नसते, तर पायरी ३ मधील चूक तुमच्या ग्राहकांच्या खिशात घडली असती.
महत्त्वाचे शब्द
| शब्द | अर्थ |
|---|---|
| Pipeline | प्रत्येक बदलावर चालणारी स्वयंचलित पायऱ्यांची मालिका. |
| Build | स्रोत कोडला चालू शकणाऱ्या गोष्टीत रूपांतरित करणे. |
| स्वयंचलित चाचणी (Automated test) | इतर कोड अपेक्षेप्रमाणे वागतो का ते तपासणारा कोड. |
| Pull request (PR) | प्रस्तावित बदल, जो इतर (आणि pipeline) तपासतात आणि मग merge होतो. GitHub म्हणजे काय पहा. |
| Branch | प्रगतीपथावरील काम मुख्य कोडवर परिणाम करू नये म्हणून बदलांची वेगळी ओळ. |
| Staging | production चे अनुकरण करणारी, वापरकर्त्यांनी पाहण्याआधी बदल तपासण्यासाठी तुमच्या ॲपची खाजगी प्रत. |
| Production | तुमचे वापरकर्ते वापरत असलेले लाइव्ह ॲप. |
| Rollback | release चुकल्यावर मागील कार्यरत आवृत्तीकडे परत जाणे. |
| हिरवा / लाल build | Pipeline चालवणे पास / अयशस्वी झाले. |
सामान्य गैरसमज
- "CI/CD म्हणजे माझे ॲप चाचणी केलेले आहे." Pipeline फक्त तुमच्याकडे असलेल्या चाचण्या चालवते. चाचण्याच नसतील, तर CI फक्त ॲप build होते हे सिद्ध करते — त्यापलीकडे काही नाही. सर्वात महत्त्वाच्या flows साठी चाचण्या लिहायला AI ला सांगा.
- "CI/CD फक्त मोठ्या कंपन्यांसाठी आहे." GitHub Actions सारखी hosted साधने सेट करायला छोटी configuration फाइल लागते, आणि छोट्या टीम्स त्या नेहमी वापरतात. प्रयत्न साधनांचे नव्हे, तर चाचण्यांचे लागतात.
- "स्वयंचलित deployment म्हणजे कोणी काही तपासत नाही." चांगली pipelines तपासण्या काढत नाहीत, तर जोडतात. अनेक टीम्स production पूर्वी मानवी मंजुरीची पायरी ठेवतात.
- "Pipeline हिरवा असेल तर ॲप काम करते." याचा अर्थ स्वयंचलित तपासण्या पास झाल्या. तरीही तुम्ही बदल स्वतः आजमावा, शक्यतो preview मध्ये किंवा staging वर.
- "CI/CD बॅकअपची जागा घेते." तसे नाही. चाचण्या पास होणारा वाईट database migration तरीही खरा डेटा खराब करू शकतो. बॅकअप आणि rollback चा मार्ग ठेवा.
तुमच्या AI बिल्डरला काय विचारावे
- "साइन अप, लॉगिन आणि चेकआउटसाठी स्वयंचलित चाचण्या लिहा, आणि त्या कशा चालवायच्या ते दाखवा."
- "प्रत्येक pull request वर dependencies इन्स्टॉल करणारी, ॲप build करणारी आणि चाचण्या चालवणारी GitHub Actions workflow सेट करा."
- "Pipeline मध्ये type check आणि linter जोडा, आणि त्रुटींवर ते अयशस्वी होऊ द्या."
- "Pipeline ची प्रत्येक पायरी काय करते ते सोप्या इंग्रजीत समजावून सांगा."
- "Deploy अर्धवट अयशस्वी झाला तर काय होते? Rollback कसा करू?"
- "Repository मध्ये किंवा pipeline logs मध्ये कोणतीही secret कोडमध्ये लिहिलेली किंवा छापलेली नाही याची खात्री करा."
तुमच्या ॲपला API keys लागत असतील, तर pipeline ना त्याही लागतात — त्या CI टूलमध्ये एन्क्रिप्टेड secrets म्हणून साठवलेल्या असाव्यात, configuration फाइलमध्ये कधीच नव्हे. पहा environment variables आणि secrets.
CI/CD आणि Mythex
Mythex तुमच्यासाठी CI pipeline चालवत नाही, पण त्याच काही गरजा स्वतःच्या पद्धतीने भागवते:
- Checkpoints. प्रत्येक यशस्वी एजंट turn नंतर Mythex git checkpoint जतन करते, आणि Revert to this point बदल चुकल्यास प्रोजेक्ट मागे नेते. पहा Chat.
- App Testing.
/testटाइप करा, आणि एजंट तुमच्या लाइव्ह preview मधून वापरकर्त्याप्रमाणे क्लिक करत जाऊन तुटलेले flows नोंदवते — प्रत्येक publish पूर्वी उपयुक्त. पहा App Testing. - Publishing ही जाणूनबुजून घेतलेली पायरी आहे. बदल आधी खाजगी preview मध्ये दिसतात; तुमचे सार्वजनिक ॲप तुम्ही पुन्हा publish केल्यावरच अपडेट होते — continuous deployment पेक्षा continuous delivery च्या जवळ.
- GitHub sync (Pro). प्रोजेक्ट GitHub repository सोबत sync करा, आणि प्रत्येक push वर चाचण्या चालवण्यासाठी स्वतःच्या GitHub Actions workflows जोडू शकता. पहा GitHub आणि export.
लाइव्ह जाण्यापूर्वी हाताने काय तपासायचे याच्या यादीसाठी लाँचपूर्वी ॲप कसे तपासावे आणि version control सह काम करण्यासाठी AI-built ॲपसोबत Git कसे वापरावे पहा.
प्रश्न
CI/CD चा अर्थ काय?
CI म्हणजे continuous integration: प्रत्येक कोड बदल वारंवार मर्ज केला जातो आणि आपोआप build व test केला जातो. CD म्हणजे continuous delivery किंवा continuous deployment: जे बदल तपासणी पास करतात ते release साठी आपोआप तयार केले जातात (delivery) किंवा कोणत्याही मॅन्युअल पायरीशिवाय वापरकर्त्यांपर्यंत पोहोचवले जातात (deployment).
Continuous delivery आणि continuous deployment मध्ये काय फरक आहे?
Continuous delivery मध्ये pipeline पास झालेला प्रत्येक बदल release साठी तयार असतो, पण तो कधी लाइव्ह करायचा हे अजूनही व्यक्ती ठरवते. Continuous deployment मध्ये पास झालेला प्रत्येक बदल आपोआप लाइव्ह होतो, कोणत्याही मंजुरीच्या पायरीशिवाय.
AI ने बनवलेल्या लहान ॲपला CI/CD लागते का?
पहिल्या दिवशी नाही. मूठभर वापरकर्ते असलेले लहान ॲप preview मध्ये चाचणी करून हाताने प्रकाशित करून चालू शकते. कोडमध्ये अनेक लोक बदल करू लागल्यावर, खरे ग्राहक ॲपवर अवलंबून असल्यावर, किंवा पूर्वी चालणाऱ्या गोष्टी सतत तुटत राहिल्यावर CI/CD उपयुक्त ठरते.
CI/CD साठी कोणती साधने वापरली जातात?
सामान्य पर्यायांमध्ये GitHub Actions, GitLab CI/CD, CircleCI आणि Jenkins, तसेच होस्टिंग प्लॅटफॉर्म्सच्या अंगभूत deploy pipelines यांचा समावेश होतो. ही सर्व साधने एकच मूलभूत काम करतात: कोड बदलला की पायऱ्यांची यादी आपोआप चालवणे.