स्वचालन के पूर्वव्यापी और टाइमवेब विकास प्रक्रियाओं में परिवर्तन

1 नवंबर, 2017 को, मैं टाइमवेब सॉफ्टवेयर डेवलपमेंट डिपार्टमेंट में विकास टीम का लीडर बन गया। और 12 नवंबर, 2018 को, विभाग के प्रमुख ने पूछा कि हाब्राहब के लिए लेख कब तैयार होगा, क्योंकि विपणन विभाग ने पूछा, स्वयंसेवक समाप्त हो गए थे, और सामग्री योजना के लिए कुछ और आवश्यक था)

इसलिए, मैं एक पूर्वव्यापी जानकारी देना चाहता हूं कि पिछले एक साल में हमारे उत्पादों के विकास, परीक्षण और वितरण की प्रक्रियाएं कैसे बदल गई हैं। विरासत प्रक्रियाओं और उपकरणों के बारे में, डॉकटर, गिटलैब और हम कैसे विकसित हो रहे हैं।

Timeweb Hoster 2006 से अस्तित्व में है। इस समय, कंपनी ग्राहकों को एक अनूठी और सुविधाजनक सेवा प्रदान करने के लिए बहुत प्रयास करती है जो इसे प्रतिस्पर्धियों से अलग पहचान देगी। Timeweb के अपने मोबाइल एप्लिकेशन, एक वेब-आधारित ईमेल इंटरफ़ेस, वर्चुअल होस्टिंग कंट्रोल पैनल, VDS, एक संबद्ध प्रोग्राम, इसके समर्थन उपकरण और बहुत कुछ है।

हमारे गिटलैब में लगभग 250 परियोजनाएं हैं : ये क्लाइंट एप्लिकेशन, आंतरिक उपकरण, लाइब्रेरी, कॉन्फ़िगरेशन रिपॉजिटरी हैं। उनमें से दर्जनों सक्रिय रूप से विकसित और समर्थित हैं: वे काम करने वाले सप्ताह के दौरान प्रतिबद्ध हैं, परीक्षण करते हैं, इकट्ठा करते हैं, और उन्हें जारी करते हैं।

बड़ी मात्रा में विरासत कोड के अलावा, यह सब उचित संख्या में विरासत में मिली प्रक्रियाओं और संबंधित उपकरणों को अपने साथ लाता है। किसी भी विरासत की तरह, उन्हें भी बनाए रखा जाना चाहिए, अनुकूलित किया जाना चाहिए, refactored, और कभी-कभी प्रतिस्थापित किया जाना चाहिए।

परियोजनाओं के इस सभी बहुतायत में, नियंत्रण कक्ष होस्टिंग ग्राहकों के सबसे करीब हैं। और यह "कंट्रोल पैनल" परियोजना में ठीक है कि हम अक्सर विभिन्न बुनियादी ढांचे में सुधार के माध्यम से चलते हैं और जुड़े हुए बुनियादी ढांचे को आकार में रखने के लिए बहुत प्रयास करते हैं। प्राप्त अनुभव और अन्य उत्पादों और उनकी टीमों को पसंद किए गए अभ्यासों को फैलाना।

पिछले वर्ष में उपकरणों और प्रक्रियाओं में विभिन्न परिवर्तनों के बारे में, मैं बताऊंगा।

वैग्रांत → डोकर-रचना

समस्या

पहले कार्य दिवस पर, मैंने स्थानीय स्तर पर कंट्रोल पैनल जुटाने की कोशिश की। उस समय, एक भंडार में पाँच वेब अनुप्रयोग थे:

- पु वर्चुअल होस्टिंग 3.0,
- पीयू वीडीएस 2.0,
- पु वेबमास्टर्स,
- STAFF (टूल सपोर्ट करता है),
- दिशानिर्देश (मानकीकृत फ्रंट-एंड घटकों का डेमो)।

