Bugungi kunda ko'pgina dasturiy mahsulotlar jamoalarda ishlab chiqilgan. Jamoani muvaffaqiyatli rivojlantirish shartlari oddiy diagramma shaklida ifodalanishi mumkin.

Kodingizni yozganingizdan so'ng, unga ishonch hosil qilishingiz kerak:

1. Rabotaet.
2. Bu hech narsani buzmaydi, shu jumladan sizning hamkasblaringiz yozgan kod.

Agar ikkala shart ham bajarilsa, siz muvaffaqiyat yo'lidasiz. Ushbu shartlarni osongina tekshirish va foydali yo'ldan chetga chiqmaslik uchun biz doimiy integratsiyani taklif qildik.

CI - bu sizning kodingizni umumiy mahsulot kodiga iloji boricha tez-tez birlashtirgan ish jarayonidir. Va siz nafaqat integratsiya, balki doimo hamma narsa ishlayotganini tekshirib turasiz. Ko'p va tez-tez tekshirishingiz kerak bo'lganligi sababli, avtomatlashtirish haqida o'ylashga arziydi. Siz hamma narsani qo'lda tekshirishingiz mumkin, lekin buni qilmasligingiz kerak va buning sababi.

• Azizlar. Har qanday dasturchining bir soatlik ishi har qanday serverning bir soatlik ishidan qimmatroq.
• Odamlar xato qiladilar. Shuning uchun, testlar noto'g'ri filialda o'tkazilganda yoki testerlar uchun noto'g'ri majburiyat tuzilganda vaziyatlar yuzaga kelishi mumkin.
• Odamlar dangasa. Vaqti-vaqti bilan bir vazifani tugatganimda, shunday fikr paydo bo'ladi: “Nima tekshiriladi? Men ikkita satr yozdim - hamma narsa ishlaydi! O'ylaymanki, ba'zilaringizda ham ba'zida shunday fikrlar paydo bo'ladi. Lekin siz doimo tekshirishingiz kerak.

Avito mobil ishlanmalar jamoasida uzluksiz integratsiya qanday amalga oshirilgan va ishlab chiqilgan, ular kuniga 0 dan 450 tagacha ishlab chiqarilgan va mashinalar kuniga 200 soat yig'iladi, deydi Nikolay Nesterov (nesterov) CI/CD Android ilovasining barcha evolyutsion oʻzgarishlarining ishtirokchisi.

Hikoya Android buyrug'i misoliga asoslangan, ammo yondashuvlarning aksariyati iOS-da ham qo'llaniladi.

Bir vaqtlar Avito Android jamoasida bir kishi ishlagan. Ta'rifga ko'ra, unga doimiy integratsiyadan hech narsa kerak emas edi: integratsiya qilish uchun hech kim yo'q edi.

Ammo dastur o'sib bordi, tobora ko'proq yangi vazifalar paydo bo'ldi va jamoa shunga mos ravishda o'sdi. Bir nuqtada, kodni integratsiya qilish jarayonini rasmiy ravishda o'rnatish vaqti keldi. Git oqimidan foydalanishga qaror qilindi.

Git oqimining kontseptsiyasi yaxshi ma'lum: loyihada bitta umumiy rivojlanish bo'limi mavjud va har bir yangi xususiyat uchun ishlab chiquvchilar alohida filialni kesib, unga amal qiladilar, surishadi va o'z kodlarini ishlab chiqish bo'limiga birlashtirmoqchi bo'lganlarida, tortish so'rovi. Bilim almashish va yondashuvlarni muhokama qilish uchun biz kodni ko'rib chiqishni joriy qildik, ya'ni hamkasblar bir-birlarining kodini tekshirishlari va tasdiqlashlari kerak.

Tekshiruvlar

Kodni ko'zlaringiz bilan ko'rish ajoyib, ammo etarli emas. Shu sababli, avtomatik tekshirishlar joriy etilmoqda.

• Birinchidan, biz tekshiramiz ARK yig'ilishi.
• Ko'p narsa Junit testlari.
• Biz kodni qamrab olishni ko'rib chiqamiz, chunki biz testlarni o'tkazmoqdamiz.

Ushbu tekshiruvlar qanday bajarilishi kerakligini tushunish uchun Avito-dagi ishlab chiqish jarayonini ko'rib chiqaylik.

U sxematik tarzda quyidagicha ifodalanishi mumkin:

