निरंतर एकता। सिस्टम में विश्वसनीयता और विश्वास सुनिश्चित करने का तरीका

बहुत पहले नहीं, मुझे केंट बैक, रॉबर्ट मार्टिन, मार्टिन फाउलर, पॉल ओवल जैसे प्रोग्रामिंग विचारकों के काम में दिलचस्पी थी।



उनकी पुस्तकों ने मुझे प्रभावित किया और मुझे वर्णित कुछ प्रथाओं की कोशिश करने के लिए प्रेरित किया। Refactoring, TDD, XP, और अंत में सतत एकीकरण, वह है जो मुझे सॉफ़्टवेयर विकास प्रक्रिया में हाल ही में दिलचस्पी है।



किताबों से मैंने जो सीखा है, मैं उसके साथ साझा करना चाहता हूं और मुझे वास्तविकता से निपटना है।

सिद्धांत

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



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



वास्तव में, सीआई आपको सॉफ्टवेयर विकास प्रक्रिया के दौरान मान्यताओं से छुटकारा पाने की अनुमति देता है। प्रबंधक मानता है कि उत्पाद तैयार है और स्थिर है, प्रोग्रामर - कि कोड में कोई त्रुटि नहीं है, आदि प्रश्नों से छुटकारा पाएं जैसे: "अंतिम बिल्ड स्थिर है, क्या विशेषताएं तैयार हैं, क्या कोड कंपनी के मानकों का अनुपालन करता है", आदि।



मैं बिल्ली के नीचे सीआई विषय में रुचि रखने वाले सभी से पूछता हूं।



Ideologically, CI निम्नलिखित सम्मेलनों पर आधारित है:

• अक्सर (प्रति दिन कम से कम 1 बार) रिपॉजिटरी में अपना कोड "अपलोड" करें
• स्वचालित परीक्षण लिखें
• निजी बिल्ड चलाएं (निर्माण प्रक्रिया जो वर्तमान में स्थानीय डेवलपर भंडार में स्थित स्रोत कोड का उपयोग करके चलती है)
• निष्क्रिय कोड "भरें" नहीं
• मरम्मत टूट निर्माण तुरंत
• सुनिश्चित करें कि सभी परीक्षण और जांच पास हैं
• रिपॉजिटरी से टूटे हुए कोड को पंप न करें

स्क्रिप्ट का निर्माण

एक बिल्ड स्क्रिप्ट कमांड का एक सेट है जिसे एकीकरण प्रक्रिया शुरू होने पर निष्पादित किया जाएगा। अक्सर, यह निम्नलिखित चरणों के सेट की तरह दिखता है:

• पिछले रन परिणाम को साफ़ करना
• संकलन (या व्याख्या की गई भाषाओं के लिए स्थिर कोड विश्लेषण)
• डेटाबेस एकीकरण
• स्वचालित परीक्षण चलाएं
• अन्य चेक चलाना (मानकों का अनुपालन, साइक्लोमैटिक जटिलता आदि की जाँच करना)
• सॉफ्टवेयर तैनाती

स्वचालित परीक्षण

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



सीआई अनुसंधान को छोड़कर सभी स्तरों पर परीक्षणों का उपयोग करता है। चूंकि विभिन्न संसाधनों पर परीक्षण स्तरों की सूची अलग है, मैं सीआई के विचारकों द्वारा वर्णित उन लोगों को दूंगा:

• इकाई परीक्षण
• घटक परीक्षण
• कार्यात्मक परीक्षण
• सिस्टम परीक्षण

लेखन और परीक्षण चलाने पर कई समझौतों को भी अपनाया गया है:

• तेजी से परीक्षण पहले चलाया जाना चाहिए
• परीक्षणों को वर्गीकृत किया जाना चाहिए
• परीक्षण सभी बग के लिए लिखा जाना चाहिए
• परीक्षण मामलों को एक परीक्षण तक सीमित किया जाना चाहिए
• पुनरारंभ करते समय परीक्षण त्रुटि के बिना चलना चाहिए

व्यवस्था कितनी विश्वसनीय है

