जैसा कि मैंने लिखा है और खरोंच से 1C में DEVOPS और इंजीनियरिंग प्रथाओं में एक डिप्लोमा का बचाव किया

प्रस्तावना

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

उस समय मैंने एक प्रतिष्ठित कंपनी में काम किया और व्यावसायिक मामलों पर मैं एक शांत प्रोग्रामर और आम तौर पर एक अच्छे व्यक्ति आंद्रेई शचीग्लोव (हाय आंद्रेई!) से मिला और किसी तरह = एक बातचीत के दौरान उसने मुझसे पूछा कि क्या मैंने वनस्क्रिप्ट के बारे में कुछ भी सुना है और? घेरकिन स्क्रिप्टिंग भाषा। जिस पर मुझे जवाब मिला कि नहीं, मैंने नहीं सुना। स्वाभाविक रूप से, शाम की google / Yandex और रातों की नींद हराम होने का कारण यह है कि यहाँ है - अज्ञात की दुनिया। लेकिन यह विचार कि यह एक थीसिस का विषय हो सकता है अभी तक उत्पन्न नहीं हुआ है। कर्तव्यों का नियमित सर्कल 1 सी विन्यासकर्ता के कार्य-वार में सामान्य कार्य था, जैसा कि आप मैनुअल परीक्षण के साथ समझते हैं और आपको 1 सी दुनिया में एक नए दृष्टिकोण में पूरी तरह से डूबने की अनुमति नहीं दी।

अपरिचित अवधारणाएँ

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

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

घोंसले के शिकार उदाहरण:

लेआउट में फ़ील्ड का दोहराव:

इसके अलावा, इन क्षेत्रों को भरने के लिए, एक 14-गुना कॉपी-कॉपी।

चक्र की शुरुआत:

और FF वैरिएबल 15 तक पहुंचने तक:

खैर, और कला के अन्य समान रूप से अद्वितीय कार्यों का एक गुच्छा।

अचानक मुझे याद आया कि वनस्क्रिप्ट के लिए मॉड्यूल (1) (मॉड्यूल या विधि की जटिलता) की "साइक्लोमैटिकिटी" की गणना के लिए एक सरल पुस्तकालय है। पाया, हिसाब लगाया। मुझे 163 यूनिट का मान मिला, जिसमें 10 से अधिक का वैध मूल्य नहीं था और मैं इस नतीजे पर पहुंचा कि प्रोग्राम कोड की स्वीकृति परीक्षण अनिवार्य होना चाहिए और यह स्वचालित और निरंतर होना चाहिए। तब मैंने सतत निरीक्षण के बारे में सीखा - और जैसा कि 2006 में वापस आया, आईबीएम ने (2) इस विषय पर एक प्रकाशन किया।

आगे और भी। संभवतः, बड़ी कंपनियों में काम करने वाले कई लोगों को डेवलपर की स्थानीय मशीन पर काम करने वाले आधार की एक प्रति तैनात करने की समस्या का सामना करना पड़ा है। जब इस बेस का वजन 5-10 गीगाबाइट होता है - यह कोई समस्या नहीं है, और जब यह लगभग एक टेराबाइट केवल बैकअप में होता है, तो यह पहले से ही गंभीर है। नतीजतन, एक नई प्रति को तैनात करने में 5-6 घंटे का समय लगा। जब मैं इससे थक गया, तो मैंने 1C-Deploy-and-CopyDB (एंटोन)!

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

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

गिथब प्रोजेक्ट्स:

• https://github.com/silverbulleters/add

• https://github.com/oscript-library/opm

• https://github.com/EvilBeaver/OneScript

• https://github.com/silverbulleters/vanessa-runner/

XDD फोरम:

• 1 स्क्रिप्ट अनुभाग

• परीक्षण अनुभाग

• ऑटोमेशन सेक्शन

अच्छी तरह से और त्वरित संचार के साधन के रूप में - गिटर में प्रोफ़ाइल समूह

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

संक्षेप में:

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

