हमारी टीम एक बड़े कॉर्पोरेट उत्पाद के संचालन और विकास के लिए जिम्मेदार है।
2017 की शुरुआत में, एक प्रमुख कार्यान्वयन से विराम लेते हुए और "सबक सीखा" का पुन: निर्धारण करते हुए, हमने दृढ़ता से अपने आवेदन के विकास और वितरण की समीक्षा करने का निर्णय लिया। हम वितरण की कम गति और गुणवत्ता के बारे में चिंतित थे, हमें उस सेवा का स्तर प्रदान करने की अनुमति नहीं देते थे जो ग्राहक हमसे उम्मीद करते हैं।

यह शब्दों से कर्मों की ओर बढ़ने का समय था - प्रक्रियाओं को बदलने के लिए।

यह आलेख संक्षेप में बात करेगा कि हमने कहां से शुरू किया, हमने क्या किया, अब क्या स्थिति है, हमें किन कठिनाइयों का सामना करना पड़ा है, हमें क्या पीछे छोड़ना है, हम और क्या करने की योजना बनाते हैं।

शुरुआत

थोड़ी प्रणाली के बारे में

आवेदन "2000 के दशक के वास्तुशिल्प" के एक अखंड उद्यम अनुप्रयोग का एक उत्कृष्ट उदाहरण है:

• 15 वर्षों में संचालित और विकसित।
• यह डेढ़ दर्जन WinForms, विंडोज़ सेवाओं और ASP .Net अनुप्रयोगों का एक सेट है जो एकल MS SQL डेटाबेस से जुड़ा हुआ है।
• कोडबेस आकार: ~ 1MLOC C #, ~ 9000 डेटाबेस ऑब्जेक्ट के लिए। अधिकांश व्यापार तर्क डेटाबेस की ओर से चलता है।
• आवेदन में एक जीत / वेब क्लाइंट (संबंधित प्रपत्रों के समूह का एक समाधान) बनाने के लिए ~ 250 + समाधान शामिल हैं। यह पिछली विकास प्रक्रिया और क्लाइंट आर्किटेक्चर की विरासत है।
• एप्लिकेशन आंतरिक कॉन्फ़िगरेशन को बदलकर कई प्रकार की प्रक्रियाओं (क्लाइंट) का समर्थन करता है: सिस्टम डेटाबेस कॉन्फ़िगरेशन तालिकाओं में प्रक्रियाओं, अनुमतियों, लचीले फ़ील्ड्स आदि को सेट करना। इसी समय, एप्लिकेशन कोड आधार सभी क्लाइंट के लिए समान है।
• आवेदन 25+ साइटों पर तैनात और समर्थित है (प्रत्येक साइट सिस्टम का एक स्वतंत्र उदाहरण है) और विभिन्न समय क्षेत्रों में कुल कई हजार अंत उपयोगकर्ताओं की सेवा करता है।

परिवर्तन से पहले वितरण प्रक्रिया

1. तैयार आवेदन और उसके घटकों का विकास और संयोजन ठेकेदार द्वारा किया जाता है।
2. कोड ठेकेदार (एमएस टीएफएस के स्थानीय संस्करण) के पक्ष में संग्रहीत किया गया था। कोड मुख्य भंडार शाखा के वर्तमान संस्करण के संग्रह के रूप में मासिक आधार पर ग्राहक को प्रेषित किया जाता है।
3. वितरण "डेल्टा अपडेट" के वितरण द्वारा किया गया था: आवेदन के लिए (डीएलएल, एक्सई, आदि) और डेटाबेस घटकों (एसक्यूएल स्क्रिप्ट का सेट / परिवर्तन)। एप्लिकेशन बनाया गया था और ठेकेदार द्वारा तैयार किए गए डेल्टा पैकेज।
4. परिनियोजन प्रक्रिया को परिवहन प्रणाली द्वारा समर्थित किया गया था, परिवर्तन स्वचालित रूप से लागू किए गए थे।

मासिक रिलीज के हिस्से के रूप में वितरण किया जाता है (जैसा कि मैंने इसे व्यवस्थित किया है, मैंने आपको पहले यहां बताया था)।