चलाने के लिए, स्थानीय रूप से वैग्रंट का उपयोग किया जाता है। वैग्रंट ने ansible लॉन्च किया। इसे शुरू करने और कॉन्फ़िगर करने के लिए सहकर्मियों की मदद ली और स्वच्छ समय के एक दिन के बारे में। मुझे वर्चुअल बॉक्स का एक विशेष संस्करण स्थापित करना था (वर्तमान स्थिर एक पर समस्याएं थीं), वर्चुअल मशीन के अंदर कंसोल से काम करना बहुत अनावश्यक था: तुच्छ कमांड जैसे एनपीएम / कंपोजर स्थापित काफी धीमा हो गया।

वर्चुअल मशीन में स्वयं अनुप्रयोगों का प्रदर्शन संभव था, जिससे प्रौद्योगिकी का उपयोग किया गया और मशीन की शक्ति को देखते हुए। यह उल्लेख करने के लिए नहीं कि एक आभासी मशीन एक आभासी मशीन है, और परिभाषा के अनुसार यह आपके पीसी के संसाधनों का एक महत्वपूर्ण हिस्सा लेता है।

निर्णय

स्थानीय विकास पर्यावरण को डॉकटर कंटेनरों में चलाने के लिए फिर से लिखा गया है। अपने जीवन चक्र के सभी चरणों में अनुप्रयोग पर्यावरण को अलग करने के लिए docker पर आधारित कंटेनरीकरण सबसे आम समाधान है। इसलिए, कोई विशेष विकल्प नहीं हैं।

निष्कर्ष

पेशेवरों से:

- स्थानीय रूप से, एप्लिकेशन अधिक प्रतिक्रियाशील हो गया है, कंटेनरों को वीएम से कम की आवश्यकता होती है,
- एक नया उदाहरण लॉन्च करना, जैसा कि अभ्यास से पता चला है, इसमें कुछ मिनट लगते हैं और कुछ संस्करणों की तुलना में केवल docker (-compose) की आवश्यकता होती है। क्लोनिंग के बाद, बस करें:

make install-dev make run-dev 

कुछ समझौते थे:

- मुझे डॉक्यूमेंटेड कमांड (कंपोजर, एनपीएम, आदि) के लिए शेल बाइंडिंग लिखना था। वे, docker-compose.yml की तरह, वैग्रांत की तुलना में पूरी तरह से क्रॉस-प्लेटफ़ॉर्म नहीं हैं। उदाहरण के लिए, मैक के तहत लॉन्च करने के लिए अतिरिक्त प्रयासों की आवश्यकता होती है, और विंडोज के तहत शायद लिनक्स वर्चुअल मशीन में डॉकटर के साथ वितरण को चलाना आसान होगा। लेकिन यह एक स्वीकार्य समझौता है, जैसा कि टीम केवल डेबियन-आधारित वितरण का उपयोग करती है, यह वाणिज्यिक विकास के लिए एक स्वीकार्य सीमा है,
- वर्चुअल मेजबानों का समर्थन करने के लिए, स्थानीय रूप से github.com/jwilder/nginx-proxy पर आधारित एक कंटेनर लॉन्च किया गया है। ऐसा नहीं है कि एक बैसाखी, लेकिन अतिरिक्त सॉफ़्टवेयर, जिसे कभी-कभी याद रखने की आवश्यकता होती है, हालांकि यह समस्याएं पैदा नहीं करता है।

हां, टीम में हर किसी को कम से कम इस बात का एहसास होना चाहिए कि क्या करना है। यद्यपि उल्लिखित शेल स्क्रिप्ट और मेकफाइल के लिए धन्यवाद, डेवलपर्स कंटेनरों के बारे में सोचने के बिना अपने कार्यों का 95% काम करते हैं, लेकिन एक गारंटीकृत समान वातावरण में।

newcp-dev → cp-स्टैंड्स

ये अजीब वाक्यांश क्रमशः नियंत्रण पैनलों, नए और पुराने के परीक्षण स्टैंड के साथ मशीनों के नाम हैं।

समस्या