• Dasturchi o'z noutbukida kod yozadi. Siz shu yerda integratsiya tekshiruvlarini o'tkazishingiz mumkin - majburiy kanca yordamida yoki shunchaki fonda tekshirishlarni amalga oshirishingiz mumkin.
• Ishlab chiquvchi kodni bosgandan so'ng, u tortish so'rovini ochadi. Uning kodi ishlab chiqish bo'limiga kiritilishi uchun kodni tekshirishdan o'tish va kerakli miqdordagi tasdiqlarni to'plash kerak. Bu yerda tekshirish va qurishni yoqishingiz mumkin: barcha tuzilmalar muvaffaqiyatli bo'lmaguncha, tortish so'rovini birlashtirib bo'lmaydi.
• Pull so'rovi birlashtirilgandan va kod ishlab chiqishga kiritilgandan so'ng, siz qulay vaqtni tanlashingiz mumkin: masalan, tunda, barcha serverlar bo'sh bo'lganda va xohlaganingizcha ko'p tekshiruvlarni o'tkazing.

Hech kim noutbukda skanerlashni yoqtirmasdi. Ishlab chiquvchi funksiyani tugatgandan so'ng, uni tezda surish va tortish so'rovini ochishni xohlaydi. Agar hozirda bir nechta uzoq tekshiruvlar boshlangan bo'lsa, bu nafaqat juda yoqimli, balki rivojlanishni sekinlashtiradi: noutbuk biror narsani tekshirayotganda, u bilan normal ishlash mumkin emas.

Bizga tunda tekshiruvlar yoqdi, chunki vaqt va serverlar ko'p, siz aylanib yurishingiz mumkin. Ammo, afsuski, xususiyat kodi ishlab chiqilgach, ishlab chiquvchi CI topgan xatolarni tuzatish uchun kamroq motivatsiyaga ega. Men vaqti-vaqti bilan ertalabki hisobotda topilgan barcha xatolarni ko'rib, ularni bir kun keyin tuzataman, deb o'ylardim, chunki endi Jirada men endigina qilishni boshlamoqchi bo'lgan ajoyib yangi vazifa bor.

Agar cheklar tortish so'rovini bloklasa, unda etarli motivatsiya mavjud, chunki tuzilmalar yashil rangga aylanmaguncha, kod ishlab chiqilmaydi, ya'ni vazifa bajarilmaydi.

Natijada, biz quyidagi strategiyani tanladik: biz tunda maksimal mumkin bo'lgan tekshiruvlar to'plamini o'tkazamiz va ulardan eng muhimlarini va eng muhimi, eng tezkorlarini tortib olish so'rovi bo'yicha ishga tushiramiz. Ammo biz bu bilan to'xtab qolmaymiz - parallel ravishda biz tekshirish tezligini optimallashtiramiz, shunda ularni tungi rejimdan so'rovni tekshirishga o'tkazamiz.

O'sha paytda bizning barcha qurilishlarimiz juda tez yakunlandi, shuning uchun biz tortishish so'rovi uchun bloker sifatida ARK qurilishi, Junit testlari va kodni qamrab olish hisoblarini kiritdik. Biz uni yoqdik, o'ylab ko'rdik va kod qamrovidan voz kechdik, chunki biz bunga muhtoj emasmiz deb o'yladik.

Asosiy CI ni to'liq o'rnatish uchun bizga ikki kun kerak bo'ldi (bundan keyin vaqt taxmini taxminiy, masshtab uchun zarur).

Shundan so'ng biz ko'proq o'ylay boshladik - biz hatto to'g'ri tekshiryapmizmi? Biz tortishish so'rovlari bo'yicha tuzilmalarni to'g'ri bajaryapmizmi?

Biz qurilishni tortib olish so'rovi ochilgan filialning oxirgi topshirig'i bo'yicha boshladik. Ammo bu majburiyatning testlari faqat ishlab chiquvchi yozgan kodning ishlashini ko'rsatishi mumkin. Lekin ular hech narsani buzmaganligini isbotlamaydilar. Aslida, xususiyat birlashtirilgandan so'ng, rivojlanish bo'limining holatini tekshirishingiz kerak.

Buning uchun biz oddiy bash skriptini yozdik premerge.sh:

#!/usr/bin/env bash

set -e

git fetch origin develop

git merge origin/develop

Bu erda rivojlanishdagi barcha so'nggi o'zgarishlar shunchaki tortib olinadi va joriy filialga birlashtiriladi. Biz premerge.sh skriptini barcha tuzilmalarda birinchi qadam sifatida qo'shdik va biz xohlagan narsani tekshira boshladik, ya'ni integratsiya.

Muammoni lokalizatsiya qilish, yechim topish va ushbu skriptni yozish uchun uch kun kerak bo'ldi.

Ilova ishlab chiqildi, tobora ko'proq vazifalar paydo bo'ldi, jamoa o'sdi va premerge.sh ba'zan bizni tushkunlikka tushira boshladi. Rivojlanishda konstruksiyani buzgan qarama-qarshi o'zgarishlar mavjud edi.

Bu qanday sodir bo'lishiga misol:

