आज, बहुतेक सॉफ्टवेअर उत्पादने संघांमध्ये विकसित केली जातात. यशस्वी संघ विकासाची परिस्थिती एका साध्या आकृतीच्या स्वरूपात दर्शविली जाऊ शकते.

एकदा तुम्ही तुमचा कोड लिहिल्यानंतर, तुम्हाला याची खात्री करणे आवश्यक आहे:

.
तुमच्या सहकाऱ्यांनी लिहिलेल्या कोडसह ते काहीही खंडित करत नाही.

जर दोन्ही अटी पूर्ण झाल्या तर तुम्ही यशाच्या मार्गावर आहात. या अटी सहज तपासण्यासाठी आणि फायदेशीर मार्गापासून विचलित न होण्यासाठी, आम्ही सतत एकात्मता आणली.

CI हा एक कार्यप्रवाह आहे जिथे तुम्ही तुमचा कोड शक्य तितक्या वेळा एकूण उत्पादन कोडमध्ये समाकलित करता. आणि तुम्ही नुसते समाकलित करत नाही, तर सर्वकाही कार्य करत आहे हे सतत तपासा. आपल्याला बरेचदा आणि बरेचदा तपासण्याची आवश्यकता असल्याने, ऑटोमेशनबद्दल विचार करणे योग्य आहे. तुम्ही सर्वकाही व्यक्तिचलितपणे तपासू शकता, परंतु तुम्ही ते करू नये आणि ते का ते येथे आहे.

प्रिय लोक. कोणत्याही प्रोग्रामरच्या कामाचा एक तास कोणत्याही सर्व्हरच्या कामाच्या तासापेक्षा महाग असतो.
लोक चुका करतात. त्यामुळे, चुकीच्या शाखेवर चाचण्या घेतल्या गेल्या किंवा परीक्षकांसाठी चुकीचे वचन संकलित केले गेले तेव्हा परिस्थिती उद्भवू शकते.
लोक आळशी आहेत. वेळोवेळी, जेव्हा मी एखादे काम पूर्ण करतो, तेव्हा विचार येतो: “तपासण्यासारखे काय आहे? मी दोन ओळी लिहिल्या - सर्वकाही कार्य करते! मला वाटतं तुमच्यापैकी काहींच्या मनात कधी कधी असे विचार येतात. परंतु आपण नेहमी तपासले पाहिजे.

अविटो मोबाइल डेव्हलपमेंट टीममध्ये कंटिन्युअस इंटिग्रेशन कसे अंमलात आणले गेले आणि विकसित केले गेले, ते दररोज 0 ते 450 बिल्ड कसे झाले आणि बिल्ड मशीन्स दिवसातून 200 तास एकत्र होतात, असे निकोलाई नेस्टेरोव्ह म्हणतात (nnesterov) CI/CD Android अनुप्रयोगातील सर्व उत्क्रांतीवादी बदलांमध्ये सहभागी आहे.

कथा Android कमांडच्या उदाहरणावर आधारित आहे, परंतु बहुतेक दृष्टिकोन iOS वर देखील लागू आहेत.

एकेकाळी, एक व्यक्ती अविटो अँड्रॉइड टीममध्ये काम करत होती. व्याख्येनुसार, त्याला सतत एकात्मतेपासून कशाचीही आवश्यकता नव्हती: समाकलित करण्यासाठी कोणीही नव्हते.

परंतु अनुप्रयोग वाढला, अधिकाधिक नवीन कार्ये दिसू लागली आणि त्यानुसार कार्यसंघ वाढला. काही क्षणी, कोड एकत्रीकरण प्रक्रिया अधिक औपचारिकपणे स्थापित करण्याची वेळ आली आहे. Git प्रवाह वापरण्याचे ठरले.

गिट फ्लोची संकल्पना सर्वज्ञात आहे: प्रकल्पामध्ये एक सामान्य विकास शाखा असते आणि प्रत्येक नवीन वैशिष्ट्यासाठी, विकासक एक वेगळी शाखा कापतात, त्यास वचनबद्ध करतात, पुश करतात आणि जेव्हा त्यांना त्यांचा कोड विकास शाखेत विलीन करायचा असतो तेव्हा एक उघडा. पुल विनंती. ज्ञान सामायिक करण्यासाठी आणि दृष्टिकोनांवर चर्चा करण्यासाठी, आम्ही कोड पुनरावलोकन सादर केले, म्हणजेच सहकाऱ्यांनी एकमेकांचा कोड तपासणे आणि पुष्टी करणे आवश्यक आहे.

चेक करतो

आपल्या डोळ्यांनी कोड पाहणे छान आहे, परंतु पुरेसे नाही. त्यामुळे स्वयंचलित तपासण्या सुरू केल्या जात आहेत.

सर्व प्रथम, आम्ही तपासतो ARK असेंब्ली.
खूप ज्युनिट चाचण्या.
आम्ही कोड कव्हरेजचा विचार करतो, कारण आम्ही चाचण्या घेत आहोत.

या तपासण्या कशा चालवल्या पाहिजेत हे समजून घेण्यासाठी, एविटोमधील विकास प्रक्रिया पाहू.

हे याप्रमाणे योजनाबद्धपणे दर्शविले जाऊ शकते:

विकासक त्याच्या लॅपटॉपवर कोड लिहितो. तुम्ही येथे एकत्रीकरण तपासण्या चालवू शकता - एकतर कमिट हुकसह, किंवा फक्त पार्श्वभूमीत तपासा चालवा.
विकसकाने कोड पुश केल्यानंतर, तो एक पुल विनंती उघडतो. त्याचा कोड डेव्हलप ब्रँचमध्ये समाविष्ट करण्‍यासाठी, कोड रिव्ह्यूमधून जाणे आणि आवश्यक पुष्टीकरणे गोळा करणे आवश्यक आहे. तुम्ही येथे चेक आणि बिल्ड सक्षम करू शकता: जोपर्यंत सर्व बिल्ड यशस्वी होत नाहीत, पुल विनंती विलीन केली जाऊ शकत नाही.
पुल रिक्वेस्ट विलीन झाल्यानंतर आणि कोड डेव्हलपमध्ये समाविष्ट केल्यानंतर, तुम्ही सोयीस्कर वेळ निवडू शकता: उदाहरणार्थ, रात्री, जेव्हा सर्व सर्व्हर मोकळे असतात आणि तुम्हाला हवे तितके चेक चालवा.

कोणालाही त्यांच्या लॅपटॉपवर स्कॅन चालवणे आवडत नाही. विकसकाने एखादे वैशिष्‍ट्य पूर्ण केल्‍यावर, तो त्‍याला झटपट पुश करू इच्छितो आणि पुल विनंती उघडू इच्छितो. जर या क्षणी काही लांब चेक लॉन्च केले गेले तर हे केवळ खूप आनंददायी नाही तर विकास देखील कमी करते: लॅपटॉप काहीतरी तपासत असताना, त्यावर सामान्यपणे कार्य करणे अशक्य आहे.

आम्हाला रात्री चेक चालवणे खूप आवडले, कारण भरपूर वेळ आणि सर्व्हर आहे, तुम्ही फिरू शकता. परंतु, दुर्दैवाने, जेव्हा वैशिष्ट्य कोड विकसित होतो, तेव्हा CI ला आढळलेल्या त्रुटी दूर करण्यासाठी विकसकाला खूप कमी प्रेरणा मिळते. मी वेळोवेळी सकाळच्या अहवालात आढळलेल्या सर्व त्रुटींकडे पाहत होतो तेव्हा मी स्वत: ला विचार करत होतो की मी त्या नंतर कधीतरी दुरुस्त करेन, कारण आता जिरामध्ये एक नवीन कार्य आहे जे मला फक्त सुरू करायचे आहे.

जर चेकने पुल विनंती अवरोधित केली, तर पुरेशी प्रेरणा आहे, कारण बिल्ड हिरवे होईपर्यंत, कोड विकसित होणार नाही, याचा अर्थ कार्य पूर्ण होणार नाही.

परिणामी, आम्ही खालील रणनीती निवडली: आम्ही रात्रीच्या वेळी जास्तीत जास्त संभाव्य तपासण्या चालवतो आणि त्यातील सर्वात गंभीर आणि सर्वात महत्त्वाचे म्हणजे, पुल विनंतीवर सर्वात वेगवान तपासण्या सुरू करतो. पण आम्ही तिथे थांबत नाही—समांतरपणे, आम्ही चेकची गती ऑप्टिमाइझ करतो जेणेकरुन विनंती चेक खेचण्यासाठी त्यांना रात्रीच्या मोडमधून हस्तांतरित करता येईल.

त्या वेळी, आमच्या सर्व बिल्ड खूप लवकर पूर्ण झाल्या होत्या, म्हणून आम्ही पुल विनंतीसाठी ब्लॉकर म्हणून ARK बिल्ड, जुनिट चाचण्या आणि कोड कव्हरेज गणना समाविष्ट केली. आम्ही ते चालू केले, त्याबद्दल विचार केला आणि कोड कव्हरेज सोडून दिले कारण आम्हाला वाटले की आम्हाला त्याची गरज नाही.

मूलभूत CI पूर्णपणे सेट करण्यासाठी आम्हाला दोन दिवस लागले (यानंतर वेळेचा अंदाज अंदाजे आहे, स्केलसाठी आवश्यक आहे).

त्यानंतर, आम्ही पुढे विचार करू लागलो - आम्ही अगदी बरोबर तपासत आहोत का? आम्ही पुल विनंत्यांवर बिल्ड योग्यरित्या चालवत आहोत का?

ज्या शाखेतून पुल विनंती उघडली गेली होती त्या शाखेच्या शेवटच्या कमिटवर आम्ही बिल्ड सुरू केले. परंतु या कमिटच्या चाचण्या हे दर्शवू शकतात की विकसकाने लिहिलेला कोड कार्य करतो. पण त्याने काहीही तोडले नाही हे ते सिद्ध करत नाहीत. खरं तर, एखाद्या वैशिष्ट्यामध्ये विलीन झाल्यानंतर तुम्हाला विकास शाखेची स्थिती तपासण्याची आवश्यकता आहे.

हे करण्यासाठी, आम्ही एक साधी बॅश स्क्रिप्ट लिहिली premerge.sh:

#!/usr/bin/env bash

set -e

git fetch origin develop

git merge origin/develop

येथे डेव्हलपमधील सर्व नवीनतम बदल सहजपणे ओढले जातात आणि सध्याच्या शाखेत विलीन केले जातात. आम्ही सर्व बिल्डमध्ये पहिली पायरी म्हणून premerge.sh स्क्रिप्ट जोडली आणि आम्हाला नेमके काय हवे आहे ते तपासण्यास सुरुवात केली, म्हणजे एकीकरण.

समस्येचे स्थानिकीकरण करण्यासाठी, त्यावर उपाय शोधण्यासाठी आणि ही स्क्रिप्ट लिहिण्यासाठी तीन दिवस लागले.

अनुप्रयोग विकसित झाला, अधिकाधिक कार्ये दिसू लागली, संघ वाढला आणि premerge.sh कधीकधी आम्हाला निराश करू लागला. डेव्हलपमध्ये विरोधाभासी बदल झाले ज्यामुळे बिल्ड खंडित झाली.

हे कसे घडते याचे उदाहरणः