एंटीग्रेटेड व्यंजनों का उपयोग विशेष रूप से वैग्रांट के अंदर किया गया था, इसलिए मुख्य लाभ हासिल नहीं किया गया था: डेवलपर्स में काम करने वाले उत्पादों पर और ठिकानों में पैकेज के संस्करण अलग थे।

डेवलपर्स के पास पुराने सॉफ्टवेयर सर्वर पैकेज के संस्करणों का बेमेल हिस्सा खड़ा था, जिससे समस्याएं पैदा हुईं। सिंक्रनाइज़ेशन इस तथ्य से जटिल था कि सिस्टम प्रशासक एक अलग कॉन्फ़िगरेशन प्रबंधन प्रणाली का उपयोग करते हैं, और डेवलपर्स रिपॉजिटरी के साथ इसे एकीकृत करना संभव नहीं है।

निर्णय

कंटेनरीकरण के बाद, परीक्षण बेंचों पर उपयोग के लिए डॉकटर-कंपोज़ कॉन्फ़िगरेशन को विस्तारित करना मुश्किल नहीं था। DOCKER_HOST पर स्टैंड तैनात करने के लिए एक नई मशीन बनाई गई थी।

निष्कर्ष

डेवलपर्स अब स्थानीय और परीक्षण वातावरण की प्रासंगिकता में विश्वास करते हैं।

टीमसिटी → गिटलैब-सीआई

समस्याओं

TeamCity में प्रोजेक्ट कॉन्फ़िगरेशन एक श्रमसाध्य और कृतघ्न प्रक्रिया है। CI कॉन्फ़िगरेशन को कोड से अलग करके xml में संग्रहीत किया गया था, जिसमें सामान्य संस्करण लागू नहीं है, और परिवर्तनों का अवलोकन। हमने टीमसिटी एजेंटों पर निर्माण प्रक्रिया की स्थिरता के साथ समस्याओं का भी अनुभव किया।

निर्णय

चूंकि गिटलैब पहले से ही रिपॉजिटरी के लिए भंडार के रूप में उपयोग किया जाता था, इसलिए इसका सीआई उपयोग करना शुरू करना न केवल तर्कसंगत था, बल्कि आसान और सुखद भी था। अब रिपॉजिटरी में संपूर्ण CI / CD कॉन्फ़िगरेशन सही है।

परिणाम

वर्ष के दौरान, टीमसिटी द्वारा इकट्ठे किए गए लगभग सभी प्रोजेक्ट सुरक्षित रूप से गिटलैब-सीआई में चले गए। हमें सीआई / सीडी प्रक्रियाओं को स्वचालित करने के लिए कई प्रकार की सुविधाओं को जल्दी से लागू करने का अवसर मिला।
पाइपलाइनों का स्क्रीनशॉट सबसे स्पष्ट होगा:


अंजीर। 1. सुविधा-शाखा: सभी उपलब्ध स्वचालित जांच और परीक्षण शामिल हैं। जब पूरा हो जाता है, तो पाइपलाइन के लिंक के साथ एक टिप्पणी को रेडमाइन कार्य के लिए भेजता है। इस शाखा के साथ एक स्टैंड को इकट्ठा करने और लॉन्च करने के लिए मैनुअल कार्य।


अंजीर। 2. कोड फ्रीज के साथ अनुसूचित बिल्ड विकसित करना (चेकआउट: आरसी): कोड फ्रीज के साथ शेड्यूल पर निर्माण विकसित करें। व्यक्तिगत नियंत्रण पैनलों के स्टैंड के लिए छवियों की विधानसभा समानांतर में होती है।


अंजीर। 3. टैग पाइपलाइन: नियंत्रण पैनलों में से एक की रिहाई। रोलबैक रिलीज के लिए मैनुअल कार्य।

इसके अलावा, gitlab-ci से स्टेटस → रिव्यू → QA, स्टेज में नोटिफिकेशन और अपडेट्स और स्टेजिंग और रोलबैक के बारे में नोटिफिकेशन → रिव्यू → QA के चरणों में स्थिति में बदलाव और एक व्यक्ति की नियुक्ति है।