Ikki dasturchi bir vaqtning o‘zida A va B funksiyalari ustida ishlay boshlaydi. A funksiyasini ishlab chiquvchisi loyihada foydalanilmagan funksiyani topadi. answer() va, yaxshi bola skaut kabi, uni olib tashlaydi. Shu bilan birga, B xususiyatini ishlab chiquvchisi o'z filialida ushbu funktsiyaga yangi qo'ng'iroqni qo'shadi.

Ishlab chiquvchilar o'z ishlarini tugatadilar va bir vaqtning o'zida tortishish so'rovini ochadilar. Qurilishlar ishga tushirildi, premerge.sh so'nggi rivojlanish holati bo'yicha ikkala tortishish so'rovini tekshiradi - barcha tekshiruvlar yashil rangda. Shundan so'ng, A xususiyatining tortish so'rovi birlashtiriladi, B xususiyatining tortish so'rovi birlashtiriladi ... Boom! Ishlab chiqish kodi mavjud bo'lmagan funksiyaga qo'ng'iroqni o'z ichiga olganligi sababli ishlab chiqish tanaffuslari.

Qachonki u rivojlanmasa, shunday bo'ladi mahalliy falokat. Butun jamoa hech narsa to'play olmaydi va uni sinovga topshira olmaydi.

Shunday bo'ldiki, men ko'pincha infratuzilma vazifalari ustida ishladim: tahlillar, tarmoq, ma'lumotlar bazalari. Ya'ni, men boshqa ishlab chiquvchilar foydalanadigan funktsiyalar va sinflarni yozganman. Shu sababli, men shunga o'xshash vaziyatlarga tez-tez duch keldim. Menda bu rasm ham bir muddat osilgan edi.

Bu bizga mos kelmagani uchun, biz buni oldini olish bo'yicha variantlarni o'rganishni boshladik.

Qanday qilib rivojlanishni buzmaslik kerak

Birinchi variant: ishlab chiqishni yangilashda barcha tortishish so'rovlarini qayta yarating. Agar bizning misolimizda A xususiyatiga ega tortish so'rovi birinchi bo'lib ishlab chiqishga kiritilsa, B xususiyatining tortish so'rovi qayta quriladi va shunga mos ravishda kompilyatsiya xatosi tufayli tekshiruvlar muvaffaqiyatsiz bo'ladi.

Bu qancha davom etishini tushunish uchun ikkita PR bilan misolni ko'rib chiqing. Biz ikkita PR ochamiz: ikkita qurish, ikkita tekshiruv. Birinchi PR rivojlanishga birlashtirilgandan so'ng, ikkinchisini qayta qurish kerak. Hammasi bo'lib, ikkita PR uchta tekshiruvni talab qiladi: 2 + 1 = 3.

Aslida, bu yaxshi. Ammo biz statistik ma'lumotlarni ko'rib chiqdik va bizning jamoamizdagi odatiy holat 10 ta ochiq PR edi, keyin tekshiruvlar soni progressiyaning yig'indisi: 10 + 9 +... + 1 = 55. Ya'ni 10 ni qabul qilish. PR, siz 55 marta qayta qurishingiz kerak. Va bu ideal vaziyatda, barcha tekshiruvlar birinchi marta o'tganda, bu o'nlab odamlar qayta ishlanayotganda hech kim qo'shimcha tortish so'rovini ochmasa.

O'zingizni "birlashtirish" tugmasini birinchi bo'lib bosishi kerak bo'lgan ishlab chiquvchi sifatida tasavvur qiling, chunki qo'shningiz buni qilsa, siz barcha tuzilmalar qaytadan o'tguncha kutishingiz kerak bo'ladi... Yo'q, bu ishlamaydi. , bu rivojlanishni jiddiy ravishda sekinlashtiradi.

Ikkinchi mumkin bo'lgan usul: kodni ko'rib chiqqandan so'ng tortib olish so'rovlarini to'plash. Ya'ni, siz tortishish so'rovini ochasiz, hamkasblardan kerakli miqdordagi tasdiqlarni to'playsiz, kerakli narsani tuzatasiz va keyin tuzilmalarni ishga tushirasiz. Agar ular muvaffaqiyatli bo'lsa, tortish so'rovi ishlab chiqishga birlashtiriladi. Bunday holda, qo'shimcha qayta ishga tushirishlar yo'q, lekin fikr-mulohazalar juda sekinlashadi. Ishlab chiquvchi sifatida, men tortishish so'rovini ochganimda, men darhol uning ishlashini ko'rishni xohlayman. Misol uchun, agar test muvaffaqiyatsiz bo'lsa, uni tezda tuzatishingiz kerak. Kechiktirilgan qurilish bo'lsa, fikr-mulohazalar sekinlashadi va shuning uchun butun rivojlanish. Bu bizga ham mos kelmadi.