मौजूदा समस्याएं

नियंत्रण की कमी

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

श्रम इनपुट और त्रुटियों

• "डेल्टा पैकेज" तैयार करना विकास के लिए समय लेने वाली प्रक्रिया है, त्रुटियों का स्रोत और कुछ परियोजना लागत।
• डेल्टा पैकेट एप्लिकेशन को तैनात करने के लिए पैकेजों के क्रम पर नज़र रखने की आवश्यकता होती है। एक पैकेट आउट-ऑफ-ऑर्डर त्रुटि एक प्रमुख परिनियोजन समस्या और घटनाओं का एक महत्वपूर्ण स्रोत है।
• नियमित रूप से प्रतिगमन होता है: जो त्रुटियां मरम्मत की जाती हैं और उत्पाद के सुधारों को फिर से प्रकट किया जाता है।

प्रतिबंध

• अतीत में एक समय में सिस्टम की स्थिति को पुनर्स्थापित करने की क्षमता (रोल बैक परिवर्तन) लगभग अनुपस्थित है।
• ग्राहक कर्मचारियों को आकर्षित करके प्रभावी रूप से विकास और प्रारंभिक परीक्षण संसाधनों को मापने की क्षमता व्यावहारिक रूप से अनुपस्थित है।

अपेक्षित परिणाम

परियोजना की शुरुआत में, हम ऊपर बताई गई समस्याओं को हल करने के लिए हमारे लिए स्पष्ट लक्ष्य निर्धारित करते हैं।

• ग्राहक नियंत्रण के लिए कोड भंडार स्थानांतरण
• एप्लिकेशन बिल्ड प्रक्रिया को ग्राहक पक्ष में ले जाएं
• पूर्ण अद्यतन के पक्ष में "परिवर्तनों के डेल्टा" को छोड़कर, परिवर्तनों के वितरण की प्रक्रिया को संशोधित करें

इसके अतिरिक्त, पहले दो लक्ष्यों को प्राप्त करने पर प्राप्त समाधानों का उपयोग करते हुए, हमने गणना की:

• कोड नियंत्रण के माध्यम से परिणामी समाधानों की तकनीकी गुणवत्ता में सुधार
• स्व-सेवा परिनियोजन प्रदान करके परीक्षण की व्यस्तता और उपयोगिता को बढ़ाएँ।

एक लंबा रास्ता तय करना

विकास प्रक्रियाओं की वर्तमान स्थिति का विश्लेषण

पहला कदम: मौजूदा ठेकेदार विकास प्रक्रिया का विश्लेषण करें। इससे परिवर्तनों की योजना बनाने में मदद मिली, ताकि यदि संभव हो, तो काम बाधित न हो।

दुर्भाग्य से, विकास प्रक्रिया से परिचित होने से पता चला कि वर्तमान में आईटी उद्योग की समझ में यह प्रक्रिया अनुपस्थित थी।