अंतिम योग्यता कार्य (WRC) का उद्देश्य सॉफ्टवेयर उपकरणों के संबंध और 1C क्षेत्र में DevOps सर्किट की व्यावसायिक प्रक्रिया के विवरण की पहचान करना है।

इस परियोजना का सैद्धांतिक औचित्य ITIL 3.0 से सेवा की गुणवत्ता में निरंतर सुधार के लिए मानक था, और व्यावहारिक वस्तु नए अनुप्रयोग समाधान के लिए निरंतर एकीकरण लूप का निर्माण था जिसे हमने विकसित किया - ग्राहक का व्यक्तिगत खाता। ऐसा करने के लिए, GitLab स्रोत सर्वर और जेनकींस बिल्ड लूप तैनात किए गए थे। परीक्षण एक समर्पित सर्वर (विंडोज स्लेव) पर चलाए गए थे। कॉन्फ़िगरेशन को GCync लाइब्रेरी, संस्करण 3.0 का उपयोग करके 1C रिपॉजिटरी से अनलोड किया गया था

(वर्तमान में विकसित शाखा में स्थित है) पहले से ही विकसित शाखा में 30 मिनट की आवृत्ति के साथ एलेक्सी खोरेव (लेक हैलो!) की उपलब्धियों के साथ है। इस विशेष संस्करण को चुनने का कारण tcp प्रोटोकॉल के माध्यम से रिपॉजिटरी से कनेक्ट करने की क्षमता थी, जो दुर्भाग्य से, उस समय ठेठ GitSync 2.x का समर्थन नहीं करता था। यदि गिटलैब में परिवर्तन दर्ज किए गए थे, तो निरंतर एकीकरण लूप का रन स्वचालित रूप से शुरू हो गया था।

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

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

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

सर्किट की व्यावसायिक प्रक्रिया का वर्णन करने के लिए, एक IDEF0 आरेख 4 लगातार ब्लॉकों से मिलकर बना था जो सर्किट के पारित होने का निर्माण करते हैं। किसी भी चरण से गुजरते समय होने वाली एक त्रुटि असेंबली प्रक्रिया को रिलीज़ इंजीनियर के लिए एक अधिसूचना के साथ बाधित करती है और असेंबली प्रक्रिया के 5 वें ब्लॉक में नियंत्रण स्थानांतरित करती है, जहां रिपोर्ट ALLURE, JUNIT प्रारूप और निश्चित रूप से, cucumber.json में उत्पन्न होती है।

IDEF0 मॉडल विवरण

"जीआईटी में स्रोत कोड उतारना" की प्रक्रिया

इनपुट डेटा: - कॉन्फ़िगरेशन रिपॉजिटरी
आउटपुट (आउटपुट): - सोर्स कोड
नियंत्रण: सॉफ्टवेयर, असेंबली स्क्रिप्ट के साथ काम करने के निर्देश
तंत्र: 1C: एंटरप्राइज, Gitsync ।

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

प्रक्रिया के चरण में "जीआईटी में अनलोडिंग स्रोत", फ़ाइल, सेवा सूचना आधार 1 सी बनाया जाएगा; यह सेवा खाते के तहत कॉन्फ़िगरेशन स्टोर से जुड़ा था; सभी परिवर्तन वर्तमान समय में (या रिपॉजिटरी में अंतिम प्रतिबद्ध के लिए) प्राप्त होते हैं; स्रोत कोड असेंबली निर्देशिका में अनलोड किए गए थे; जीआईटी संस्करण भंडारण प्रणाली के लिए प्रतिबद्ध; परिवर्तन GitLab स्रोत सर्वर पर भेजे जाते हैं

"स्रोत कोड की गुणवत्ता का परीक्षण" की प्रक्रिया

इनपुट डेटा: - सोर्स कोड
आउटपुट (आउटपुट): - सोर्स कोड
नियंत्रण: सॉफ्टवेयर, असेंबली स्क्रिप्ट के साथ काम करने के निर्देश
तंत्र: 1 सी: एंटरप्राइज, डिप्लोकका , सोनारक्यूब , साइक्लो.ओस - (दुर्भाग्य से कोई लिंक नहीं है)