Natijada, faqat uchinchi variant qoldi - velosiped. Bizning barcha kodlarimiz, barcha manbalarimiz Bitbucket serveridagi omborda saqlanadi. Shunga ko'ra, biz Bitbucket uchun plaginni ishlab chiqishimiz kerak edi.

Ushbu plagin tortishish so'rovini birlashtirish mexanizmini bekor qiladi. Boshlanish standartdir: PR ochiladi, barcha yig'ilishlar ishga tushiriladi, kodni ko'rib chiqish tugallanadi. Ammo kodni ko'rib chiqish tugallangandan so'ng va ishlab chiquvchi "birlashtirish" tugmasini bosishga qaror qilgandan so'ng, plagin qaysi rivojlanish holati bo'yicha tekshiruvlar o'tkazilganligini tekshiradi. Agar dastur tuzilishdan keyin yangilangan bo'lsa, plagin bunday tortish so'rovini asosiy filialga birlashtirishga ruxsat bermaydi. Bu nisbatan yaqinda ishlab chiqilgan qurilishlarni qayta ishga tushiradi.

Qarama-qarshi o'zgarishlar bilan bizning misolimizda bunday tuzilmalar kompilyatsiya xatosi tufayli muvaffaqiyatsiz bo'ladi. Shunga ko'ra, B xususiyatini ishlab chiquvchi kodni tuzatishi, tekshiruvlarni qayta boshlashi kerak, keyin plagin avtomatik ravishda tortish so'rovini qo'llaydi.

Ushbu plaginni amalga oshirishdan oldin biz har bir tortishish so'roviga o'rtacha 2,7 ta ko'rib chiqishni o'tkazdik. Plagin bilan 3,6 ta ishga tushirildi. Bu bizga mos edi.

Shuni ta'kidlash kerakki, ushbu plaginning kamchiligi bor: u faqat bir marta qurishni qayta ishga tushiradi. Ya'ni, qarama-qarshi o'zgarishlar rivojlanishi mumkin bo'lgan kichik oyna hali ham mavjud. Ammo buning ehtimoli past va biz bu startlar soni va muvaffaqiyatsizlik ehtimoli o'rtasida kelishuvni amalga oshirdik. Ikki yil ichida u faqat bir marta o'q uzdi, shuning uchun bu behuda emas edi.

Bitbucket plaginining birinchi versiyasini yozish uchun bizga ikki hafta vaqt ketdi.

Yangi cheklar

Ayni paytda jamoamiz o'sishda davom etdi. Yangi cheklar qo'shildi.

Biz o'yladik: agar ularni oldini olish mumkin bo'lsa, nima uchun xato qilish kerak? Va shuning uchun ular amalga oshirildi statik kod tahlili. Biz Android SDK-ga kiritilgan lintdan boshladik. Ammo o'sha paytda u Kotlin kodi bilan qanday ishlashni umuman bilmas edi va bizda allaqachon dasturning 75 foizi Kotlinda yozilgan edi. Shuning uchun, lintga o'rnatilganlar qo'shildi Android Studio tekshiruvi.

Buning uchun biz juda ko'p buzuqlik qilishimiz kerak edi: Android Studio-ni oling, uni Docker-ga joylashtiring va virtual monitor bilan CI-da ishga tushiring, shunda u haqiqiy noutbukda ishlayapti deb o'ylaydi. Lekin u ishladi.

Aynan shu davrda biz ko'p yozishni boshladik asboblar sinovlari va amalga oshirildi skrinshot sinovi. Bu alohida kichik ko'rinish uchun mos yozuvlar skrinshoti yaratilganda va test ko'rinishdan skrinshot olish va uni standart to'g'ridan-to'g'ri piksel piksel bilan solishtirishdan iborat. Agar nomuvofiqlik bo'lsa, bu tartib qaerdadir noto'g'ri ketgan yoki uslublarda biror narsa noto'g'ri ekanligini anglatadi.

Ammo asboblar testlari va skrinshot sinovlari qurilmalarda bajarilishi kerak: emulyatorlarda yoki haqiqiy qurilmalarda. Ko'p sinovlar borligini va ular tez-tez o'tkazilishini hisobga olsak, butun bir ferma kerak. O'z fermangizni ochish juda ko'p mehnat talab qiladi, shuning uchun biz tayyor variantni topdik - Firebase Test Lab.

Firebase sinov laboratoriyasi

Bu tanlandi, chunki Firebase Google mahsulotidir, ya'ni u ishonchli bo'lishi va hech qachon o'lmasligi kerak. Narxlar o'rtacha: haqiqiy qurilmaning soatiga 5 dollar, emulyatorning soatiga 1 dollar.

Firebase Test Laboratoriyasini CI-ga joriy qilish uchun taxminan uch hafta vaqt ketdi.

