यहां कुछ ऐसी सुविधाएं दी गई हैं जो ज़्यादातर सीआई सिस्टम में मिल सकती हैं.
पर्यावरण
यह समझना और चुनना ज़रूरी है कि सिस्टम किस हार्डवेयर और सॉफ़्टवेयर एनवायरमेंट में वर्कफ़्लो को लागू करता है. Android ऐप्लिकेशन के लिए, इन बातों का ध्यान रखना ज़रूरी है:
- प्लैटफ़ॉर्म: Linux, Mac, Windows, और उनके वर्शन.
- उपलब्ध मेमोरी: ऐप्लिकेशन बनाने और एमुलेटर चलाने के लिए, ज़्यादा रैम का इस्तेमाल किया जा सकता है. साथ ही, अक्सर मेमोरी खत्म होने से जुड़ी गड़बड़ियों से बचने के लिए, JVM के ढेर के साइज़ जैसे पैरामीटर में बदलाव करना ज़रूरी होता है.
- पहले से इंस्टॉल किया गया सॉफ़्टवेयर: आम तौर पर, सीआई सिस्टम ऐसी इमेज उपलब्ध कराते हैं जिनमें पहले से ही कई टूल मौजूद होते हैं. जैसे, Java Development Kit (JDK), Android सॉफ़्टवेयर डेवलपमेंट किट (SDK टूल), बिल्ड टूल, प्लैटफ़ॉर्म, और एमुलेटर.
- रनर आर्किटेक्चर और निर्देश सेट: ARM, x86. एमुलेटर का इस्तेमाल करते समय यह ज़रूरी है.
- एनवायरमेंट वैरिएबल: कुछ वैरिएबल, सीआई सिस्टम सेट करता है. जैसे:
ANDROID_HOME. हालांकि, आपके पास अपने हिसाब से वैरिएबल सेट करने का विकल्प होता है. उदाहरण के लिए, अपने वर्कफ़्लो में क्रेडेंशियल को हार्डकोड करने से बचने के लिए.
आपको कई अन्य बातों पर भी ध्यान देना चाहिए. जैसे, उपलब्ध कोर की संख्या और एमुलेटर चलाने के लिए, वर्चुअलाइज़ेशन की सुविधा चालू है या नहीं.
लॉग और रिपोर्ट
जब कोई चरण पूरा नहीं होता, तो सीआई सिस्टम आपको इसकी सूचना देता है और आम तौर पर, बदलाव को मर्ज करने की अनुमति नहीं देता. गड़बड़ी का पता लगाने के लिए, लॉग में गड़बड़ियां देखें.
इसके अलावा, बिल्ड करने और टेस्ट करने से ऐसी रिपोर्ट जनरेट होती हैं जिन्हें आम तौर पर उस बिल्ड के आर्टफ़ैक्ट के तौर पर सेव किया जाता है. सीआई सिस्टम के हिसाब से, उन रिपोर्ट के नतीजों को विज़ुअलाइज़ करने के लिए प्लग इन का इस्तेमाल किया जा सकता है.
कैश मेमोरी और सीआई के चलने में लगने वाला समय
सीआई सिस्टम, प्रोसेस को तेज़ करने के लिए बिल्ड कैश का इस्तेमाल करते हैं. सबसे आसान तरीके से, ये सभी Gradle कैश फ़ाइलों को बिल्ड होने के बाद सेव करते हैं और नए बिल्ड से पहले उन्हें वापस लाते हैं. यह Gradle के बिल्ड कैश की सुविधा पर निर्भर करता है. साथ ही, यह आपके प्रोजेक्ट में चालू होना चाहिए.
रन टाइम और भरोसे को बेहतर बनाने के कुछ तरीके यहां दिए गए हैं:
- मॉड्यूल: यह पता लगाना कि किसी बदलाव से किन मॉड्यूल पर असर पड़ा है और सिर्फ़ उन मॉड्यूल को बनाना और उनकी जांच करना.
- कैश मेमोरी को स्किप करें: अगर बिल्ड में ऐसी स्क्रिप्ट शामिल हैं जिनमें डेवलपर ने बदलाव किया है, तो बिल्ड कैश मेमोरी को अनदेखा करें. नए सिरे से बनाना ज़्यादा सुरक्षित है.
- टेस्ट को अलग-अलग हिस्सों में बांटना: खास तौर पर, इंस्ट्रूमेंट किए गए टेस्ट को कई डिवाइसों पर बांटने से फ़ायदा मिल सकता है. यह सुविधा, Android runner, Gradle के मैनेज किए जा रहे डिवाइसों, और Firebase टेस्ट लैब के साथ काम करती है.
- बिल्ड को अलग-अलग हिस्सों में बांटना: बिल्ड को कई सर्वर इंस्टेंस में बांटा जा सकता है.
- रिमोट कैश मेमोरी: Gradle के रिमोट कैश मेमोरी का भी इस्तेमाल किया जा सकता है.
जिन टेस्ट को पूरा नहीं किया जा सका उन्हें फिर से चलाना
फ़्लैकीनेस का मतलब उन जांचों या टूल से है जो कभी-कभी काम नहीं करते. आपको हमेशा उन समस्याओं को ढूंढने और ठीक करने की कोशिश करनी चाहिए जिनकी वजह से गड़बड़ियों वाले बिल्ड और टेस्ट जनरेट होते हैं. हालांकि, इनमें से कुछ समस्याओं को दोबारा जनरेट करना मुश्किल होता है. खास तौर पर, इंस्ट्रूमेंट किए गए टेस्ट चलाते समय. आम तौर पर, टेस्ट रन के पूरा न होने पर, उन्हें फिर से चलाया जाता है. ऐसा तय संख्या तक किया जाता है.
फिर से कोशिश करने की सुविधा को कॉन्फ़िगर करने का कोई एक तरीका नहीं है, क्योंकि यह कई लेवल पर हो सकती है. नीचे दी गई टेबल में, टेस्ट के दौरान आ रही गड़बड़ी के जवाब में की जाने वाली कार्रवाई के बारे में बताया गया है:
कार्रवाई सफल नहीं हुई |
कार्रवाई |
|---|---|
एम्युलेटर एक सेकंड के लिए काम नहीं कर रहा था, जिसकी वजह से टाइम आउट ट्रिगर हुआ |
पूरा न हो सकने वाले टेस्ट को फिर से चलाना |
एमुलेटर बूट नहीं हो सका |
पूरा टास्क फिर से चलाना |
कोड चेकआउट के दौरान कनेक्शन से जुड़ी गड़बड़ी हुई |
वर्कफ़्लो को फिर से शुरू करना |
यह ज़रूरी है कि सिस्टम के किन हिस्सों में समस्या आ रही है, इसकी जानकारी लॉग की जाए और उसका ट्रैक रखा जाए. साथ ही, सिर्फ़ फिर से कोशिश करने पर भरोसा न करके, सीआई को भरोसेमंद और तेज़ बनाए रखने पर ध्यान दिया जाए