सीआई/सीडी एक सुस्थापित सॉफ्टवेयर विकास सिद्धांत है। इंटरनेट सीआई/सीडी के बारे में बात करने वाले लेखों और पृष्ठों से भरा है। उनके पास हमेशा एक ही सीआई/सीडी छवि होती है। मुझे यकीन है कि आप उस छवि को जानते होंगे जिसके बारे में मैं बात कर रहा हूं।
मैंने इस विषय के बारे में दर्जनों लेख पढ़े और एंड-टू-एंड सीआई/सीडी पाइपलाइन के कार्यान्वयन का अनुभव किया। वास्तविकता यह है कि सीआई/सीडी पाइपलाइन को लागू करना लेखों को पढ़ने, सीआई/सीडी की समग्र तस्वीर को समझने और सिद्धांत का उपयोग करने से कहीं अधिक जटिल है। सीआई/सीडी पाइपलाइन विकास के लिए अंतःविषय और अनुभवी टीमों की आवश्यकता होती है।
यह आलेख बताता है कि पायथन एप्लिकेशन की न्यूनतम व्यवहार्य सीआई पाइपलाइन कैसे बनाई जाए। आप लेख की सामग्री को अन्य भाषाओं और आवश्यकताओं के अनुसार अनुकूलित कर सकते हैं। नमूना फास्टएपीआई और गिटहब क्रियाओं का उपयोग करता है।
GitHub उदाहरण: https://github.com/joan-mido-qa/ निरंतर-एकीकरण-example
मैं मौजूदा निरंतर एकीकरण विवरण में अपने दो सेंट जोड़ना चाहता हूं। निरंतर एकीकरण का अर्थ नियमित रूप से स्वचालित रूप से परीक्षण किए गए, स्वीकृत और वितरण योग्य कोड परिवर्तनों को प्रोजेक्ट रिपॉजिटरी में विलय करना है।
यह उदाहरण प्रत्येक 'पुल रिक्वेस्ट' या 'पुश टू मेन' इवेंट पर स्वचालित रूप से आवश्यक जांच निष्पादित करने के लिए GitHub क्रियाओं का उपयोग करता है ताकि यह गारंटी दी जा सके कि कोड रिपॉजिटरी गुणवत्ता मानकों पर कायम है। बाज़ार सीआई/सीडी उपकरणों का एक विविध संग्रह प्रदान करता है: जेनकिंस , ट्रैविस , सर्कलसीआई , गिटलैब, आदि। वह चुनें जो आपकी पाइपलाइन आवश्यकताओं के लिए सबसे उपयुक्त हो।
उदाहरण वर्कफ़्लो जाँचता है कि नया कोड प्री-कमिट चल रहे फ़ॉर्मेटिंग नियमों का पालन करता है। फिर, यह पाइटेस्ट का उपयोग करके छोटे परीक्षण निष्पादित करता है और अंत में, मध्यम परीक्षण को किन डी क्लस्टर पर हेल्म चार्ट एप्लिकेशन इंस्टॉल करता है।
आपका निरंतर एकीकरण वर्कफ़्लो आपकी टीम के आकार, परिपक्वता, आवेदन आवश्यकताओं और शाखा रणनीति पर निर्भर करेगा।
कोड परिवर्तनों को निष्पादित किए बिना उनका विश्लेषण करें। स्थैतिक विश्लेषण उपकरण जाँचते हैं कि आपका कोड फ़ॉर्मेटिंग नियमों का पालन करता है, अप्रचलित या दूषित निर्भरता का उपयोग नहीं करता है, और पढ़ने योग्य और काफी सरल है। वे प्रोग्रामिंग भाषा के आधार पर एंटी-पैटर्न और बग को कोड करने का भी सुझाव देते हैं।
हम बताएंगे कि प्री-कमिट को कैसे इंस्टॉल करें, कॉन्फ़िगर करें और चलाएं। आप प्री-कमिट को सोनार या सिंक जैसे अन्य विश्लेषण टूल के साथ जोड़ सकते हैं।
प्री- कमिट पायथन में लिखा गया एक टूल है। इसे अपने रिपॉजिटरी पर कॉन्फ़िगर करना उतना ही सरल है जितना कि एक YAML फ़ाइल बनाना और प्रत्येक कमिट से पहले आप जो संस्करण हुक चलाना चाहते हैं उन्हें जोड़ना। प्री-कमिट स्वचालित रूप से हुक द्वारा आवश्यक निर्भरताओं का प्रबंधन करता है और पाई गई त्रुटियों को स्वचालित रूप से ठीक करता है। यह कई फ़ाइल प्रकारों का समर्थन करता है: JSON, YAML, tf, py, ts, आदि।
बुनियादी ढांचे की लागत को आगे बढ़ाने से पहले स्थानीय रूप से अपने कोड की जांच करके बचाएं। आप पुश किए गए कोड के प्रारूप की जांच करने के लिए अपने सीआई पर प्री-कमिट चला सकते हैं।
प्री-कमिट टूल इंस्टॉल करें, कॉन्फ़िगर करें और चलाएं:
repos: - repo: https://github.com/pre-commit/pre-commit-hooks rev: v2.3.0 hooks: - id: check-yaml - id: end-of-file-fixer - id: trailing-whitespace
$ pip install pre-commit $ pre-commit install $ pre-commit run --all-files
पायथन हुक सुझाव:
यूनिट, एकीकरण और एंड-टू-एंड परीक्षण की परिभाषाएँ और दायरा कभी-कभी भिन्न होता है। जैसा कि मैंने सतत एकीकरण विवरण के साथ किया था, मैं Google परीक्षण प्रकारों में सॉफ़्टवेयर इंजीनियरिंग में अपने दो सेंट जोड़ूंगा:
छोटा : तेज़ परीक्षण। कोड के छोटे टुकड़ों का परीक्षण करें. टेस्ट डबल्स या नकली वातावरण (जैसे SQLite) का उपयोग करें। किसी कलाकृति के निर्माण के लिए इसकी आवश्यकता नहीं है। समय: ~ 60 सेकंड.
माध्यम : कोड के कई टुकड़ों के बीच परस्पर क्रिया का परीक्षण करें। उनमें कलाकृतियों का निर्माण, तीसरे पक्ष की कलाकृतियों (जैसे डेटाबेस ) का उपयोग करना और लोकलहोस्ट नेटवर्क से जुड़ना शामिल हो सकता है। नकली वातावरण (उदाहरण के लिए डॉकर-कंपोज़, काइंड, मिनिक्यूब, आदि) या बाहरी सेवाओं (उदाहरण के लिए Azure ब्लॉब स्टोरेज या AWS S3) का उपयोग। समय: ~300 सेकंड.
बड़े : वे उत्पादन-जैसे वातावरण (जैसे प्रदर्शन परीक्षण) का उपयोग करते हैं। समय: +900 सेकंड.
आपकी सतत एकीकरण पाइपलाइन पर मध्यम/बड़े परीक्षण होना या न होना आपकी आवश्यकताओं पर निर्भर करता है।
उदाहरण परीक्षण चलाने के लिए पाइटेस्ट का उपयोग करता है और पर्यावरण का मज़ाक उड़ाने के लिए फास्टएपीआई परीक्षण क्लाइंट का उपयोग करता है। कोई रहस्य नहीं; आपके प्रोग्रामिंग भाषा परीक्षण उपकरण को आपके एप्लिकेशन का परीक्षण करने के लिए सभी आवश्यक निर्भरताएँ प्रदान करनी चाहिए।
इसके अतिरिक्त, आप न्यूनतम परीक्षण कवरेज जांच जोड़ सकते हैं और इसे अपने परिणामों के हिस्से के रूप में अपलोड कर सकते हैं। परीक्षण कवरेज एक पेचीदा मीट्रिक है. एक उच्च परीक्षण कवरेज का मतलब स्पष्ट रूप से एक अच्छी तरह से परीक्षण किया गया कोड नहीं है, लेकिन 50%, 0% परीक्षण किए गए कोड से अधिक है।
Kin D एक डॉकर-इन-डॉकर लाइटवेट कुबेरनेट्स क्लस्टर है जिसका उपयोग स्थानीय विकास या CI के लिए किया जाता है। हम एक परीक्षण वातावरण स्थापित करने और उसके विरुद्ध परीक्षण चलाने के लिए काइंड का उपयोग करते हैं:
काइंड आपकी छवि को डाउनलोड करने में विफल हो जाएगा क्योंकि यह रजिस्ट्री से डाउनलोड करने योग्य नहीं है। प्रकार के लिए आवश्यक है कि छवि का उपयोग करने से पहले उसे लोड किया जाए।
मेटलएलबी एक बेअर मेटल कुबेरनेट्स लोड-बैलेंसर है। मेटलएलबी वेब पेज पर लोड-बैलेंसर की आवश्यकता क्यों है, इसके बारे में और पढ़ें।
एक बार हेल्म चार्ट का उपयोग करके स्थापित करने के बाद, हम आवश्यक सीआरडी बना सकते हैं:
--- apiVersion: metallb.io/v1beta1 kind: L2Advertisement metadata: name: kind-advertisement --- apiVersion: metallb.io/v1beta1 kind: IPAddressPool metadata: name: kind-address-pool spec: addresses: - "172.26.255.0/24"
डॉकर काइंड क्लस्टर के लिए एक सबनेट बनाता है (जैसे 172.26.0.0/16)। निर्दिष्ट IP पता सीमा जानने के लिए Kind नेटवर्क इंटरफ़ेस का निरीक्षण करें और IPAddressPool संसाधन के मान के रूप में पते का उपयोग करें। मेटलएलबी कॉन्फ़िगरेशन के बारे में अधिक जानकारी KinD वेब पेज पर है।
इनग्रेस-नेग्नेक्स हेल्म चार्ट स्थापित करें। फिर, एक इनग्रेस ऑब्जेक्ट को परिभाषित करते हुए अपना एप्लिकेशन हेल्म चार्ट इंस्टॉल करें। ingressClassName प्रॉपर्टी को nginx पर सेट करें और एक होस्ट परिभाषित करें (जैसे api.local)। अंत में, निम्नलिखित पंक्ति को जोड़ने के लिए /etc/host को संशोधित करें:
192.168.1.10 api.local
आप एक ही पते की ओर इशारा करते हुए जितने चाहें उतने होस्ट परिभाषित कर सकते हैं। बाकी काम Nginx करेगा।
काइंड का उपयोग करके स्थानीय परिवेश को प्रारंभ करने, अपडेट करने और हटाने के लिए एक टूल विकसित करें। डेवलपर्स इसका उपयोग एप्लिकेशन को आसानी से डीबग करने, स्थानीय रूप से रिपोर्ट किए गए बग को पुन: उत्पन्न करने या सीआई पर परीक्षण चलाने के लिए कर सकते हैं।
यह उदाहरण लिनक्स आधारित वितरणों के लिए काम करता है। Windows/MacOS वैसे काम नहीं कर सकता जैसा वह कर रहा है, परिवर्तन की आवश्यकता हो सकती है।
आवश्यक कलाकृतियाँ वितरित करने से पहले, वर्कफ़्लो लाइनिंग और परीक्षण चरणों को निष्पादित करता है।
हम कलाकृतियों की रिलीज़ को प्रबंधित करने के लिए कमिटिज़ेन का उपयोग करते हैं। Commtizen स्वचालित रूप से आर्टिफैक्ट संस्करण को अपडेट करता है और परिवर्तनों को आगे बढ़ाता है। यह कॉन्फ़िगर किए गए टैग प्रारूप के साथ एक नया git टैग बनाता है। आप नवीनतम परिवर्तनों के साथ अपने चेंजलॉग को अपडेट करने के लिए कमेटिज़न को भी कॉन्फ़िगर कर सकते हैं।
[tool.commitizen] tag_format = "v$major.$minor.$patch" version_scheme = "semver" version_provider = "pep621" major_version_zero = true update_changelog_on_bump = true version_files = [ "charts/ci-example/Chart.yaml:version", "charts/ci-example/Chart.yaml:appVersion" ]
डॉकर इमेज और हेल्म चार्ट टैग सेट करने के लिए वर्कफ़्लो कमिटिज़न आउटपुट संस्करण का उपयोग करता है।
आपके पास प्रत्येक आर्टिफैक्ट (छवि और चार्ट) के लिए अलग-अलग संस्करण हो सकते हैं। लेकिन तब आपका चार्ट और छवि परिवर्तन पश्चगामी संगत होना चाहिए। यह विकास और रिलीज़ प्रक्रिया में जटिलता बढ़ा देगा। इससे बचने के लिए, हम दोनों कलाकृतियों के लिए एक ही संस्करण का उपयोग करते हैं।
यह आलेख एक सरल लेकिन कार्यात्मक सतत एकीकरण वर्कफ़्लो का वर्णन करता है। अन्य प्रोग्रामिंग भाषाओं के लिए काम करने या आपकी आवश्यकताओं को पूरा करने के लिए इसमें बदलाव की आवश्यकता हो सकती है, लेकिन कुछ चरण आसानी से निर्यात योग्य होने चाहिए और वैसे ही काम करने चाहिए जैसे वे हैं।
सीआई/सीडी व्यावहारिक: सतत परिनियोजन [भाग 2] जल्द ही आ रहा है...