Ammo jamoa o'sishda davom etdi va Firebase, afsuski, bizni tushkunlikka sola boshladi. O'sha paytda u hech qanday SLAga ega emas edi. Ba'zida Firebase bizni sinovlar uchun kerakli miqdordagi qurilmalar bo'sh bo'lguncha kutishga majbur qildi va biz xohlagancha ularni darhol ishga tushirishni boshlamadi. Navbatda kutish yarim soatgacha davom etdi, bu juda uzoq vaqt. Har bir PR bo'yicha asbob-uskunalar sinovlari o'tkazildi, kechikishlar haqiqatan ham rivojlanishni sekinlashtirdi, keyin oylik hisob dumaloq summa bilan keldi. Umuman olganda, Firebase-dan voz kechib, uyda ishlashga qaror qilindi, chunki jamoa etarlicha o'sgan.

Docker + Python + bash

Biz Docker-ni oldik, unga emulyatorlarni to'ldirdik, Python-da oddiy dastur yozdik, u kerakli vaqtda kerakli versiyada kerakli miqdordagi emulyatorlarni keltirib chiqaradi va kerak bo'lganda ularni to'xtatadi. Va, albatta, bir nechta bash skriptlari - ularsiz qayerda bo'lar edik?

O'z sinov muhitimizni yaratish uchun besh hafta kerak bo'ldi.

Natijada, har bir tortib olish so'rovi uchun keng qamrovli birlashtirishni blokirovka qiluvchi tekshiruvlar ro'yxati mavjud edi:

• ARK yig'ilishi;
• Junit testlari;
• tuklar;
• Android Studio tekshiruvlari;
• Asboblar sinovlari;
• Skrinshot sinovlari.

Bu ko'plab mumkin bo'lgan buzilishlarning oldini oldi. Texnik jihatdan hamma narsa ishladi, ammo ishlab chiquvchilar natijalarni kutish juda uzoq bo'lganidan shikoyat qilishdi.

Qancha vaqt juda uzun? Biz Bitbucket va TeamCity-dan ma'lumotlarni tahlil tizimiga yukladik va buni angladik o'rtacha kutish vaqti 45 daqiqa. Ya'ni, dasturchi tortib olish so'rovini ochganda, qurish natijalarini o'rtacha 45 daqiqa kutadi. Menimcha, bu juda ko'p va siz bunday ishlay olmaysiz.

Albatta, biz barcha qurilishlarimizni tezlashtirishga qaror qildik.

Tezlashaylik

Qurilishlar ko'pincha navbatda turishini ko'rib, biz qiladigan birinchi narsa ko'proq apparat sotib oldi — ekstensiv rivojlanish eng oddiy hisoblanadi. Qurilishlar navbatda turishni to'xtatdi, ammo kutish vaqti biroz qisqardi, chunki ba'zi tekshiruvlar juda uzoq davom etdi.

Juda uzoq davom etadigan cheklarni olib tashlash

Bizning uzluksiz integratsiyamiz bunday turdagi xato va muammolarni bartaraf etishi mumkin.

• Bormaydi. Qarama-qarshi o'zgarishlar tufayli biror narsa tuzilmasa, CI kompilyatsiya xatosini olishi mumkin. Yuqorida aytganimdek, hech kim hech narsani yig'a olmaydi, rivojlanish to'xtaydi va hamma asabiylashadi.
• Xulq-atvordagi xato. Misol uchun, dastur qurilganda, lekin tugmani bosganingizda ishlamay qoladi yoki tugma umuman bosilmaydi. Bu yomon, chunki bunday xato foydalanuvchiga etib borishi mumkin.
• Tartibdagi xato. Misol uchun, tugma bosilgan, lekin 10 piksel chapga siljigan.
• Texnik qarzning oshishi.

Ushbu ro'yxatni ko'rib chiqqandan so'ng, biz faqat birinchi ikkita nuqta muhim ekanligini tushundik. Biz birinchi navbatda bunday muammolarni hal qilmoqchimiz. Tartibdagi xatolar dizaynni ko'rib chiqish bosqichida topiladi va keyin osongina tuzatilishi mumkin. Texnik qarz bilan shug'ullanish alohida jarayon va rejalashtirishni talab qiladi, shuning uchun biz uni tortib olish so'rovida sinab ko'rmaslikka qaror qildik.