प्रत्येक घटक सिस्टम की विश्वसनीयता के लिए जिम्मेदार है, इसलिए सिस्टम की विश्वसनीयता में सुधार के लिए ध्यान देना बहुत महत्वपूर्ण है। मुझे लगता है कि कोई भी ऐसे कंप्यूटर का उपयोग नहीं करना चाहेगा जो आपके अनुरोधों का 20% समय तक जवाब न दे। विश्वसनीयता के महत्व को प्रदर्शित करने के लिए, कल्पना करें कि आपके पास 3 घटकों की एक प्रणाली है। इन घटकों में से प्रत्येक 90% विश्वसनीय है, इसलिए कुल सिस्टम विश्वसनीयता प्रत्येक घटक की विश्वसनीयता का उत्पाद है, कुल 73%। अब याद कीजिए आपने लिखे आखिरी आवेदन में कितने घटक हैं ...

सतत निरीक्षण

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

निरंतर प्रतिक्रिया

CI में सबसे महत्वपूर्ण कार्यों में से एक प्रतिक्रिया तंत्र है, जिसे CI के प्रावधानों के अनुसार नियम को ध्यान में रखते हुए किया जाना चाहिए: "सही लोगों के लिए।" सही समय पर। सही तरीके से। ”(उत्पत्ति। -“ सही लोग। सही समय। सही तरीका। ”)।



निम्नलिखित लोकप्रिय प्रतिक्रिया तंत्र हैं:

• एसएमएस
• ब्राउज़र प्लग-इन
• ट्रैफिक लाइट असेंबली
• ध्वनि चेतावनी
• ईमेल

इसके अलावा, यह ध्यान देने योग्य है कि कई IDE (NetBeans, PHPStorm) आपको लोकप्रिय (जेनकिंस, टीमसिटी) CI सर्वर के साथ सिंक्रनाइज़ करने की अनुमति देते हैं।

वास्तविकता

यह सिर्फ इतना हुआ कि "खूनी उद्यम परियोजना" के विकास में भाग लेने के दौरान, मुझे आदर्श सीआई संस्करण को कठोर दुनिया की वास्तविकताओं के अनुकूल बनाना पड़ा। जब तक मैंने सीआई शुरू किया, तब तक कंपनी पहले से ही अपने निपटान में थी:

• दर्जनों सर्वरों के साथ CI सर्वर (जेनकिंस)
• इकाई परीक्षण, एक छोटी राशि के बावजूद
• स्क्रिप्ट का निर्माण, मुख्य रूप से शेल पर, लेकिन अपाचे चींटी पर स्विच करने की प्रवृत्ति के साथ
• मानक प्रतिक्रिया तंत्र - ईमेल

मुख्य समस्याएं हैं:

• डेवलपर्स भी इकाई परीक्षण लिखना नहीं चाहते हैं
• प्रतिक्रिया तंत्र की प्रतिक्रिया, धीमी, कई अक्षरों को केवल अनदेखा किया जाता है
• बग को यूनिट परीक्षणों द्वारा कवर नहीं किया जाता है

समाधान:

• सीआई और यूनिट परीक्षण पर रिपोर्ट
• प्रत्येक डेवलपर के साथ शैक्षिक कार्य
• क्यूए विभाग के साथ सहयोग
• विकास प्रक्रिया में परिवर्तन, परीक्षणों के अनिवार्य लेखन को शामिल करना

योजनाओं:

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

उपसंहार

सीआई अभ्यास, जो वर्तमान में "वयस्क" समाधानों की बढ़ती संख्या के विकास के संबंध में लोकप्रियता प्राप्त कर रहा है जो उनके उत्पाद की गुणवत्ता के लिए गंभीर जिम्मेदारी वहन करते हैं।



रुचि रखने वालों के लिए, मैं CI और संबंधित या व्युत्पन्न विषयों पर किताबें पढ़ने का सुझाव देता हूं:



पॉल डुवैल - निरंतर-एकीकरण

जेज़ विनम्र - निरंतर वितरण

रॉबर्ट मार्टिन - क्लीन कोड, क्लीन कोडर