यह सुविधाजनक है, लेकिन हमने एक कार्यप्रणाली पर ध्यान नहीं दिया। एक परियोजना में इस तरह के स्वचालन को लागू करने के बाद, लोगों को जल्दी से इसकी आदत हो जाती है। और किसी अन्य परियोजना पर स्विच करने के मामले में जहां यह अभी तक मौजूद नहीं है, या प्रक्रिया अलग है, आप कार्य को फिर से शुरू करने और फिर से असाइन करने के लिए भूल सकते हैं या मर्ज अनुरोध के लिंक के साथ एक टिप्पणी छोड़ सकते हैं (जिसे गिटलैब-सी भी करता है), जिससे दर्शक वांछित को खोज सके। स्वयं एम.आर. उसी समय, आप केवल .itlab-ci.yml टुकड़ों और परियोजनाओं के बीच शेल कोड को कॉपी नहीं करना चाहते हैं, क्योंकि आपको कॉपी-पेस्ट का समर्थन करना है।

निष्कर्ष: स्वचालन अच्छा है, लेकिन जब यह सभी टीमों और परियोजनाओं के स्तर पर समान है - और भी बेहतर। मैं इस तरह के विन्यास के पुन: उपयोग को सुंदर ढंग से व्यवस्थित करने के विचारों के लिए प्रतिष्ठित जनता का आभारी रहूंगा।

पाइपलाइन की अवधि: 80 मिनट → 8 मिनट

धीरे-धीरे, हमारे सीआई ने अनिश्चित काल के लिए शुरू किया। परीक्षकों को इससे बहुत परेशानी हुई: मास्टर में प्रत्येक फिक्स को एक रिलीज के लिए एक घंटे इंतजार करना पड़ा। ऐसा लग रहा था:


अंजीर। 4. पाइप लाइन 80 lvl न्यूनतम अवधि।

मुझे कई दिनों तक धीमे स्थानों के विश्लेषण में गोता लगाना पड़ा और कार्यक्षमता को बनाए रखते हुए तेजी लाने के तरीके खोजने पड़े।

प्रक्रिया में सबसे लंबे समय तक स्थान npm संकुल स्थापित कर रहे थे। बिना किसी समस्या के, उन्होंने इसे यार्न से बदल दिया और 7 मिनट तक कई स्थानों पर बचाया।

उन्होंने इस मंच की स्थिति के स्वत: मंचन अपडेट, पसंदीदा मैनुअल नियंत्रण से इनकार कर दिया।

हमने कई धावकों को भी जोड़ा और समानांतर कार्यों में विभाजित किया गया जो कि एप्लीकेशन इमेज और सभी चेकों की असेंबली है। इन अनुकूलन के बाद, सभी स्टैंडों के अद्यतन के साथ मुख्य शाखा की पाइपलाइन ज्यादातर मामलों में 7-8 मिनट के लिए शुरू हुई।

कैपिस्ट्रानो → तैनातीकर्ता

उत्पादन में और क्यूए-स्टैंड पर तैनाती के लिए, कैपिस्ट्रानो का उपयोग किया गया था (और लेखन के समय इसका उपयोग किया जाता है)। इस टूल का मुख्य परिदृश्य है: रिपॉजिटरी को टारगेट सर्वर पर क्लोन करना और वहां सभी कार्य करना।

इससे पहले, तैनाती को QA इंजीनियर के हाथों से शुरू किया गया था, जिसमें वैग्रांट से आवश्यक ssh कीज़ थीं। फिर, जैसा कि वैग्रैंट ने त्याग दिया, कैपिस्ट्रानो एक अलग कंटेनर में चले गए। अब कंटेनर को कैपिस्ट्रानो के साथ गिटलैब-रनर्स के साथ विशेष टैग के साथ चिह्नित किया गया है और आवश्यक टैग होने पर स्वचालित रूप से आवश्यक कुंजी होने पर बनाया गया है।