दोन विकासक एकाच वेळी A आणि B वैशिष्ट्यांवर काम करण्यास सुरवात करतात. वैशिष्ट्य A च्या विकासकाला प्रकल्पातील एक न वापरलेले वैशिष्ट्य सापडते answer() आणि, एखाद्या चांगल्या मुलाप्रमाणे, ते काढून टाकते. त्याच वेळी, फीचर B चा विकासक त्याच्या शाखेत या कार्यासाठी एक नवीन कॉल जोडतो.

विकसक त्यांचे काम पूर्ण करतात आणि त्याच वेळी पुल विनंती उघडतात. बिल्ड लाँच केले आहेत, premerge.sh नवीनतम विकसित स्थितीशी संबंधित दोन्ही पुल विनंत्या तपासते - सर्व चेक हिरवे आहेत. त्यानंतर, वैशिष्ट्य A ची पुल विनंती विलीन केली जाते, वैशिष्ट्य B ची पुल विनंती विलीन केली जाते... बूम! डेव्हलप ब्रेक्स कारण डेव्हलप कोडमध्ये अस्तित्वात नसलेल्या फंक्शनला कॉल असतो.

जेव्हा ते विकसित होणार नाही, ते आहे स्थानिक आपत्ती. संपूर्ण टीम काहीही गोळा करू शकत नाही आणि चाचणीसाठी सबमिट करू शकत नाही.

असे घडले की मी बहुतेकदा पायाभूत सुविधांच्या कार्यांवर काम केले: विश्लेषण, नेटवर्क, डेटाबेस. म्हणजेच, इतर विकासक वापरत असलेली फंक्शन्स आणि क्लासेस मीच लिहिले. या कारणास्तव, मी स्वतःला बर्‍याचदा अशाच परिस्थितीत सापडले. मी तर हे चित्र काही काळ लटकले होते.

हे आम्हाला शोभत नसल्यामुळे, आम्ही हे कसे रोखायचे याचे पर्याय शोधू लागलो.

विकास कसा खंडित करू नये

पहिला पर्याय: विकास अद्यतनित करताना सर्व पुल विनंत्या पुन्हा तयार करा. जर, आमच्या उदाहरणात, वैशिष्ट्य A सह पुल विनंती विकासामध्ये समाविष्ट केलेली प्रथम असेल, तर वैशिष्ट्य B ची पुल विनंती पुन्हा तयार केली जाईल आणि, त्यानुसार, संकलन त्रुटीमुळे चेक अयशस्वी होतील.

यास किती वेळ लागेल हे समजून घेण्यासाठी, दोन PR सह उदाहरण विचारात घ्या. आम्ही दोन पीआर उघडतो: दोन बिल्ड, दोन रन ऑफ चेक. पहिला पीआर डेव्हलपमध्ये विलीन झाल्यानंतर, दुसरा पुन्हा तयार करणे आवश्यक आहे. एकूण, दोन PR साठी तीन रन चेक आवश्यक आहेत: 2 + 1 = 3.

तत्वतः, ते ठीक आहे. परंतु आम्ही आकडेवारी पाहिली, आणि आमच्या संघातील विशिष्ट परिस्थिती 10 खुली पीआर होती, आणि नंतर धनादेशांची संख्या ही प्रगतीची बेरीज आहे: 10 + 9 +... + 1 = 55. म्हणजेच 10 स्वीकारणे PRs, तुम्हाला 55 वेळा पुनर्बांधणी करणे आवश्यक आहे. आणि ही एक आदर्श परिस्थिती आहे, जेव्हा सर्व चेक प्रथमच पास होतात, जेव्हा या डझनवर प्रक्रिया होत असताना कोणीही अतिरिक्त पुल विनंती उघडत नाही.

स्वत: ला एक विकासक म्हणून कल्पना करा ज्याने "विलीन" बटणावर क्लिक करणे आवश्यक आहे, कारण एखाद्या शेजाऱ्याने असे केल्यास, सर्व बिल्ड्स पुन्हा पूर्ण होईपर्यंत तुम्हाला प्रतीक्षा करावी लागेल... नाही, ते कार्य करणार नाही , तो गंभीरपणे विकास मंदावेल.

दुसरा संभाव्य मार्ग: कोड पुनरावलोकनानंतर पुल विनंत्या गोळा करा. म्हणजेच, तुम्ही पुल रिक्वेस्ट उघडा, सहकाऱ्यांकडून आवश्यक प्रमाणात मंजूरी गोळा करा, आवश्यक ते दुरुस्त करा आणि नंतर बिल्ड लाँच करा. जर ते यशस्वी झाले, तर पुल विनंती डेव्हलपमध्ये विलीन केली जाईल. या प्रकरणात, कोणतेही अतिरिक्त रीस्टार्ट नाहीत, परंतु अभिप्राय मोठ्या प्रमाणात मंद झाला आहे. डेव्हलपर म्हणून, जेव्हा मी पुल विनंती उघडतो, तेव्हा मला ते कार्य करत आहे की नाही हे त्वरित पहायचे आहे. उदाहरणार्थ, एखादी चाचणी अयशस्वी झाल्यास, आपल्याला ते द्रुतपणे दुरुस्त करण्याची आवश्यकता आहे. विलंबित बिल्डच्या बाबतीत, अभिप्राय मंदावतो आणि त्यामुळे संपूर्ण विकास. हे आम्हालाही पटले नाही.

परिणामी, फक्त तिसरा पर्याय राहिला - दुचाकी. आमचे सर्व कोड, आमचे सर्व स्रोत बिटबकेट सर्व्हरवरील भांडारात साठवले जातात. त्यानुसार, आम्हाला बिटबकेटसाठी प्लगइन विकसित करावे लागले.