इस प्रक्रिया के प्रारंभ में, स्रोत कोड GitLab रिपॉजिटरी में संग्रहीत किया जाता है। नियंत्रण (असेंबली) स्क्रिप्ट का उपयोग करते हुए, इसे असेंबली डायरेक्टरी में प्राप्त किया जाता है। 1 सी के माध्यम से: एंटरप्राइज़ प्लेटफ़ॉर्म, इन स्रोत कोडों के आधार पर, एक सेवा सूचना आधार तैनात किया जाता है। प्लेटफ़ॉर्म टूल का उपयोग करके एक त्रुटि विश्लेषण किया जाता है। यदि विश्लेषण के दौरान प्रोग्राम कोड की त्रुटियों का पता चला है जो कॉन्फ़िगरेशन को इकट्ठा करने की अनुमति नहीं देता है, तो प्रक्रिया बाधित हो जाएगी। इस कदम का लक्ष्य एक निष्क्रिय कॉन्फ़िगरेशन के प्रोग्राम कोड को बर्बाद करने वाले समय को समाप्त करना है।

त्रुटियों की जाँच करने के बाद, प्रोग्राम कोड की चक्रीय जटिलता की गणना शुरू की जाती है। इस गुणांक में वृद्धि डिबगिंग और प्रोग्राम कोड के विश्लेषण को महत्वपूर्ण रूप से प्रभावित करती है। अधिकतम अनुमत मूल्य 10. यदि पार हो गया है, तो एक अपवाद फेंक दिया जाता है और संशोधन के लिए कोड वापस कर दिया जाता है।

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

कार्यात्मक परीक्षण प्रक्रिया

इनपुट डेटा: - सोर्स कोड
आउटपुट (आउटपुट): - सोर्स कोड
नियंत्रण: सॉफ्टवेयर, असेंबली स्क्रिप्ट के साथ काम करने के निर्देश
तंत्र: 1 सी: उद्यम, वैनेसा-व्यवहार, XunitFor1C ।

विकास प्रक्रिया के दौरान, ऐसी स्थितियाँ हो सकती हैं कि नई कार्यक्षमता मौजूदा सबसिस्टम के संचालन को बाधित कर सकती है। यह अपवादों के गठन, और अपेक्षित परिणाम के निष्कर्ष दोनों में प्रकट हो सकता है। इन उद्देश्यों के लिए, सिस्टम के अपेक्षित व्यवहार का परीक्षण किया जाता है।

इस सर्किट के लिए कई विकास और परीक्षण विधियां लागू हैं: TDD (टेस्ट ड्रिवेन डेवलपमेंट) और BDD (बिहेवियर ड्रिवेन डेवलपमेंट)

डब्ल्यूआरसी लिखने के समय, वैनेसा-व्यवहार फ्रेमवर्क का उपयोग बीडीडी पद्धति , और टीडीडी के लिए XunitFor1C का उपयोग करके परीक्षण करने के लिए किया गया था। वे वर्तमान में एक वेनेसा-एडीडी उत्पाद के तहत विलय कर रहे हैं। पुराने उत्पादों के लिए डेवलपर का समर्थन बंद कर दिया गया है। परीक्षण के परिणाम Yandex Allure और Xunit रिपोर्ट फ़ाइलों के लिए आउटपुट हैं।

प्रक्रिया "वितरण की सभा"

इनपुट डेटा: - सोर्स कोड
आउटपुट डेटा: - विन्यास का वितरण
नियंत्रण: सॉफ्टवेयर, असेंबली स्क्रिप्ट के साथ काम करने के निर्देश
तंत्र: 1 सी: एंटरप्राइज, पैकमैन ।

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

परिणाम प्रक्रिया प्रकाशित करें

इनपुट डेटा: - परिणाम अनलोड, रिपोर्ट फ़ाइलें
आउटपुट डेटा: - रिपोर्ट
नियंत्रण: सॉफ्टवेयर, असेंबली स्क्रिप्ट के साथ काम करने के निर्देश
तंत्र: यांडेक्स एल्यूर , ज़ुनिट ।

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