Ushbu tasnifga asoslanib, biz cheklarning butun ro'yxatini silkitdik. Chizilgan Lint va uni ishga tushirishni bir kechaga qoldirdi: shunchaki loyihada qancha muammolar borligi haqida hisobot tayyorlab berishi uchun. Biz texnik qarz bilan alohida ishlashga kelishib oldik va Android Studio tekshiruvlaridan butunlay voz kechildi. Tekshirishlarni amalga oshirish uchun Docker-dagi Android Studio qiziqarli ko'rinadi, ammo qo'llab-quvvatlashda juda ko'p muammolarni keltirib chiqaradi. Android Studio versiyalarining har qanday yangilanishi tushunarsiz xatolar bilan kurashishni anglatadi. Skrinshot sinovlarini qo'llab-quvvatlash ham qiyin edi, chunki kutubxona unchalik barqaror emas edi va noto'g'ri pozitivlar mavjud edi. Skrinshot sinovlari tekshiruv roʻyxatidan olib tashlandi.

Natijada, biz qoldik:

• ARK yig'ilishi;
• Junit testlari;
• Instrumental sinovlar.

Gradle masofaviy kesh

Og'ir tekshiruvlarsiz hamma narsa yaxshilandi. Ammo mukammallikning chegarasi yo'q!

Bizning ilovamiz allaqachon taxminan 150 gradus moduliga bo'lingan. Gradle masofaviy keshi odatda bu holatda yaxshi ishlaydi, shuning uchun biz uni sinab ko'rishga qaror qildik.

Gradle masofaviy kesh - bu alohida modullardagi individual vazifalar uchun qurilish artefaktlarini keshlashi mumkin bo'lgan xizmat. Gradle, aslida kodni kompilyatsiya qilish o'rniga, masofaviy keshni taqillatish va kimdir bu vazifani bajarganligini so'rash uchun HTTP-dan foydalanadi. Ha bo'lsa, u shunchaki natijani yuklab oladi.

Gradle masofaviy keshini ishga tushirish oson, chunki Gradle Docker tasvirini taqdim etadi. Biz buni uch soat ichida uddaladik.

Siz qilishingiz kerak bo'lgan yagona narsa Docker-ni ishga tushirish va loyihaga bitta qator yozish edi. Ammo uni tezda ishga tushirish mumkin bo'lsa-da, hamma narsa yaxshi ishlashi uchun juda ko'p vaqt kerak bo'ladi.

Quyida kesh o'tkazib yuborilgan grafik.

Eng boshida kesh o'tkazib yuborish foizi taxminan 65 edi. Uch haftadan so'ng biz bu qiymatni 20% ga oshirishga muvaffaq bo'ldik. Ma'lum bo'lishicha, Android ilovasi to'playdigan vazifalar g'alati tranzitiv bog'liqliklarga ega, shuning uchun Gradle keshni o'tkazib yuborgan.

Keshni ulash orqali biz qurilishni sezilarli darajada tezlashtirdik. Ammo montajdan tashqari, asbob-uskunalar sinovlari ham mavjud va ular uzoq vaqt talab etadi. Ehtimol, har bir tortishish so'rovi uchun barcha testlarni o'tkazish kerak emas. Buni bilish uchun biz ta'sir tahlilidan foydalanamiz.

Ta'sir tahlili

Pull so'rovida biz git diff ni yig'amiz va o'zgartirilgan Gradle modullarini topamiz.

Faqat o'zgartirilgan modullarni va ularga bog'liq bo'lgan barcha modullarni tekshiradigan asbob-uskunalar testlarini o'tkazish mantiqan. Qo'shni modullar uchun testlarni o'tkazishning ma'nosi yo'q: u erda kod o'zgarmagan va hech narsa buzilmaydi.

Asboblar sinovlari unchalik oddiy emas, chunki ular yuqori darajadagi Ilova modulida joylashgan bo'lishi kerak. Har bir test qaysi modulga tegishli ekanligini tushunish uchun bayt-kod tahlili bilan evristikadan foydalandik.

Asboblar sinovlarining ishlashini yangilash, ular faqat ishtirok etgan modullarni sinab ko'rish uchun taxminan sakkiz hafta davom etdi.

Tekshiruvlarni jadallashtirish chora-tadbirlari o‘z samarasini berdi. 45 daqiqadan boshlab biz taxminan 15 ga chiqdik. Qurilish uchun chorak soat kutish odatiy holdir.

Ammo endi ishlab chiquvchilar qaysi tuzilmalar ishga tushirilayotganini, jurnalni qayerda ko'rishni, nima uchun qurish qizil ekanligini, qaysi sinov muvaffaqiyatsiz tugashini va hokazolarni tushunmasliklari haqida shikoyat qila boshladilar.

Fikr-mulohaza bilan bog'liq muammolar rivojlanishni sekinlashtiradi, shuning uchun biz har bir PR va qurilish haqida eng aniq va batafsil ma'lumot berishga harakat qildik. Biz Bitbucket-dagi PR-ga sharhlar bilan boshladik, qaysi tuzilish muvaffaqiyatsiz bo'lganini va nima uchun ekanligini ko'rsatib, Slack-da maqsadli xabarlarni yozdik. Oxir-oqibat, biz hozirda ishlayotgan barcha tuzilmalar ro'yxati va ularning holati: navbatda turgan, ishlayotgan, ishdan chiqqan yoki tugallangan sahifa uchun PR boshqaruv panelini yaratdik. Qurilish ustiga bosing va uning jurnaliga kirishingiz mumkin.