हे प्लगइन पुल विनंती विलीनीकरण यंत्रणा अधिलिखित करते. सुरुवात मानक आहे: PR उघडते, सर्व संमेलने सुरू केली जातात, कोड पुनरावलोकन पूर्ण होते. परंतु कोड रिव्ह्यू पूर्ण झाल्यानंतर आणि डेव्हलपरने “मर्ज” वर क्लिक करण्याचा निर्णय घेतल्यानंतर, प्लगइन चेक कोणत्या डेव्हलप स्टेटमध्ये चालवले गेले ते तपासते. बिल्ड केल्यानंतर डेव्हलप अपडेट केले असल्यास, प्लगइन अशा पुल विनंतीला मुख्य शाखेत विलीन करण्याची परवानगी देणार नाही. हे तुलनेने अलीकडील विकासाचे बिल्ड रीस्टार्ट करेल.

विरोधाभासी बदलांसह आमच्या उदाहरणामध्ये, संकलन त्रुटीमुळे अशा बिल्ड अयशस्वी होतील. त्यानुसार, वैशिष्ट्य B च्या विकसकाला कोड दुरुस्त करावा लागेल, चेक रीस्टार्ट करावे लागेल, त्यानंतर प्लगइन स्वयंचलितपणे पुल विनंती लागू करेल.

हे प्लगइन लागू करण्यापूर्वी, आम्ही प्रति पुल विनंती सरासरी 2,7 पुनरावलोकन धावा केल्या. प्लगइनसह 3,6 लाँच झाले. हे आम्हाला अनुकूल होते.

हे लक्षात घेण्यासारखे आहे की या प्लगइनमध्ये एक कमतरता आहे: ते फक्त एकदाच बिल्ड रीस्टार्ट करते. म्हणजेच, अजूनही एक लहान विंडो आहे ज्याद्वारे परस्परविरोधी बदल विकसित होऊ शकतात. पण याची शक्यता कमी आहे, आणि आम्ही हा ट्रेड-ऑफ स्टार्टची संख्या आणि अयशस्वी होण्याची शक्यता यांच्या दरम्यान केला. दोन वर्षांत ते फक्त एकदाच उडाले, म्हणून ते कदाचित व्यर्थ ठरले नाही.

बिटबकेट प्लगइनची पहिली आवृत्ती लिहिण्यासाठी आम्हाला दोन आठवडे लागले.

नवीन धनादेश

दरम्यान, आमची टीम वाढत गेली. नवीन धनादेश जोडले गेले आहेत.

आम्ही विचार केला: जर त्या टाळता आल्या तर चुका का कराव्यात? आणि म्हणूनच त्यांनी अमलात आणले स्थिर कोड विश्लेषण. आम्ही लिंटसह सुरुवात केली, जी Android SDK मध्ये समाविष्ट आहे. परंतु त्या वेळी त्याला कोटलिन कोडसह कसे कार्य करावे हे माहित नव्हते आणि आमच्याकडे आधीच कोटलिनमध्ये 75% अर्ज लिहिलेले होते. म्हणून, बिल्ट-इन लिंटमध्ये जोडले गेले Android स्टुडिओ तपासतो.

हे करण्यासाठी, आम्हाला बरेच विकृतीकरण करावे लागले: अँड्रॉइड स्टुडिओ घ्या, ते डॉकरमध्ये पॅकेज करा आणि व्हर्च्युअल मॉनिटरसह सीआयवर चालवा, जेणेकरून ते वास्तविक लॅपटॉपवर चालत आहे असे समजेल. पण काम झाले.

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

परंतु इन्स्ट्रुमेंटेशन चाचण्या आणि स्क्रीनशॉट चाचण्या डिव्हाइसेसवर चालवल्या पाहिजेत: एमुलेटरवर किंवा वास्तविक उपकरणांवर. बर्याच चाचण्या आहेत आणि त्या वारंवार चालवल्या जातात हे लक्षात घेता, संपूर्ण शेत आवश्यक आहे. तुमची स्वतःची शेती सुरू करणे खूप श्रम-केंद्रित आहे, म्हणून आम्हाला एक तयार पर्याय सापडला - फायरबेस टेस्ट लॅब.

फायरबेस चाचणी प्रयोगशाळा

फायरबेस हे Google उत्पादन असल्यामुळे ते निवडले गेले आहे, याचा अर्थ ते विश्वसनीय असावे आणि कधीही मरण्याची शक्यता नाही. किमती वाजवी आहेत: वास्तविक उपकरणाच्या ऑपरेशनसाठी $5 प्रति तास, एमुलेटरच्या ऑपरेशनसाठी 1 $ प्रति तास.

आमच्या CI मध्ये फायरबेस चाचणी लॅब कार्यान्वित करण्यासाठी सुमारे तीन आठवडे लागले.

परंतु संघ वाढतच गेला आणि फायरबेसने दुर्दैवाने आम्हाला निराश करण्यास सुरुवात केली. त्यावेळी त्यांच्याकडे कोणताही एसएलए नव्हता. काहीवेळा Firebase ने आम्हाला चाचण्यांसाठी आवश्यक उपकरणे मोफत मिळेपर्यंत थांबायला लावले आणि आम्हाला हवे तसे ते लगेच कार्यान्वित करणे सुरू केले नाही. रांगेत थांबायला अर्धा तास लागला, जो बराच वेळ आहे. प्रत्येक PR वर इंस्ट्रुमेंटेशन चाचण्या चालवल्या गेल्या, विलंबाने खरोखरच विकास मंदावला आणि नंतर मासिक बिल पूर्ण रकमेसह आले. सर्वसाधारणपणे, टीम पुरेशी वाढलेली असल्याने फायरबेस सोडून घरामध्ये काम करण्याचा निर्णय घेण्यात आला.

डॉकर + पायथन + बॅश