1. इसके लिए डेटाबेस कोड और व्यावसायिक तर्क आज तक भंडार में नहीं रखे गए थे। मुख्य कारण: उपकरणों की कमी जो विधानसभा से कोड में भंडार और परिणाम की तैनाती को लागू करते हैं। तो, रिपॉजिटरी में कोड सिर्फ प्रलेखन है।
2. डेटाबेस कोड का "वास्तविक" संस्करण आम "विकास डेटाबेस" में है, जिस पर दर्जनों डेवलपर्स काम करते हैं।
3. क्लाइंट एप्लिकेशन कोड (C #, ASP.NET) रिपॉजिटरी में बनाए रखा गया था, लेकिन कमिट की गुणवत्ता और समयबद्धता की गारंटी नहीं थी।
4. घटकों के संयोजन (पूरे आवेदन नहीं) डेवलपर के स्टेशनों पर किया गया था। यह पूरी तरह से स्पष्ट नहीं है कि विधानसभा से पहले कोड को कैसे अपडेट किया गया था। इकट्ठे घटक को एक साझा साझा फ़ोल्डर पर रखा गया था। वहां से, ग्राहक के लिए एक "डेल्टा पैकेज" का गठन किया गया था।
5. विकास शाखाओं को बनाए रखने के अभ्यास का पूर्ण अभाव। अप्रत्यक्ष संकेतों से, हमें लंबे समय तक इस पर संदेह था - लेकिन प्रक्रिया में गोता लगाने के बाद, सब कुछ स्पष्ट हो गया।

एक नए रिपॉजिटरी और संस्करण नियंत्रण प्रणाली पर स्विच करना

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

VSTS के संस्करण और कार्यक्षमता के पीछे कॉर्पोरेट ऑन-प्रिमाइसेस TFS पिछड़ गया, नए संस्करण में प्रवास केवल चर्चा की प्रक्रिया में था। हम इंतजार नहीं करना चाहते थे। हमने तुरंत वीएसटीएस पर स्विच करने का फैसला किया, क्योंकि इससे प्लेटफॉर्म को सपोर्ट करने के लिए हमारी ओवरहेड लागत कम हो गई और हमें इस बात पर पूरा नियंत्रण मिला कि हम कैसे और क्या करते हैं।

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

हमने अलग-अलग रिपॉजिटरी - टीएफएसवीसी और जीआईटी के साथ वीएसटीएस में दो परियोजनाओं को तैनात किया। परिदृश्यों का एक सेट परिभाषित किया गया था, जिसे प्रत्येक प्रणाली में प्रयोज्य का परीक्षण और मूल्यांकन करने का प्रस्ताव दिया गया था।

मूल्यांकन किए गए परिदृश्यों में से थे:

• शाखाएँ बनाएँ और विलय करें
• संयुक्त कार्य का संगठन (एक या विभिन्न शाखाओं पर)
• श्रृंखला संचालन बदलें (प्रतिबद्ध, पूर्ववत करें)
• तृतीय-पक्ष एकीकरण
• सर्वर के अनुपलब्ध होने पर कार्य जारी रखने की क्षमता।

परिणामस्वरूप, जैसा कि अपेक्षित था, जीआईटी को चुना गया था, और अब तक किसी को भी इसका पछतावा नहीं है।

एक प्रक्रिया के रूप में, हमने GitFlow का उपयोग करना शुरू कर दिया। इस प्रक्रिया ने परिवर्तनों पर पर्याप्त नियंत्रण प्रदान किया और रिलीज के वितरण की अनुमति दी, जैसा कि हम उपयोग करते हैं।

1. हमने एक ऐसी नीति के साथ विकसित शाखा का बचाव किया जिसमें मांग थी कि सभी परिवर्तन पुल अनुरोधों के माध्यम से होते हैं।
2. हम "एक टिकट - एक पुल अपेक्षित" के अभ्यास का पालन करने की कोशिश करते हैं। विभिन्न टिकटों के परिवर्तन को एक परिवर्तन में कभी संयोजित नहीं किया जाता है। हम बाद में पुल की आवश्यकता में सुधार के साथ स्थिति से बचने के लिए सुविधा शाखा पर परीक्षण करने की पूरी कोशिश करते हैं।
3. जब विकास में विलय हो जाता है, तो सभी परिवर्तन एक ही प्रतिबद्ध (स्क्वैश) में विलय हो जाते हैं।
4. रिलीज शाखाएं विकास से निर्मित होती हैं।
5. यदि आवश्यक हो, तो रिलीज शाखा में, आप नवीनतम परिवर्तन चुनिंदा (चेरी-पिक) या सभी (रिबेस) जोड़ सकते हैं। हम रिलीज़ शाखा में सीधे सुधार नहीं करते हैं।
6. उत्पाद पर नवीनतम रिलीज को तैनात करने के बाद, यह पुश बल के माध्यम से मास्टर करने के लिए जाता है (केवल कुछ लोगों को यह अधिकार है)

उत्पाद विधानसभा का स्वचालन

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

एक अलग कहानी एक डेटाबेस डिजाइन है। दुर्भाग्य से, सिस्टम में कई सीएलआर घटक शामिल हैं जो अच्छी तरह से संरचित नहीं थे। निर्भरता सामग्री के साथ एक सरल तैनाती आधार की अनुमति नहीं देती है। फिलहाल, यह एक पूर्व-तैनाती स्क्रिप्ट द्वारा हल किया जा रहा है।
इसके अलावा, असमान प्रणाली परिदृश्य (SQL सर्वर संस्करण 2008 और 2014 को अलग-अलग बिंदुओं पर स्थापित किया गया था) के कारण, .net संस्करणों 2.0 और 4.0 के लिए आधार परियोजना की विधानसभा को व्यवस्थित करना आवश्यक था।

सभी लिपियों के तैयार होने और परीक्षण के बाद, उनका उपयोग बिल्ड स्क्रिप्ट VSTS में किया गया था।

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

टेस्ट बेंच में तैनाती

निर्माण प्रक्रिया का प्रारंभिक संस्करण पूरा होने के बाद, हम तैनाती स्क्रिप्ट की तैयारी के साथ आगे बढ़े।

यह उम्मीद की जाती है कि डेटाबेस सबसे अधिक परेशानी वाला था।

एक वास्तविक डेटाबेस की "टॉप" कॉपी तैनात करने से विधानसभा और वास्तविक प्रणालियों की स्थिति के बीच कई संघर्ष सामने आए:

• जीआईटी और वास्तविक प्रणाली में असंगत संस्करण
• डेटाबेस स्कीमा उन उपयोगकर्ताओं के स्वामित्व में है जिन्हें हटाने की योजना बनाई गई थी।

विकास प्रक्रिया का स्थिरीकरण

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

सबसे कठिन बात डेटाबेस कोड के साथ थी। डेटाबेस को रिपॉजिटरी से परिनियोजित करने के लिए स्विच करने के बाद, एसक्लॉकपेज का उपयोग करके असेंबली और तैनाती के माध्यम से, "डेल्टा" दृष्टिकोण को "वांछित राज्य" दृष्टिकोण से बदल दिया गया था। पैकेज अतीत की बात थी, सब कुछ स्वचालित रूप से तैनात किया जाना था।

लेकिन! नई तैनाती प्रक्रिया में पूर्ण परिवर्तन होने तक, परिवर्तन अभी भी वितरित किए जाने की आवश्यकता है। और इसे पुराने ढंग से करना जरूरी था - "डेल्टा अपडेट"।

डेल्टा पैकेट और रिपॉजिटरी की सामग्री वितरित करते समय हमने सिस्टम की स्थिति के पूर्ण और निरंतर स्थिरता सुनिश्चित करने के कार्य का सामना किया।

ऐसा करने के लिए, हमने निम्नलिखित प्रक्रिया का आयोजन किया:

1. नियमित रूप से, भंडार से कोड एकत्र किया गया था और एक खाली "मॉडल" डेटाबेस में तैनात किया गया था।
2. "मॉडल" आधार के आधार पर, एक विशेष ऑटोटेस्ट तैयार किया जा रहा था। "मॉडल" डेटाबेस के प्रत्येक ऑब्जेक्ट के लिए, चेकसम की गणना की गई थी। ऑटोटेस्ट में ये सभी चेकसम होते हैं और स्टार्टअप पर यह "चेक किए गए" डेटाबेस की संबंधित वस्तुओं के चेकसम की गणना करता है। वस्तुओं या उनके चेकसम की संरचना में कोई विसंगति परीक्षण में गिरावट की ओर ले जाती है।
3. "गिरता" परीक्षण स्वचालित रूप से परिदृश्य के नीचे परीक्षण पर्यावरण से संकुल के हस्तांतरण को मना करता है। इस तरह के एकीकरण को पिछली परिवहन प्रणाली में पहले ही लागू किया जा चुका है।

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

एकीकरण परीक्षण वातावरण पर उत्पाद की तैनाती

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

उस क्षण से, पूरी टीम को पहले खर्च किए गए प्रयासों का पहला फल प्राप्त करना शुरू हुआ: तैनाती बिना किसी अतिरिक्त प्रयास के हुई। कस्टम कोड स्वचालित रूप से एकत्र, तैनात और परीक्षण किया गया था।

दुर्भाग्य से, जैसा कि हमने बाद में समझा, "रिपॉजिटरी का संरेखण" इस तथ्य का कारण बना कि हमारे पास "विकसित" के स्थिर रूप से समर्थित संस्करण का एक संस्करण था, लेकिन "उत्पादन" का संस्करण अभी भी अनुपलब्ध था। और इसलिए, QAS और PRD के साथ परीक्षण के माहौल से परे जाने के लिए कुछ भी नहीं था।

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

स्वचालित असेंबली के परिणामस्वरूप उत्पाद का परीक्षण करना

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

लेकिन सी # के लिए कोई परीक्षण नहीं थे - इसलिए, सब कुछ हाथ से चेक किया गया था। यह एक महत्वपूर्ण कार्य था, और सत्यापन में कुछ समय लगा।

विश्वास की छलांग - पायलट उत्पादक तैनाती

परीक्षण के बावजूद, पहली बार किसी उत्पाद पर तैनात करना डरावना था।

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

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

आधिकारिक लॉन्च और पोस्ट-लॉन्च समर्थन के एक सप्ताह के बाद, हमने घोषणा की कि यह "एक नए तरीके से इकट्ठा और वितरित की गई पहली कॉपी है।"

असेंबली का यह संस्करण मास्टर शाखा का पहला स्थिर संस्करण बन गया, इसे fisrt_dep तैनाती टैग्स के साथ लटका दिया गया था (हम कमिट के हैश के साथ आदेश आइकन नहीं करते थे)।

पूरे उत्पादक परिदृश्य में स्केल परिनियोजन

जैसा कि जेम्स बॉन्ड ने कहा: "दूसरी बार बहुत सरल है।" पायलट की तैनाती की सफलता के बाद, हमने जल्दी से एक समान प्रकार के सिस्टम के शेष उदाहरणों को जोड़ा।

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

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

स्केलिंग से ही अप्रत्याशित तकनीकी समस्याएं सामने आईं:

अमानवीय प्रणाली परिदृश्य
एप्लिकेशन को सीधे परिनियोजित करने के अलावा, हमें पहले यह ध्यान रखना था कि हर जगह सब कुछ समान था - .net संस्करण, पॉवर्सशेल और मॉड्यूल। यह सब उचित समय लगा।

नेटवर्क कनेक्शन
कुछ साइटों पर, नेटवर्क कनेक्शन ने विधानसभा के सभी घटकों को पंप करने की अनुमति नहीं दी। स्थानांतरण के दौरान समय-समय पर क्षति हुई। हमने बहुत सी चीजों की जाँच की और कोशिश की - बहुत सफलतापूर्वक नहीं।

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

एंटीवायरस के साथ संघर्ष
हमारे सामने आई एक और विचित्र समस्या एंटीवायरस सॉफ़्टवेयर और एक परिनियोजन चरणों के बीच का टकराव है: जब सभी प्रकार के "संदिग्ध", जैसे .js, .dll, को कलाकृतियों के अभिलेखागार से निकाला जाता है, तो एंटीवायरस उन्हें करीब से देखना शुरू कर देता है। और सबसे अजीब बात यह है कि एंटीवायरस अनपैकिंग के अंत से पहले फ़ाइल में भागना शुरू कर देता है और अनपैकिंग प्रक्रिया "फ़ाइल किसी अन्य प्रक्रिया द्वारा व्यस्त है" संदेश के साथ गिरती है। जबकि हम इससे जूझ रहे हैं, स्कैन से कलाकृतियों के साथ स्थानीय फ़ोल्डर को छोड़कर, यह बहुत अच्छा नहीं है, लेकिन हमने कुछ और नहीं किया है।

प्रक्रिया में सुधार

, " " — .

• (service-now.com) VSTS Work Items. develop — .
• CI feature . —
• "self-service"
• — . , .
• : , CI/CD ,
• ( )
• - ( ) . — , .
• VSTS , , .

परिणाम

• MS VisualStudio Team Services ( — Azure Devops) . — GIT
• (/)
• git / GitFlow .
• code review .
• CI. , feature , .
• . , .
• ( ) — . - .
• - 1 . - .
• "" .

— 14

, , , .

, — 250 * .