Olti hafta batafsil fikr-mulohazalarga sarflandi.

rejalari

Keling, yaqin tarixga o'tamiz. Fikr-mulohaza muammosini hal qilib, biz yangi bosqichga chiqdik - biz o'z emulyator fermamizni qurishga qaror qildik. Ko'p testlar va emulyatorlar mavjud bo'lganda, ularni boshqarish qiyin. Natijada, bizning barcha emulyatorlarimiz moslashuvchan resurslarni boshqarish bilan k8s klasteriga o'tdi.

Bundan tashqari, boshqa rejalar ham bor.

• Lintni qaytaring (va boshqa statik tahlillar). Biz allaqachon bu yo'nalishda ishlamoqdamiz.
• Hamma narsani PR blokerda ishga tushiring oxirigacha sinovlar barcha SDK versiyalarida.

Shunday qilib, biz Avitoda uzluksiz integratsiyaning rivojlanish tarixini kuzatdik. Endi men tajribali nuqtai nazardan bir nechta maslahat bermoqchiman.

Maslahatlar

Agar men bitta maslahat bera olsam, bu shunday bo'lar edi:

Iltimos, qobiq skriptlari bilan ehtiyot bo'ling!

Bash juda moslashuvchan va kuchli vosita bo'lib, skriptlarni yozish uchun juda qulay va tezdir. Ammo siz u bilan tuzoqqa tushib qolishingiz mumkin va afsuski, biz unga tushib qoldik.

Hammasi bizning qurilish mashinalarimizda ishlaydigan oddiy skriptlar bilan boshlandi:

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

Ammo, siz bilganingizdek, vaqt o'tishi bilan hamma narsa rivojlanadi va murakkablashadi - keling, bitta skriptni boshqasidan ishga tushiramiz, ba'zi parametrlarni u erga o'tkazamiz - oxirida biz bash joylashtirishning qaysi darajasida ekanligimizni aniqlaydigan funktsiyani yozishimiz kerak edi. kerakli tirnoqlarni kiritish, hammasini boshlash uchun.

Bunday skriptlarni ishlab chiqish uchun mehnat xarajatlarini tasavvur qilishingiz mumkin. Men sizga bu tuzoqqa tushmaslikni maslahat beraman.

Nimani almashtirish mumkin?

• Har qanday skript tili. ga yozing Python yoki Kotlin skripti qulayroq, chunki u skriptlar emas, balki dasturlash.
• Yoki shakldagi barcha qurish mantiqini tasvirlab bering Maxsus gradus vazifalari loyihangiz uchun.

Biz ikkinchi variantni tanlashga qaror qildik va endi biz barcha bash skriptlarini muntazam ravishda o'chirib tashlayapmiz va ko'plab maxsus gradusli vazifalarni yozyapmiz.

Maslahat №2: Infratuzilmani kodda saqlang.

Doimiy integratsiya sozlamalari Jenkins yoki TeamCity va boshqalarning UI interfeysida emas, balki to'g'ridan-to'g'ri loyiha omborida matnli fayllar ko'rinishida saqlanganida qulaydir. Bu versiyani beradi. Qayta tiklash yoki boshqa filialda kodni yaratish qiyin bo'lmaydi.

Skriptlar loyihada saqlanishi mumkin. Atrof-muhit bilan nima qilish kerak?

Maslahat №3: Docker atrof-muhitga yordam berishi mumkin.

Bu, albatta, Android dasturchilariga yordam beradi; afsuski, iOS-da hali yo'q.

Bu jdk va android-sdk ni o'z ichiga olgan oddiy docker fayliga misol:

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

Ushbu Docker faylini yozganingizdan so'ng (sizga sirni aytaman, uni yozishingiz shart emas, uni GitHub'dan tayyor holda tortib oling) va tasvirni yig'ib, siz dasturni yaratishingiz mumkin bo'lgan virtual mashinaga ega bo'lasiz. va Junit testlarini ishga tushiring.

Buning mantiqiy bo'lishining ikkita asosiy sababi - kengaytirilishi va takrorlanuvchanligi. Docker-dan foydalanib, siz oldingisi bilan bir xil muhitga ega bo'lgan o'nlab quruvchi agentlarni tezda yuklashingiz mumkin. Bu CI muhandislarining hayotini ancha osonlashtiradi. Android-sdk-ni docker-ga surish juda oson, ammo emulyatorlar bilan bu biroz qiyinroq: siz biroz ko'proq ishlashingiz kerak bo'ladi (yoki tayyorni GitHub-dan yana yuklab oling).