आम्ही डॉकर घेतले, त्यात एमुलेटर भरले, पायथनमध्ये एक साधा प्रोग्राम लिहिला, जो योग्य वेळी योग्य आवृत्तीमध्ये आवश्यक प्रमाणात एमुलेटर सुरू करतो आणि आवश्यक असल्यास त्यांना थांबवतो. आणि, अर्थातच, दोन बॅश स्क्रिप्ट्स - आम्ही त्यांच्याशिवाय कुठे असू?

आमचे स्वतःचे चाचणी वातावरण तयार करण्यासाठी पाच आठवडे लागले.

परिणामी, प्रत्येक पुल विनंतीसाठी चेकची विस्तृत मर्ज-ब्लॉकिंग सूची होती:

एआरके असेंब्ली;
ज्युनिट चाचण्या;
लिंट;
Android स्टुडिओ तपासणी;
इन्स्ट्रुमेंटेशन चाचण्या;
स्क्रीनशॉट चाचण्या.

यामुळे अनेक संभाव्य ब्रेकडाउन टाळले. तांत्रिकदृष्ट्या सर्वकाही कार्य केले, परंतु विकासकांनी तक्रार केली की परिणामांची प्रतीक्षा खूप लांब आहे.

किती लांब आहे खूप लांब? आम्ही Bitbucket आणि TeamCity मधील डेटा विश्लेषण प्रणालीमध्ये अपलोड केला आणि ते लक्षात आले सरासरी प्रतीक्षा वेळ 45 मिनिटे. म्हणजेच, विकासक, पुल विनंती उघडताना, बिल्ड परिणामांसाठी सरासरी 45 मिनिटे प्रतीक्षा करतो. माझ्या मते, हे खूप आहे आणि आपण असे कार्य करू शकत नाही.

अर्थात, आम्ही आमच्या सर्व बांधकामांना गती देण्याचा निर्णय घेतला.

चला वेग वाढवूया

बिल्ड्स अनेकदा रांगेत उभं राहतात हे बघून, पहिली गोष्ट आपण करतो अधिक हार्डवेअर विकत घेतले - व्यापक विकास सर्वात सोपा आहे. बिल्ड्सने रांगा लावणे थांबवले, परंतु प्रतीक्षा वेळ थोडासा कमी झाला, कारण काही चेक स्वतःच खूप वेळ घेतात.

खूप वेळ घेणारे धनादेश काढत आहे

आमचे सतत एकत्रीकरण या प्रकारच्या त्रुटी आणि समस्या पकडू शकते.

जाणार नाही. जेव्हा परस्परविरोधी बदलांमुळे काहीतरी तयार होत नाही तेव्हा CI संकलन त्रुटी पकडू शकते. मी आधीच म्हटल्याप्रमाणे, मग कोणाला काही जमत नाही, विकास थांबतो आणि सर्वजण घाबरतात.
वागण्यात बग. उदाहरणार्थ, जेव्हा अनुप्रयोग तयार केला जातो, परंतु जेव्हा तुम्ही बटण दाबता तेव्हा क्रॅश होतो किंवा बटण अजिबात दाबले जात नाही. हे वाईट आहे कारण असा बग वापरकर्त्यापर्यंत पोहोचू शकतो.
लेआउटमध्ये बग. उदाहरणार्थ, एक बटण क्लिक केले आहे, परंतु 10 पिक्सेल डावीकडे हलविले आहे.
तांत्रिक कर्जात वाढ.

ही यादी पाहिल्यानंतर आमच्या लक्षात आले की फक्त पहिले दोन मुद्दे गंभीर आहेत. आम्हाला अशा समस्या आधी पकडायच्या आहेत. लेआउटमधील बग डिझाइन-पुनरावलोकनाच्या टप्प्यावर शोधले जातात आणि नंतर ते सहजपणे दुरुस्त केले जाऊ शकतात. तांत्रिक कर्ज हाताळण्यासाठी स्वतंत्र प्रक्रिया आणि नियोजन आवश्यक आहे, म्हणून आम्ही पुल विनंतीवर त्याची चाचणी न घेण्याचा निर्णय घेतला.

या वर्गीकरणाच्या आधारे, आम्ही चेकची संपूर्ण यादी हलवली. लिंट पार केले आणि त्याचे प्रक्षेपण रात्रभर पुढे ढकलले: फक्त त्यामुळे प्रकल्पात किती समस्या आहेत याचा अहवाल तयार केला जाईल. आम्ही तांत्रिक कर्जासह स्वतंत्रपणे काम करण्यास सहमत झालो, आणि अँड्रॉइड स्टुडिओ तपासणे पूर्णपणे सोडून दिले होते. तपासणीसाठी डॉकरमधील Android स्टुडिओ मनोरंजक वाटतो, परंतु समर्थनामध्ये खूप त्रास होतो. अँड्रॉइड स्टुडिओ आवृत्त्यांचे कोणतेही अद्यतन म्हणजे न समजण्याजोग्या बगसह संघर्ष आहे. स्क्रीनशॉट चाचण्यांचे समर्थन करणे देखील अवघड होते, कारण लायब्ररी फारशी स्थिर नव्हती आणि तेथे चुकीचे सकारात्मक होते. चेक लिस्टमधून स्क्रीनशॉट चाचण्या काढून टाकल्या आहेत.

परिणामी, आमच्याकडे बाकी होते:

एआरके असेंब्ली;
ज्युनिट चाचण्या;
इन्स्ट्रुमेंटेशन चाचण्या.

ग्रेडल रिमोट कॅशे

जड तपासण्यांशिवाय, सर्वकाही चांगले झाले. पण परिपूर्णतेला मर्यादा नाही!

आमचा अर्ज आधीच सुमारे 150 ग्रेडल मॉड्यूल्समध्ये विभागला गेला आहे. Gradle रिमोट कॅशे सहसा या प्रकरणात चांगले कार्य करते, म्हणून आम्ही ते वापरण्याचा निर्णय घेतला.

