एंड्रॉइड - निरंतर एकीकरण। भाग 1

मैं सौवीं बार नहीं बताऊंगा कि सीआई क्या है और इसकी आवश्यकता क्यों है। इस अवधारणा के आविष्कारक, अज्ञात नहीं हैं, मार्टिन फाउलर, लेकिन उनका काम यहां पाया जा सकता है ।

मैं निरंतर एकीकरण का उपयोग करके एंड्रॉइड एप्लिकेशन के विकास को व्यवस्थित करने के तरीके के बारे में कई लेखों की एक श्रृंखला में बताना चाहता हूं। यह मेरे लिए आश्चर्य की बात थी कि, सीआई की लोकप्रियता के बावजूद, इंटरनेट पर अभी भी कोई विस्तृत निर्देश नहीं है, कदम से कदम, शुरुआती लोगों के लिए, यहां तक ​​कि अंग्रेजी में भी, रूसी बोलने के लिए नहीं (अच्छी तरह से, या मुझे बस ऐसे नहीं मिलते हैं)।

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

मैं उपकरण / प्रौद्योगिकियों के निम्नलिखित सेट पर सभी उदाहरणों पर विचार करूंगा, हालांकि यह मौलिक नहीं है और उदाहरण के लिए, जीआईटी को आसानी से मर्क्यूरियल से बदला जा सकता है, और जेनकिंस के साथ टीमसिटी:

वीसीएस - जीआईटी
परीक्षण - एमुलेटर, एंड्रॉइड इंस्ट्रूमेंटेशन फ्रेमवर्क, जुनिट, रोबोटियम, रोबोइलेक्ट्रिक, मॉकिटो
बिल्डिंग - मावेन + एंड्रॉइड-मावेन-प्लगइन
IDE - इंटेलीज आईडिया
विरूपण साक्ष्य संग्रहण - Nexus
सीआई सर्वर - टीमसिटी

क्या उपलब्ध है:

इसलिए, परियोजना के स्रोत कोड जीआईटी रिपॉजिटरी में हैं, आवश्यक पुस्तकालय वहां संग्रहीत किए जाते हैं, सभी परियोजना प्रतिभागियों को एक मुख्य मास्टर शाखा के लिए प्रतिबद्ध किया जाता है, रिहाई के लिए विधानसभाएं वहां से एकत्र की जाती हैं। परीक्षणों की कोई अवधारणा नहीं है, विधानसभा को IntelliJ IDEA: Tools -> Android -> Export Signed Application Package. इस प्रक्रिया में प्रतिभागियों के बीच एकत्रित कलाकृतियों को मेल, स्काइप और अन्य द्वारा वितरित किया जाता है। अगले रिलीज़ संस्करण को तैयार करने में कई घंटे लग सकते हैं: कॉन्फ़िगर फ़ाइल को स्विच करना, एप्लिकेशन में संस्करण संख्या बदलना, रिपॉजिटरी के लिए रिलीज़ को कमिट करना, कमिट करने के लिए संस्करण संख्या के साथ एक टैग बनाना, फिर जाँचना कि सब कुछ इकट्ठा है जैसा कि होना चाहिए, एप्लिकेशन वांछित सर्वर को देखता है और आवश्यक के साथ हस्ताक्षरित होता है। कुंजी और सामान। और सभी जांच और सावधानियों के बावजूद, मानव कारक के बारे में नहीं भूलना चाहिए।

हम क्या पाना चाहते हैं:

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

• आईडीई के माध्यम से, डिबग से जुड़ने की क्षमता के साथ और आईडिया का उपयोग करके विभिन्न रन-कॉन्फ़िगरेशन बनाने (स्थानीय विकास के लिए सुविधाजनक, जल्दी से व्यक्तिगत परीक्षण शुरू करने के लिए, आदि)
• मावेन, एक क्लिक में या पूरी तरह से स्वचालित रूप से

परियोजना में तीन मॉड्यूल शामिल हैं:

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

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

CI सर्वर निम्न असेंबली करता है:

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

प्रत्येक सफल UAT या रिलीज़ बिल्ड के लिए, प्रपत्र rcX.XX-X या vX.XX का एक टैग क्रमशः रिपॉजिटरी में बनाया जाता है। यदि बिल्ड अभिभूत है: यह संकलन नहीं करता है, तो कुछ परीक्षण टूट गए हैं, आदि। - इच्छुक पार्टियों को अलर्ट के साथ एक पत्र भेजा जाता है।

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

अगले लेख में, हम मावेन के लिए अपना pom.xml लिखेंगे और धीरे-धीरे अपनी योजना को लागू करना शुरू करेंगे

PS जब मैं Habré पर एक लेख तैयार कर रहा था, तो इस विषय पर एक प्रकाशन सामने आया, फिर भी मैं अपने अनुभव लिखना और साझा करना जारी रखूंगा