Maslahat No4: tekshirishlar tekshirish uchun emas, balki odamlar uchun amalga oshirilishini unutmang.

Tez va eng muhimi, aniq fikr-mulohazalar ishlab chiquvchilar uchun juda muhim: nima buzildi, qanday sinov muvaffaqiyatsiz tugadi, qurilish jurnalini qayerda ko'rishim mumkin.

Maslahat №5: Uzluksiz integratsiyani ishlab chiqishda pragmatik bo'ling.

Qanday turdagi xatolar oldini olishni xohlayotganingizni, qancha resurslar, vaqt va kompyuter vaqtini sarflashga tayyor ekanligingizni aniq tushunib oling. Juda uzoq davom etadigan tekshiruvlar, masalan, bir kechada qoldirilishi mumkin. Va unchalik muhim bo'lmagan xatolarga yo'l qo'yadiganlardan butunlay voz kechish kerak.

Maslahat №6: Tayyor vositalardan foydalaning.

Hozirda bulutli CIni ta'minlovchi ko'plab kompaniyalar mavjud.

Bu kichik jamoalar uchun yaxshi yechim. Hech narsani qo'llab-quvvatlashingiz shart emas, shunchaki ozgina pul to'lang, ilovangizni yarating va hatto asbob sinovlarini o'tkazing.

Maslahat №7: Katta jamoada ichki echimlar foydaliroq.

Ammo ertami-kechmi, jamoa o'sishi bilan, ichki echimlar yanada foydali bo'ladi. Bu qarorlarda bitta muammo bor. Iqtisodiyotda rentabellikning kamayishi qonuni mavjud: har qanday loyihada har bir keyingi takomillashtirish tobora qiyinlashadi va ko'proq va ko'proq investitsiyalarni talab qiladi.

Iqtisodiyot bizning butun hayotimizni, shu jumladan Uzluksiz integratsiyani tasvirlaydi. Men uzluksiz integratsiyamiz rivojlanishining har bir bosqichi uchun mehnat xarajatlari jadvalini tuzdim.

Har qanday yaxshilanish tobora qiyinlashib borayotgani aniq. Ushbu grafikga qarab, siz uzluksiz integratsiyani jamoa hajmining o'sishiga mos ravishda ishlab chiqish kerakligini tushunishingiz mumkin. Ikki kishidan iborat jamoa uchun ichki emulyator fermasini ishlab chiqish uchun 50 kun sarflash o'rtacha g'oyadir. Ammo shu bilan birga, katta jamoa uchun Uzluksiz integratsiyani umuman qilmaslik ham yomon fikr, chunki integratsiya muammolari, aloqani tuzatish va h.k. bundan ham ko'proq vaqt talab etadi.

Biz avtomatlashtirish zarur, chunki odamlar qimmat, xato qiladi va dangasalik qiladi degan fikrdan boshladik. Lekin odamlar ham avtomatlashadi. Shuning uchun barcha bir xil muammolar avtomatlashtirishga tegishli.

• Avtomatlashtirish qimmat. Mehnat jadvalini eslang.
• Avtomatlashtirish haqida gap ketganda, odamlar xato qiladilar.
• Ba'zan avtomatlashtirish juda dangasa, chunki hamma narsa shunday ishlaydi. Nima uchun boshqa narsani yaxshilash kerak, nima uchun bu doimiy integratsiya?

Ammo menda statistika bor: xatolar yig'ilishlarning 20 foizida uchraydi. Va bu bizning ishlab chiquvchilarimiz kodni yomon yozganlari uchun emas. Buning sababi shundaki, ishlab chiquvchilar, agar ular biron bir xatoga yo'l qo'ysa, u rivojlanishda qolmasligiga, avtomatlashtirilgan tekshiruvlar orqali ushlanishiga ishonchi komil. Shunga ko'ra, ishlab chiquvchilar mahalliy ravishda biror narsani ishga tushirish va sinab ko'rishdan ko'ra, kod va qiziqarli narsalarni yozish uchun ko'proq vaqt sarflashlari mumkin.

Uzluksiz integratsiyani mashq qiling. Ammo me'yorida.

Aytgancha, Nikolay Nesterov nafaqat o'zi ajoyib hisobotlar beradi, balki dastur qo'mitasining a'zosi hamdir. AppsConf va boshqalarga siz uchun mazmunli nutqlar tayyorlashga yordam beradi. Keyingi konferentsiya dasturining to'liqligi va foydaliligini mavzular bo'yicha baholash mumkin jadval. Tafsilotlar uchun 22-23 aprel kunlari Infospace’ga keling.

Manba: www.habr.com