ग्रेडल रिमोट कॅशे ही एक सेवा आहे जी वैयक्तिक मॉड्यूल्समधील वैयक्तिक कार्यांसाठी आर्टिफॅक्ट तयार करू शकते. ग्रेडल, कोड प्रत्यक्षात संकलित करण्याऐवजी, रिमोट कॅशेवर नॉक करण्यासाठी HTTP वापरतो आणि कोणीतरी हे कार्य आधीच केले आहे का ते विचारतो. होय असल्यास, ते फक्त परिणाम डाउनलोड करते.

Gradle रिमोट कॅशे चालवणे सोपे आहे कारण Gradle डॉकर प्रतिमा प्रदान करते. आम्ही हे तीन तासांत करू शकलो.

तुम्हाला फक्त डॉकर लाँच करायचे होते आणि प्रोजेक्टमध्ये एक ओळ लिहायची होती. परंतु ते त्वरीत लॉन्च केले जाऊ शकत असले तरी, सर्वकाही व्यवस्थित कार्य करण्यासाठी बराच वेळ लागेल.

खाली कॅशे मिस्स आलेख आहे.

अगदी सुरुवातीस, कॅशे मिस्सची टक्केवारी सुमारे 65 होती. तीन आठवड्यांनंतर, आम्ही हे मूल्य 20% पर्यंत वाढविण्यात व्यवस्थापित केले. असे दिसून आले की Android अनुप्रयोग संकलित केलेल्या कार्यांमध्ये विचित्र संक्रमणात्मक अवलंबित्व आहेत, ज्यामुळे ग्रेडलने कॅशे गमावला.

कॅशे कनेक्ट करून, आम्ही बिल्डला मोठ्या प्रमाणात गती दिली. परंतु असेंब्ली व्यतिरिक्त, इन्स्ट्रुमेंटेशन चाचण्या देखील आहेत आणि त्यांना बराच वेळ लागतो. कदाचित प्रत्येक पुल विनंतीसाठी सर्व चाचण्या चालवण्याची गरज नाही. शोधण्यासाठी, आम्ही प्रभाव विश्लेषण वापरतो.

प्रभाव विश्लेषण

पुल विनंतीवर, आम्ही git diff गोळा करतो आणि सुधारित Gradle मॉड्यूल्स शोधतो.

बदललेले मॉड्युल आणि त्यांच्यावर अवलंबून असलेले सर्व मॉड्युल्स तपासणार्‍या केवळ इन्स्ट्रुमेंटेशन चाचण्या चालवणे अर्थपूर्ण आहे. शेजारच्या मॉड्यूल्ससाठी चाचण्या चालवण्यात काही अर्थ नाही: तेथील कोड बदलला नाही आणि काहीही खंडित होऊ शकत नाही.

इन्स्ट्रुमेंटेशन चाचण्या इतक्या सोप्या नाहीत, कारण त्या उच्च-स्तरीय ऍप्लिकेशन मॉड्यूलमध्ये स्थित असणे आवश्यक आहे. प्रत्येक चाचणी कोणत्या मॉड्यूलशी संबंधित आहे हे समजून घेण्यासाठी आम्ही बायकोड विश्लेषणासह ह्युरिस्टिक्सचा वापर केला.

इन्स्ट्रुमेंटेशन चाचण्यांचे ऑपरेशन अपग्रेड करणे जेणेकरुन ते फक्त समाविष्ट असलेल्या मॉड्यूल्सची चाचणी घेतात सुमारे आठ आठवडे.

तपासण्यांना गती देण्याचे उपाय यशस्वीरित्या काम करत आहेत. 45 मिनिटांपासून आम्ही सुमारे 15 पर्यंत गेलो. बांधण्यासाठी एक चतुर्थांश तास प्रतीक्षा करणे आधीच सामान्य आहे.

परंतु आता विकासकांनी तक्रार करण्यास सुरुवात केली आहे की त्यांना कोणते बिल्ड लॉन्च केले जात आहेत, लॉग कुठे पहायचे, बिल्ड लाल का आहे, कोणती चाचणी अयशस्वी झाली इत्यादी.

फीडबॅकमधील समस्यांमुळे विकास कमी होतो, म्हणून आम्ही प्रत्येक PR आणि शक्य तितक्या बिल्डबद्दल स्पष्ट आणि तपशीलवार माहिती देण्याचा प्रयत्न केला. आम्ही Bitbucket to PR मधील टिप्पण्यांसह सुरुवात केली, कोणती बिल्ड अयशस्वी झाली आणि का हे दर्शविते आणि Slack मध्ये लक्ष्यित संदेश लिहिले. सरतेशेवटी, आम्ही पृष्ठासाठी सध्या चालू असलेल्या सर्व बिल्ड आणि त्यांची स्थिती: रांगेत, चालू, क्रॅश किंवा पूर्ण केलेल्या सूचीसह PR डॅशबोर्ड तयार केला. तुम्ही बिल्डवर क्लिक करून त्याच्या लॉगवर जाऊ शकता.

तपशीलवार अभिप्रायावर सहा आठवडे घालवले गेले.

योजना

अलीकडील इतिहासाकडे वळूया. फीडबॅक समस्येचे निराकरण केल्यावर, आम्ही एका नवीन स्तरावर पोहोचलो - आम्ही आमचे स्वतःचे एमुलेटर फार्म तयार करण्याचा निर्णय घेतला. जेव्हा अनेक चाचण्या आणि अनुकरणकर्ते असतात तेव्हा ते व्यवस्थापित करणे कठीण असते. परिणामी, आमचे सर्व अनुकरणकर्ते लवचिक संसाधन व्यवस्थापनासह k8s क्लस्टरमध्ये गेले.