प्रतिक्रिया के लिए, मेलिंग सूची के अलावा, स्लैक कॉर्पोरेट प्रबंधक के साथ एकीकरण का उपयोग किया गया था, जहां बिल्ड की स्थिति के बारे में सभी सूचना संदेश भेजे गए थे, नए संचार की उपस्थिति, बैकअप का गठन, साथ ही साथ DevOps सर्किट से संबंधित सेवाओं के कामकाज की निगरानी और 1C से पूरे।

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

सामान्य निष्कर्ष:

1. आर्थिक प्रभाव केवल लंबी अवधि में संभव है। अनुभव से, यह नोट किया गया था कि जब इंजीनियरिंग प्रथाओं को लागू करने की परियोजना शुरू की जाती है, तो वर्तमान स्तर से 20-30% विकास उत्पादकता में कमी दर्ज की जाती है। यह अवधि अस्थायी है, और एक नियम के रूप में, प्रदर्शन ऑपरेशन के तीन से चार महीनों के बाद अपने प्रारंभिक मूल्यों पर लौटता है। प्रदर्शन में कमी मुख्य रूप से इस तथ्य के कारण है कि डेवलपर को नई विकास आवश्यकताओं के लिए उपयोग करना है: स्क्रिप्ट लिखना, परीक्षण करना और तकनीकी दस्तावेज बनाना।
2. कार्यक्रम कोड के परीक्षण के कारण एक उत्पादक सूचना प्रणाली की स्थिरता में काफी वृद्धि हुई है। महत्वपूर्ण सबसिस्टम का गारंटीकृत संचालन परिदृश्य परीक्षण कवरेज द्वारा प्रदान किया जाता है। इसके कारण, एक महत्वपूर्ण क्षेत्र में कंपनी के जोखिम - ग्राहकों के साथ परिचालन बातचीत कम हो गई थी।
3. एक उत्पादक सूचना आधार पर गतिशील सुधारों के बहिष्करण ने अधिक रचनात्मक रूप से योजना विकास और सॉफ्टवेयर कोड को टेस्ट लूप के आसपास होने से रोकना संभव बना दिया।
4. असेंबली सर्किट के स्वचालन के कारण सूचना आधार की सेवा के लिए कम श्रम लागत।
5. स्लैक के माध्यम से प्रतिक्रिया के उपयोग ने सिस्टम जीवन चक्र की समस्याओं की ऑनलाइन निगरानी और उन्हें ठीक करना संभव बना दिया। टीम की समीक्षाओं के अनुसार, संदेशवाहक का उपयोग करना डाक से अधिक सुविधाजनक है (हालांकि यह भी मौजूद है)।
6. विकास मानकों (सोनारक्यूब) के अनुपालन के लिए स्वचालित निरंतर कोड निरीक्षण (निरंतर निरीक्षण) का उपयोग करना डेवलपर्स को स्वतंत्र रूप से अपनी क्षमता बढ़ाने के लिए मजबूर करता है, और सॉफ़्टवेयर मॉड्यूल के विकास के दौरान सीधे पहचाने गए तकनीकी ऋण को ठीक करना बहुत तेज़ है, क्योंकि आपको कार्य के संदर्भ को पुनर्स्थापित करने में खर्च करने की आवश्यकता नहीं है।
7. ऑटो-प्रलेखन की कार्यक्षमता और वीडियो निर्देशों की पीढ़ी को सक्षम करने से उपयोगकर्ता अनुरोधों की संख्या कम हो सकती है।
8. परियोजना के दौरान, एक व्यावसायिक प्रक्रिया का गठन किया गया था जो 1 सी अनुप्रयोग समाधानों के विकास और परीक्षण के जीवन चक्र का वर्णन करता है, जिसने बदले में इंजीनियरिंग प्रथाओं के कार्यान्वयन के लिए एक परियोजना के गठन को प्रभावित किया । , 1.

, . 90% .

, :

1. , " 1. - , , ( 5 ).
2. “ 1”. . ( , " ". ).
3. CICD 1 , 5.5.0 .

, , 1 , DevOps. , — DevOps 1 .

, DevOps 1. ?