यहाँ समस्या यह है कि पूरी निर्माण प्रक्रिया:

a) कॉम्बैट सर्वर (विशेषकर नोड / gulp) के संसाधनों का महत्वपूर्ण रूप से उपभोग करता है,
बी) संगीतकार, एनपीएम संस्करणों को अद्यतित रखने का कोई तरीका नहीं है। नोड, आदि।

बिल्ड सर्वर (हमारे मामले में यह gitlab-runner) पर बनाने के लिए और तार्किक है, और तैयार कलाकृतियों को लक्ष्य सर्वर पर अपलोड करना अधिक तर्कसंगत है। यह लड़ाई सर्वर को विधानसभा उपयोगिताओं और विदेशी जिम्मेदारी से बचाएगा।

अब हम तैनातीकर्ता को कैपिस्ट्रानो के प्रतिस्थापन के रूप में मानते हैं (क्योंकि हमारे पास कोई रूबिस्ट नहीं है, और न ही हमें इसके डीएसएल के साथ काम करने की इच्छा है) और असेंबली को गिटलैब में स्थानांतरित करने की योजना है। कुछ गैर-महत्वपूर्ण परियोजनाओं में, हम पहले से ही इसे आज़माने में कामयाब रहे और अब तक संतुष्ट हैं: यह आसान लग रहा है, हमने किसी प्रतिबंध का सामना नहीं किया है।

Gitflow: आरसी-शाखाएँ → टैग

विकास साप्ताहिक चक्रों में किया जाता है। पांच दिनों के दौरान, एक नया संस्करण विकसित किया जा रहा है: विकास अगले सप्ताह रिलीज के लिए नियोजित सुधारों और सुधारों को स्वीकार करता है। शुक्रवार की रात, कोड फ्रीज स्वचालित रूप से होता है। सोमवार को, नए संस्करण का परीक्षण शुरू होता है, सुधार किए जाते हैं, और कार्य सप्ताह के मध्य-अंत तक, एक रिलीज होती है।

इससे पहले, हमने rc18-47 फॉर्म के नामों के साथ शाखाओं का उपयोग किया था, जिसका अर्थ है कि रिलीज उम्मीदवार 2018 का 47 वां सप्ताह है। कोड फ्रीज आरसी शाखा को विकसित करने के लिए जांचना था। लेकिन इस साल अक्टूबर में, हमने टैग पर स्विच किया। टैग पहले सेट किए गए थे, लेकिन तथ्य के बाद, मास्टर के साथ आरसी की रिहाई और विलय के बाद। अब टैग की उपस्थिति एक स्वचालित तैनाती की ओर ले जाती है, और फ्रीजिंग मास्टर में विकसित होने का एक मर्ज है।

इसलिए हमने प्रक्रिया में git और चर में अतिरिक्त संस्थाओं से छुटकारा पा लिया।
अब हम "पुलिंग" परियोजनाओं को इसी तरह के वर्कफ़्लो की प्रक्रिया में पिछड़ रहे हैं।

निष्कर्ष

प्रक्रियाओं का स्वचालन, उनका अनुकूलन, साथ ही साथ विकास, एक निरंतर मामला है: जब तक उत्पाद सक्रिय रूप से विकसित हो रहा है और टीम काम कर रही है, तब तक इसी कार्य होंगे। नए विचारों से पता चलता है कि कैसे नियमित कार्यों से छुटकारा पाने के लिए: सुविधाओं को गिटलैब-सीआई में लागू किया जाता है।

जैसे-जैसे एप्लिकेशन बढ़ते हैं, सीआई प्रक्रियाएं अस्वीकार्य रूप से लंबा समय लेने लगती हैं - यह उनके प्रदर्शन पर काम करने का समय है। चूंकि दृष्टिकोण और उपकरण अप्रचलित हो रहे हैं - आपको रिफ्लेक्टर के लिए समय निकालने, उनकी समीक्षा करने और अपडेट करने की आवश्यकता है।