याव्यतिरिक्त, इतर योजना आहेत.

लिंट परत करा (आणि इतर स्थिर विश्लेषण). आम्ही आधीच या दिशेने काम करत आहोत.
पीआर ब्लॉकरवर सर्वकाही चालवा एंड-टू-एंड चाचण्या सर्व SDK आवृत्त्यांवर.

तर, आम्ही अविटोमध्ये सतत एकात्मतेच्या विकासाचा इतिहास शोधला आहे. आता मला अनुभवी दृष्टिकोनातून काही सल्ला द्यायचा आहे.

टिपा

जर मी फक्त एक सल्ला देऊ शकलो तर तो असा असेल:

कृपया शेल स्क्रिप्टसह सावधगिरी बाळगा!

बॅश एक अतिशय लवचिक आणि शक्तिशाली साधन आहे, स्क्रिप्ट लिहिण्यासाठी ते अतिशय सोयीस्कर आणि जलद आहे. परंतु आपण त्याच्या सापळ्यात पडू शकता आणि दुर्दैवाने आम्ही त्यात पडलो.

हे सर्व आमच्या बिल्ड मशीनवर चालणार्‍या सोप्या स्क्रिप्टसह सुरू झाले:

#!/usr/bin/env bash
./gradlew assembleDebug

परंतु, जसे तुम्हाला माहिती आहे, सर्वकाही विकसित होते आणि कालांतराने अधिक क्लिष्ट बनते - चला एक स्क्रिप्ट दुसर्‍यावरून चालवू या, तेथे काही पॅरामीटर्स पास करूया - शेवटी आम्हाला एक फंक्शन लिहावे लागले जे ठरवते की बॅश नेस्टिंगच्या कोणत्या स्तरावर आपण आता क्रमाने आहोत. आवश्यक कोट्स घालण्यासाठी, हे सर्व सुरू करण्यासाठी.

अशा लिपींच्या विकासासाठी श्रम खर्चाची कल्पना करू शकता. मी तुम्हाला सल्ला देतो की या फंदात पडू नका.

काय बदलले जाऊ शकते?

कोणतीही स्क्रिप्टिंग भाषा. ला लिहा पायथन किंवा कोटलिन स्क्रिप्ट अधिक सोयीस्कर कारण ते प्रोग्रामिंग आहे, स्क्रिप्ट नाही.
किंवा फॉर्ममध्ये सर्व बिल्ड लॉजिकचे वर्णन करा सानुकूल ग्रेडल कार्ये तुमच्या प्रकल्पासाठी.

आम्ही दुसरा पर्याय निवडण्याचा निर्णय घेतला आणि आता आम्ही पद्धतशीरपणे सर्व बॅश स्क्रिप्ट हटवत आहोत आणि बरीच सानुकूल ग्रेडल कार्ये लिहित आहोत.

टीप #2: कोडमध्ये पायाभूत सुविधा साठवा.

जेव्हा सतत एकत्रीकरण सेटिंग जेनकिन्स किंवा टीमसिटी इत्यादींच्या UI इंटरफेसमध्ये नाही तर थेट प्रोजेक्ट रिपॉजिटरीमध्ये मजकूर फायलींच्या स्वरूपात संग्रहित केली जाते तेव्हा ते सोयीचे असते. हे आवृत्तीक्षमता देते. दुसर्‍या शाखेत कोड रोलबॅक करणे किंवा तयार करणे कठीण होणार नाही.

स्क्रिप्ट्स प्रोजेक्टमध्ये संग्रहित केल्या जाऊ शकतात. पर्यावरणाचे काय करायचे?

टीप #3: डॉकर पर्यावरणास मदत करू शकतो.

हे Android विकसकांना निश्चितपणे मदत करेल; दुर्दैवाने iOS कडे अद्याप एक नाही.

हे साध्या डॉकर फाइलचे उदाहरण आहे ज्यामध्ये jdk आणि android-sdk आहे:

FROM openjdk:8

ENV SDK_URL="https://dl.google.com/android/repository/sdk-tools-linux-3859397.zip" 
    ANDROID_HOME="/usr/local/android-sdk" 
    ANDROID_VERSION=26 
    ANDROID_BUILD_TOOLS_VERSION=26.0.2

# Download Android SDK
RUN mkdir "$ANDROID_HOME" .android 
    && cd "$ANDROID_HOME" 
    && curl -o sdk.zip $SDK_URL 
    && unzip sdk.zip 
    && rm sdk.zip 
    && yes | $ANDROID_HOME/tools/bin/sdkmanager --licenses

# Install Android Build Tool and Libraries
RUN $ANDROID_HOME/tools/bin/sdkmanager --update
RUN $ANDROID_HOME/tools/bin/sdkmanager "build-tools;${ANDROID_BUILD_TOOLS_VERSION}" 
    "platforms;android-${ANDROID_VERSION}" 
    "platform-tools"

RUN mkdir /application
WORKDIR /application

ही डॉकर फाइल लिहिल्यानंतर (मी तुम्हाला एक रहस्य सांगेन, तुम्हाला ते लिहिण्याची गरज नाही, परंतु ती फक्त GitHub वरून तयार करा) आणि प्रतिमा एकत्र केल्यावर, तुम्हाला एक आभासी मशीन मिळेल ज्यावर तुम्ही अनुप्रयोग तयार करू शकता. आणि Junit चाचण्या चालवा.

हे समजण्यामागची दोन मुख्य कारणे म्हणजे स्केलेबिलिटी आणि रिपीटेबिलिटी. डॉकर वापरून, तुम्ही त्वरीत डझनभर बिल्ड एजंट उभे करू शकता ज्यांचे वातावरण मागील सारखेच असेल. यामुळे सीआय अभियंत्यांचे जीवन खूप सोपे होते. अँड्रॉइड-एसडीकेला डॉकरमध्ये ढकलणे खूप सोपे आहे, परंतु अनुकरणकर्त्यांसह ते थोडे अधिक कठीण आहे: तुम्हाला थोडे कष्ट करावे लागतील (किंवा GitHub वरून पूर्ण झालेले पुन्हा डाउनलोड करा).

