रूसी संस्करण
आइए कल्पना करें कि आप सॉफ्टवेयर और हार्डवेयर उपकरण विकसित कर रहे हैं। उपकरण में कस्टम ओएस वितरण, अपस्केल सर्वर, बहुत सारे व्यापारिक तर्क हैं, नतीजतन, इसे वास्तविक हार्डवेयर का उपयोग करना पड़ता है। यदि आप टूटे हुए उपकरण जारी करते हैं, तो आपके उपयोगकर्ता खुश नहीं होंगे। स्थिर रिलीज कैसे करें?
मैं अपनी कहानी साझा करना चाहता हूं कि हमने इससे कैसे निपटा।
अवधारणा का प्रमाण
यदि आपको कोई लक्ष्य नहीं पता है तो कार्य के माध्यम से कोड़ा मारना वास्तव में कठिन होगा। पहले तैनात संस्करण को बैश की तरह देखा गया:
make dist for i in abc ; do scp ./result.tar.gz $i:~/ ssh $i "tar -zxvf result.tar.gz" ssh $i "make -C ~/resutl install" done
मुख्य विचार दिखाने के लिए स्क्रिप्ट को सरल बनाया गया: कोई CI / CD नहीं था। हमारा प्रवाह था:
- डेवलपर होस्ट पर निर्मित।
- एक डेमो के लिए पर्यावरण का परीक्षण करने के लिए तैनात है।
वर्तमान चरण में ज्ञान का प्रावधान कैसे किया गया था, सभी ज्ञात कुंडल डेवलपर्स के दिमाग के अंदर गंदे जादू थे। टीम की वृद्धि के कारण यह हमारे लिए एक वास्तविक मुद्दा था।
बस करो
हमने अपनी परियोजनाओं के लिए TeamCity का उपयोग किया था और gitlab लोकप्रिय नहीं था, इसलिए हमने TeamCity का उपयोग करने का निर्णय लिया। हमने मैन्युअल रूप से एक वीएम बनाया है। हम वीएम के अंदर परीक्षण चला रहे थे।
बिल्ड फ़्लो में कुछ चरण थे:
- मैन्युअल रूप से तैयार वातावरण के अंदर कुछ उपयोगिताओं को स्थापित करें।
- जांचें कि यह काम करता है।
- यदि यह ठीक है, तो RPM प्रकाशित करें।
- नए संस्करण में स्टेजिंग अपडेट करें।
make install && ./libs/run_all_tests.sh make dist make srpm rpmbuild -ba SPECS/xxx-base.spec make publish
हमें एक अस्थायी परिणाम प्राप्त हुआ:
- मास्टर शाखा में कुछ चल रहा था।
- यह कहीं काम किया।
- हम कुछ आकस्मिक मुद्दों का पता लगा सकते हैं।
क्या आपको गंध महसूस होती है?
- आरपीएम के साथ एक आश्रित नरक था।
- सबका अपना पालतू विकास का माहौल था।
- परीक्षण अज्ञात वातावरण के अंदर चल रहे थे।
- तीन पूरी तरह से अनबाउंड इकाइयां थीं: ओएस बिल्ड, इंस्टॉलेशन प्रावधान और परीक्षण।
गंदा जादू कम करें
हमने प्रवाह और प्रक्रिया को बदल दिया:
- हमने RPM मेटा पैकेज बनाया था और निर्भरता नरक को हटा दिया था।
- हमने आवारा के माध्यम से एक विकास वीएम टेम्पलेट बनाया है।
- हम bash स्क्रिप्ट्स को ansible में ले गए।
- एक ओर, हमने एक एकीकरण परीक्षण ढांचा बनाया, लेकिन दूसरी ओर, हमने सर्वरस्पेस का उपयोग किया।
वर्तमान चरण के परिणामस्वरूप हमें प्राप्त हुआ:
- हमारे सभी विकास पर्यावरण समान थे।
- ऐप कोड और प्रावधान तर्क प्रत्येक ओवर के साथ सिंक किए गए थे।
- हमने नए डेवलपर्स ऑनबोर्डिंग प्रक्रिया को गति दी।
एक तरफ, एक निर्माण वास्तव में धीमा था (लगभग 30-60 मिनट), लेकिन दूसरी तरफ यह काफी अच्छा था और मैन्युअल गुणवत्ता आश्वासन से पहले अधिकांश मुद्दों को सफलतापूर्वक पकड़ता था। हालाँकि हमें नई भिन्न समस्याओं का सामना करना पड़ा, यानी फिर हमने कर्नेल को अपडेट किया या फिर हमने एक पैकेज वापस लिया।
इसमें सुधार करें
हमने विभिन्न मुद्दों को हल किया है:
- एकीकरण परीक्षणों ने धीमी और धीमी गति से काम किया क्योंकि देव वीएम टेम्पलेट वास्तविक आरपीएम से पुराना था। हम मैन्युअल रूप से टेम्पलेट का पुनर्निर्माण कर रहे थे, फिर हमने इसे स्वचालित करने का निर्णय लिया:
- स्वचालित रूप से एक VMDK बनाएँ।
- VMDK को VM में संलग्न करें।
- VM को पैक करें और s3 पर अपलोड करें।
- मर्ज की स्थिति में, बिल्ड स्टेटस प्राप्त करना संभव नहीं था, परिणामस्वरूप, हम गिटलैब में चले गए।
- हम हर हफ्ते एक मैनुअल रिलीज करते थे, हमने इसे स्वचालित किया।
- ऑटो वेतन वृद्धि संस्करण।
- बंद मुद्दों के आधार पर रिलीज नोट्स तैयार करें।
- चैंज अपडेट करें।
- मर्ज अनुरोध बनाएँ।
- एक नया मील का पत्थर बनाएँ।
- हमने कुछ चरणों को डॉकटर (एक प्रकार का वृक्ष, कुछ परीक्षण चलाने, संदेश भेजने, डॉक्स बनाने आदि) में स्थानांतरित किया।
वर्तमान चरण योजना के परिणामस्वरूप निम्न प्रकार देखा गया:
- संकुल के लिए बहुत सारे RPM / DEB रिपो थे।
- आर्टिफैक्ट्स वेयरहाउस के रूप में s3 था।
- यदि आप एक ही शाखा के लिए दो बार बिल्ड चलाते हैं, तो आपको एक अलग परिणाम प्राप्त होगा, क्योंकि मेटा पैकेज निर्भरता हार्डकोड नहीं थी।
- बिल्डरों के बीच अविकसित सीमाएं (लाल रंग की रेखाएं) थीं।
हालांकि, हम हर हफ्ते रिलीज का उत्पादन करने और विकास वेग में सुधार करने में सक्षम थे।
निष्कर्ष
परिणाम आदर्श नहीं था, लेकिन एक हजार ली की यात्रा एक कदम के साथ शुरू होती है ©।
पुनश्च यह क्रॉसपोस्ट है