टीप क्रमांक 4: हे विसरू नका की तपासणी तपासणीसाठी केली जात नाही तर लोकांसाठी केली जाते.

जलद आणि, सर्वात महत्त्वाचे म्हणजे, स्पष्ट अभिप्राय विकसकांसाठी खूप महत्वाचे आहे: काय तोडले, कोणती चाचणी अयशस्वी झाली, मी बिल्डलॉग कुठे पाहू शकतो.

टीप #5: सतत एकात्मता विकसित करताना व्यावहारिक व्हा.

तुम्हाला कोणत्या प्रकारच्या त्रुटी टाळायच्या आहेत, तुम्ही किती संसाधने, वेळ आणि संगणक वेळ घालवण्यास तयार आहात हे स्पष्टपणे समजून घ्या. खूप वेळ घेणारे चेक, उदाहरणार्थ, रात्रभर पुढे ढकलले जाऊ शकतात. आणि त्यापैकी ज्यांना फार महत्त्वाच्या चुका सापडत नाहीत त्या पूर्णपणे सोडून दिल्या पाहिजेत.

टीप #6: तयार साधने वापरा.

आता क्लाउड सीआय प्रदान करणाऱ्या अनेक कंपन्या आहेत.

लहान संघांसाठी हा एक चांगला उपाय आहे. तुम्हाला कशाचेही समर्थन करण्याची गरज नाही, फक्त थोडे पैसे द्या, तुमचा अर्ज तयार करा आणि इन्स्ट्रुमेंटेशन चाचण्या देखील चालवा.

टीप #7: मोठ्या टीममध्ये, इन-हाऊस सोल्यूशन्स अधिक फायदेशीर असतात.

परंतु जितक्या लवकर किंवा नंतर, संघ वाढेल तसतसे घरातील उपाय अधिक फायदेशीर होतील. या निर्णयांमध्ये एक समस्या आहे. अर्थशास्त्रात परतावा कमी करण्याचा नियम आहे: कोणत्याही प्रकल्पात, प्रत्येक पुढील सुधारणा अधिकाधिक कठीण असते आणि त्यासाठी अधिकाधिक गुंतवणूक आवश्यक असते.

अर्थशास्त्र सतत एकात्मतेसह आपल्या संपूर्ण जीवनाचे वर्णन करते. मी आमच्या सतत एकात्मतेच्या विकासाच्या प्रत्येक टप्प्यासाठी श्रम खर्चाचे वेळापत्रक तयार केले.

हे स्पष्ट आहे की कोणतीही सुधारणा अधिकाधिक कठीण होत आहे. हा आलेख पाहता, तुम्ही समजू शकता की संघाच्या आकाराच्या वाढीनुसार सतत एकात्मता विकसित करणे आवश्यक आहे. दोन लोकांच्या टीमसाठी, अंतर्गत एमुलेटर फार्म विकसित करण्यासाठी 50 दिवस घालवणे ही एक सामान्य कल्पना आहे. परंतु त्याच वेळी, मोठ्या संघासाठी, सतत एकात्मता अजिबात न करणे देखील एक वाईट कल्पना आहे, कारण एकत्रीकरण समस्या, संप्रेषण निराकरण इ. यास आणखी वेळ लागेल.

आम्ही या कल्पनेने सुरुवात केली की ऑटोमेशन आवश्यक आहे कारण लोक महाग आहेत, ते चुका करतात आणि आळशी आहेत. पण लोक स्वयंचलित देखील आहेत. म्हणून, सर्व समान समस्या ऑटोमेशनवर लागू होतात.

ऑटोमेशन महाग आहे. श्रम वेळापत्रक लक्षात ठेवा.
जेव्हा ऑटोमेशन येतो तेव्हा लोक चुका करतात.
काहीवेळा ते स्वयंचलित करणे खूप आळशी आहे, कारण सर्वकाही त्या प्रकारे कार्य करते. बाकी कशात सुधारणा का, हे सगळे सतत इंटिग्रेशन का?

परंतु माझ्याकडे आकडेवारी आहे: 20% असेंब्लीमध्ये त्रुटी आढळल्या आहेत. आणि हे असे नाही कारण आमचे विकसक कोड खराब लिहितात. याचे कारण असे की विकासकांना खात्री असते की त्यांनी काही चूक केली तर ती विकसित होणार नाही, ती स्वयंचलित तपासणीद्वारे पकडली जाईल. त्यानुसार, विकासक स्थानिक पातळीवर काहीतरी चालवण्यापेक्षा आणि चाचणी करण्याऐवजी कोड आणि मनोरंजक गोष्टी लिहिण्यासाठी अधिक वेळ देऊ शकतात.

सतत एकात्मतेचा सराव करा. पण संयत.

तसे, निकोलाई नेस्टेरोव्ह स्वतःच उत्कृष्ट अहवाल देत नाही तर कार्यक्रम समितीचा सदस्य देखील आहे AppsConf आणि इतरांना तुमच्यासाठी अर्थपूर्ण भाषणे तयार करण्यात मदत करते. पुढील कॉन्फरन्स प्रोग्रामची पूर्णता आणि उपयुक्तता मधील विषयांद्वारे मूल्यांकन केले जाऊ शकते वेळापत्रक. आणि तपशीलांसाठी, 22-23 एप्रिल रोजी Infospace वर या.

स्त्रोत: www.habr.com

मोबाईल डेव्हलपमेंट टीममध्ये सीआयची उत्क्रांती