Bu gün əksər proqram məhsulları komandalar şəklində hazırlanır. Komandanın uğurlu inkişafı üçün şərtlər sadə diaqram şəklində təqdim edilə bilər.

Kodunuzu yazdıqdan sonra ona əmin olmalısınız:

1. İşləyir.
2. Həmkarlarınızın yazdığı kod daxil olmaqla, heç bir şeyi pozmur.

Əgər hər iki şərt yerinə yetirilirsə, deməli, uğura gedən yoldasınız. Bu şərtləri asanlıqla yoxlamaq və sərfəli yoldan sapmamaq üçün biz Davamlı İnteqrasiya ilə gəldik.

CI kodunuzu mümkün qədər tez-tez ümumi məhsul koduna inteqrasiya etdiyiniz iş axınıdır. Siz yalnız inteqrasiya etmirsiniz, həm də hər şeyin işlədiyini daim yoxlayın. Çox və tez-tez yoxlamaq lazım olduğundan, avtomatlaşdırma haqqında düşünməyə dəyər. Hər şeyi əl ilə yoxlaya bilərsiniz, amma etməməlisiniz və bunun səbəbi budur.

• Əziz insanlar. İstənilən proqramçının bir saatlıq işi istənilən serverin bir saatlıq işindən baha başa gəlir.
• İnsanlar səhv edirlər. Buna görə də, testlər səhv filialda aparıldıqda və ya testçilər üçün səhv öhdəlik tərtib edildikdə vəziyyətlər yarana bilər.
• İnsanlar tənbəldir. Hərdən bir işi bitirəndə belə fikir yaranır: “Yoxlamalı nə var? İki sətir yazdım - hər şey işləyir! Düşünürəm ki, sizin bəziləriniz də bəzən belə fikirlərə düşür. Ancaq həmişə yoxlamaq lazımdır.

Avito mobil inkişaf komandasında Davamlı İnteqrasiya necə həyata keçirildi və inkişaf etdirildi, onlar gündə 0-dan 450-yə qədər quruldu və maşınlar gündə 200 saat yığılır, Nikolay Nesterov deyir (nesterov) CI/CD Android tətbiqinin bütün təkamül dəyişikliklərinin iştirakçısıdır.

Hekayə Android əmrinin nümunəsinə əsaslanır, lakin yanaşmaların əksəriyyəti iOS-da da tətbiq olunur.

Bir vaxtlar Avito Android komandasında bir nəfər işləyirdi. Tərifinə görə, onun Davamlı İnteqrasiyadan heç nəyə ehtiyacı yox idi: inteqrasiya olunacaq heç kim yox idi.

Ancaq tətbiq böyüdü, getdikcə daha çox yeni vəzifələr ortaya çıxdı və komanda buna uyğun olaraq böyüdü. Müəyyən bir nöqtədə kod inteqrasiyası prosesini daha rəsmi şəkildə qurmağın vaxtı gəldi. Git axınından istifadə etmək qərara alındı.

Git axınının konsepsiyası yaxşı məlumdur: layihənin bir ümumi inkişaf şöbəsi var və hər bir yeni xüsusiyyət üçün tərtibatçılar ayrıca bir filialı kəsir, ona öhdəlik götürür, itələyir və kodlarını inkişaf filialına birləşdirmək istədikdə, çəkmə tələbi. Bilikləri bölüşmək və yanaşmaları müzakirə etmək üçün biz kodun nəzərdən keçirilməsini təqdim etdik, yəni həmkarlar bir-birlərinin kodunu yoxlamalı və təsdiq etməlidirlər.

Çeklər

Kodları gözlərinizlə görmək gözəldir, lakin kifayət deyil. Buna görə də avtomatik yoxlamalar tətbiq edilir.

• Əvvəlcə yoxlayırıq ARK montajı.
• Bir çox şey Junit testləri.
• Kod əhatəsini nəzərdən keçiririk, çünki biz testlər keçiririk.

Bu yoxlamaların necə aparılacağını başa düşmək üçün Avito-da inkişaf prosesinə baxaq.

Sxematik olaraq belə təqdim edilə bilər:

• Tərtibatçı öz laptopunda kod yazır. İnteqrasiya yoxlamalarını burada keçirə bilərsiniz - ya öhdəçilik çəngəl ilə, ya da sadəcə arxa planda yoxlama apara bilərsiniz.
• Tərtibatçı kodu itələdikdən sonra çəkmə sorğusu açır. Onun kodunun inkişaf şöbəsinə daxil olması üçün kodun nəzərdən keçirilməsindən keçmək və lazımi sayda təsdiq toplamaq lazımdır. Siz burada yoxlamaları və qurmaları aktivləşdirə bilərsiniz: bütün quruluşlar uğurlu olana qədər çəkmə sorğusu birləşdirilə bilməz.
• Çəkmə sorğusu birləşdirildikdən və kod inkişafa daxil edildikdən sonra rahat vaxt seçə bilərsiniz: məsələn, gecə, bütün serverlər boş olduqda və istədiyiniz qədər yoxlama aparın.

Heç kim laptopunda skan etməyi xoşlamırdı. Tərtibatçı funksiyanı bitirdikdən sonra onu tez bir zamanda itələmək və çəkmə sorğusu açmaq istəyir. Bu anda bəzi uzun yoxlamalar işə salınarsa, bu, nəinki çox xoş deyil, həm də inkişafı ləngidir: laptop bir şeyi yoxlayarkən, onun üzərində normal işləmək mümkün deyil.

Gecələr yoxlama aparmağı çox xoşladıq, çünki çox vaxt və serverlər var, siz gəzə bilərsiniz. Ancaq təəssüf ki, xüsusiyyət kodu inkişaf etdirilməyə başlayanda, tərtibatçının CI-nin tapdığı səhvləri düzəltmək üçün daha az motivasiyası var. Səhər hesabatında tapılan bütün səhvlərə baxanda vaxtaşırı özümü düşünürdüm ki, onları nə vaxtsa sonra düzəldəcəyəm, çünki indi Jira-da sadəcə etməyə başlamaq istədiyim gözəl yeni bir tapşırıq var.

Çeklər çəkmə sorğusunu bloklayırsa, o zaman kifayət qədər motivasiya var, çünki quruluşlar yaşıllaşana qədər kod inkişafa daxil olmayacaq, yəni tapşırıq tamamlanmayacaq.

Nəticədə, biz aşağıdakı strategiyanı seçdik: gecələr mümkün olan maksimum yoxlama dəstini həyata keçiririk və onların ən kritikini və ən əsası, ən sürətli olanları çəkmə sorğusu ilə işə salırıq. Lakin biz bununla kifayətlənmirik - paralel olaraq, biz yoxlamaların sürətini optimallaşdırırıq ki, onları gecə rejimindən sorğu çeklərini çəkmək üçün köçürək.

O zaman, bütün quruluşlarımız olduqca tez tamamlandı, ona görə də biz sadəcə olaraq ARK quruluşunu, Junit testlərini və kodu əhatə etmə hesablamalarını çəkmə sorğusu üçün bloker kimi daxil etdik. Biz onu yandırdıq, bu barədə düşündük və kodun əhatə dairəsini tərk etdik, çünki buna ehtiyacımız olmadığını düşündük.

Əsas CI-ni tam qurmaq bizə iki gün çəkdi (bundan sonra vaxt təxmini təxminidir, miqyas üçün lazımdır).

Bundan sonra biz daha çox düşünməyə başladıq - hətta düzgün yoxlayırıqmı? Çəkmə sorğuları üzərində qurulma işlərini düzgün icra edirikmi?

Biz çəkmə sorğusunun açıldığı filialın son öhdəliyindən qurmağa başladıq. Lakin bu öhdəliyin sınaqları yalnız tərtibatçının yazdığı kodun işlədiyini göstərə bilər. Amma heç nəyi sındırmadığını sübut etmirlər. Əslində, bir xüsusiyyət birləşdirildikdən sonra inkişaf filialının vəziyyətini yoxlamaq lazımdır.

Bunun üçün sadə bir bash skripti yazdıq premerge.sh:

#!/usr/bin/env bash

set -e

git fetch origin develop

git merge origin/develop

Burada inkişafdan olan bütün son dəyişikliklər sadəcə yuxarıya çəkilir və mövcud filiala birləşdirilir. Bütün quruluşlarda ilk addım olaraq premerge.sh skriptini əlavə etdik və tam olaraq nə istədiyimizi yoxlamağa başladıq, yəni. inteqrasiya.

Problemi lokallaşdırmaq, həllini tapmaq və bu ssenarini yazmaq üç gün çəkdi.

Tətbiq inkişaf etdirildi, getdikcə daha çox tapşırıq ortaya çıxdı, komanda böyüdü və premerge.sh bəzən bizi ruhdan salmağa başladı. Devel-də quruluşu pozan ziddiyyətli dəyişikliklər oldu.

Bunun necə baş verdiyinə bir nümunə:

İki tərtibatçı eyni vaxtda A və B funksiyaları üzərində işləməyə başlayır. A funksiyasının tərtibçisi layihədə istifadə olunmamış funksiyanı aşkar edir. answer() və yaxşı oğlan kəşfiyyatçısı kimi onu aradan qaldırır. Eyni zamanda, B funksiyasının tərtibçisi öz filialında bu funksiyaya yeni zəng əlavə edir.

Tərtibatçılar işlərini bitirir və eyni zamanda çəkmə sorğusu açır. Quraşdırmalar işə salındı, premerge.sh son inkişaf vəziyyəti ilə bağlı hər iki çəkmə sorğusunu yoxlayır - bütün yoxlamalar yaşıl rəngdədir. Bundan sonra A funksiyasının çəkmə sorğusu birləşdirilir, B funksiyasının çəkmə sorğusu birləşdirilir... Boom! İnkişaf kodunda mövcud olmayan funksiyaya çağırış olduğu üçün inkişaf fasilələri var.

İnkişaf etməyəcəksə, o yerli fəlakət. Bütün komanda heç nə toplayıb sınaq üçün təqdim edə bilməz.

Elə oldu ki, mən ən çox infrastruktur tapşırıqları üzərində işləyirdim: analitika, şəbəkə, verilənlər bazası. Yəni, digər tərtibatçıların istifadə etdiyi o funksiyaları və sinifləri yazan mən olmuşam. Buna görə də tez-tez özümü oxşar vəziyyətlərdə tapdım. Hətta bir müddət bu şəkli asdım.

Bu bizə uyğun gəlmədiyi üçün bunun qarşısını almaq üçün variantları araşdırmağa başladıq.

İnkişafı necə pozmamaq olar

İlk seçim: inkişafı yeniləyərkən bütün çəkmə sorğularını yenidən qurun. Əgər bizim nümunəmizdə A xüsusiyyəti olan çəkmə sorğusu inkişafa ilk daxil edilirsə, B xüsusiyyətinin çəkmə sorğusu yenidən qurulacaq və müvafiq olaraq, tərtib etmə xətası səbəbindən yoxlamalar uğursuz olacaq.

Bunun nə qədər vaxt aparacağını başa düşmək üçün iki PR ilə bir nümunə nəzərdən keçirin. İki PR açırıq: iki qurma, iki yoxlama. Birinci PR inkişafa birləşdirildikdən sonra ikincisini yenidən qurmaq lazımdır. Ümumilikdə, iki PR üç yoxlama dövrünü tələb edir: 2 + 1 = 3.

Prinsipcə, yaxşıdır. Amma biz statistikaya baxdıq və komandamızda tipik vəziyyət 10 açıq PR idi, sonra yoxlamaların sayı irəliləyişin cəmidir: 10 + 9 +... + 1 = 55. Yəni 10-u qəbul etmək. PR, 55 dəfə yenidən qurmaq lazımdır. Və bu ideal vəziyyətdədir, bütün yoxlamalar ilk dəfə keçdikdə, bu onlarla işlənərkən heç kim əlavə çəkmə sorğusu açmadıqda.

Özünüzü “birləşdirmə” düyməsini ilk klikləməli olan bir tərtibatçı kimi təsəvvür edin, çünki qonşu bunu edərsə, onda siz bütün quruluşların yenidən keçməsini gözləməli olacaqsınız... Xeyr, bu işləməyəcək. , inkişafı ciddi şəkildə yavaşlatacaq.

İkinci mümkün yol: kodu nəzərdən keçirdikdən sonra çəkmə sorğularını toplayın. Yəni, siz çəkmə sorğusunu açırsınız, həmkarlarınızdan lazımi sayda təsdiq toplayır, lazım olanı düzəldirsiniz və sonra quruluşları işə salın. Əgər onlar uğurlu olarsa, çəkmə sorğusu inkişafa birləşdirilir. Bu halda, heç bir əlavə yenidən başlatma yoxdur, lakin rəy çox yavaşlayır. Bir inkişaf etdirici olaraq, çəkmə sorğusunu açanda dərhal bunun işləyəcəyini görmək istəyirəm. Məsələn, test uğursuz olarsa, onu tez bir zamanda düzəltmək lazımdır. Gecikmiş bir quruluş vəziyyətində, əks əlaqə yavaşlayır və buna görə də bütün inkişaf. Bu da bizə yaraşmadı.

Nəticədə, yalnız üçüncü seçim qaldı - velosiped. Bütün kodlarımız, bütün mənbələrimiz Bitbucket serverində depoda saxlanılır. Müvafiq olaraq, Bitbucket üçün plagin hazırlamalı olduq.

Bu plagin çəkmə sorğusunun birləşmə mexanizmini ləğv edir. Başlanğıc standartdır: PR açılır, bütün montajlar işə salınır, kodun nəzərdən keçirilməsi tamamlanır. Lakin kodun nəzərdən keçirilməsi başa çatdıqdan və tərtibatçı “birləşmə” düyməsini sıxmağa qərar verdikdən sonra, plagin yoxlamaların hansı inkişaf vəziyyətini yoxlayır. Əgər inkişaf qurduqdan sonra yenilənibsə, plagin belə bir çəkmə sorğusunun əsas filiala birləşdirilməsinə icazə verməyəcək. Bu, sadəcə olaraq, nisbətən yeni bir inkişaf quruluşunu yenidən işə salacaq.

Bir-birinə zidd dəyişikliklərin olduğu nümunəmizdə bu cür quruluşlar kompilyasiya xətası səbəbindən uğursuz olacaq. Müvafiq olaraq, B funksiyasının tərtibatçısı kodu düzəltməli, yoxlamaları yenidən başlatmalı, sonra plagin avtomatik olaraq çəkmə sorğusunu tətbiq edəcək.

Bu plaqini tətbiq etməzdən əvvəl biz hər çəkmə sorğusu üçün orta hesabla 2,7 baxış qaçışını əldə etdik. Plugin ilə 3,6 buraxılış var idi. Bu bizə yaraşırdı.

Qeyd etmək lazımdır ki, bu plaqinin bir çatışmazlığı var: o, yalnız bir dəfə quruluşu yenidən başladır. Yəni hələ də ziddiyyətli dəyişikliklərin inkişaf edə biləcəyi kiçik bir pəncərə var. Ancaq bunun ehtimalı azdır və biz başlanğıcların sayı ilə uğursuzluq ehtimalı arasında bu mübadilə etdik. İki il ərzində yalnız bir dəfə atəş açdı, buna görə də, yəqin ki, boşuna deyildi.

Bitbucket plagininin ilk versiyasını yazmaq bizə iki həftə çəkdi.

Yeni çeklər

Bu arada komandamız böyüməyə davam edirdi. Yeni çeklər əlavə edildi.

Fikirləşdik: əgər onların qarşısını almaq olarsa, niyə səhv etmək lazımdır? Və buna görə də həyata keçirdilər statik kod analizi. Android SDK-ya daxil olan lint ilə başladıq. Amma o vaxt o, ümumiyyətlə Kotlin kodu ilə işləməyi bilmirdi və bizdə artıq 75% ərizə Kotlin dilində yazılmışdı. Buna görə də, daxili olanlar lintə əlavə edildi Android Studio yoxlayır.

Bunu etmək üçün çoxlu pozğunluqlar etməli olduq: Android Studio-nu götürün, onu Docker-də paketləyin və virtual monitor ilə CI-də işlədin ki, o, real noutbukda işlədiyini düşünsün. Amma işlədi.

Həm də bu dövrdə çox yazmağa başladıq cihaz testləri və həyata keçirilir ekran görüntüsü sınağı. Bu, ayrı bir kiçik görünüş üçün istinad ekran görüntüsünün yaradıldığı zamandır və test görünüşdən skrinşot götürmək və onu standart birbaşa piksel piksel ilə müqayisə etməkdən ibarətdir. Əgər uyğunsuzluq varsa, bu, düzənliyin haradasa səhv getdiyini və ya üslublarda bir şeyin səhv olduğunu bildirir.

Lakin cihaz testləri və ekran görüntüsü testləri cihazlarda aparılmalıdır: emulyatorlarda və ya real cihazlarda. Nəzərə alsaq ki, çoxlu sınaqlar var və onlar tez-tez aparılır, bütöv bir ferma lazımdır. Öz təsərrüfatınızı yaratmaq çox əmək tələb edir, ona görə də biz hazır seçim tapdıq - Firebase Test Laboratoriyası.

Firebase Test Laboratoriyası

Firebase Google məhsulu olduğuna görə seçildi, yəni etibarlı olmalı və heç vaxt ölmə ehtimalı az olmalıdır. Qiymətlər münasibdir: real cihazın hər saat işləməsi üçün 5 dollar, emulyatorun hər saat işləməsi üçün 1 dollar.

Firebase Test Laboratoriyasını CI-də tətbiq etmək təxminən üç həftə çəkdi.

Ancaq komanda böyüməyə davam etdi və Firebase, təəssüf ki, bizi ruhdan salmağa başladı. Həmin vaxt onun heç bir SLA-sı yox idi. Bəzən Firebase bizi tələb olunan sayda cihazların testlər üçün pulsuz olmasını gözləməyə məcbur etdi və istədiyimiz kimi dərhal icra etməyə başlamadı. Növbə gözləmək yarım saata qədər çəkdi, bu da çox uzun müddətdir. Hər bir PR-də alət testləri aparıldı, gecikmələr inkişafı həqiqətən yavaşlatdı və sonra aylıq qanun layihəsi dəyirmi bir məbləğlə gəldi. Ümumiyyətlə, komanda kifayət qədər böyüdüyü üçün Firebase-dən imtina etmək və evdə işləmək qərara alındı.

Docker + Python + bash

Docker-i götürdük, içinə emulyatorlar doldurduq, Python-da sadə bir proqram yazdıq, lazımi anda lazımi sayda emulyatorları tələb olunan versiyaya gətirir və lazım olduqda onları dayandırır. Və əlbəttə ki, bir neçə bash skripti - onlarsız harada olardıq?

Öz test mühitimizi yaratmaq beş həftə çəkdi.

Nəticədə, hər çəkmə sorğusu üçün geniş birləşməni bloklayan yoxlamalar siyahısı var idi:

• ARK montajı;
• Junit testləri;
• lint;
• Android Studio yoxlamaları;
• Cihaz testləri;
• Ekran görüntüsü testləri.

Bu, bir çox mümkün nasazlığın qarşısını aldı. Texniki cəhətdən hər şey işlədi, lakin tərtibatçılar nəticələrin gözləməsinin çox uzun olduğundan şikayətləndilər.

Nə qədər uzundur? Bitbucket və TeamCity-dən məlumatları analiz sisteminə yüklədik və bunu başa düşdük orta gözləmə müddəti 45 dəqiqə. Yəni bir tərtibatçı, çəkmə sorğusunu açarkən, qurma nəticələrini orta hesabla 45 dəqiqə gözləyir. Məncə, bu çox şeydir və siz belə işləyə bilməzsiniz.

Təbii ki, biz bütün tikintilərimizi sürətləndirməyə qərar verdik.

Gəlin sürətləndirək

Tikintilərin tez-tez növbəyə durduğunu görəndə ilk işimiz budur daha çox avadanlıq aldı — geniş inkişaf ən sadəsidir. Quraşdırma növbələrini dayandırdı, lakin gözləmə müddəti bir qədər azaldı, çünki bəzi yoxlamaların özü çox uzun müddət çəkdi.

Çox uzun çəkən çeklərin silinməsi

Davamlı İnteqrasiyamız bu tip səhvləri və problemləri tuta bilər.

• getməz. CI, ziddiyyətli dəyişikliklər səbəbiylə bir şey qurulmayanda tərtib səhvini tuta bilər. Bayaq dediyim kimi, o zaman heç kim heç nə yığa bilməz, inkişaf dayanır, hamı əsəbiləşir.
• Davranışda səhv. Məsələn, proqram qurulduqda, ancaq düyməni basdığınız zaman çökür və ya düymə ümumiyyətlə basılmır. Bu pisdir, çünki belə bir səhv istifadəçiyə çata bilər.
• Düzəlişdə səhv. Məsələn, bir düyməyə basılır, lakin 10 piksel sola köçürülür.
• Texniki borcun artması.

Bu siyahıya nəzər saldıqdan sonra anladıq ki, yalnız ilk iki məqam kritikdir. Biz ilk növbədə belə problemlərin qarşısını almaq istəyirik. Dizayndakı səhvlər dizayn-nəzərdən keçmə mərhələsində aşkar edilir və sonra asanlıqla düzəldilə bilər. Texniki borcla məşğul olmaq ayrı bir proses və planlaşdırma tələb edir, ona görə də biz onu çəkmə sorğusu ilə sınaqdan keçirməməyə qərar verdik.

Bu təsnifata əsaslanaraq, biz çeklərin bütün siyahısını silkələdik. Lint üzərindən xətt çəkildi və onun işə salınmasını bir gecəyə təxirə saldı: sadəcə olaraq, layihədə nə qədər problem olduğu barədə hesabat hazırlasın. Texniki borcla ayrı işləməyə razılaşdıq və Android Studio yoxlamalarından tamamilə imtina edildi. Yoxlamaların aparılması üçün Docker-də Android Studio maraqlı səslənir, lakin dəstəkdə çoxlu problemlər yaradır. Android Studio versiyalarının hər hansı bir yeniləməsi anlaşılmaz səhvlərlə mübarizə deməkdir. Skrinşot testlərini dəstəkləmək də çətin idi, çünki kitabxana çox stabil deyildi və yanlış pozitivlər var idi. Ekran görüntüsü testləri yoxlama siyahısından silindi.

Nəticədə biz qaldıq:

• ARK montajı;
• Junit testləri;
• Cihaz testləri.

Gradle uzaq keş

Ağır yoxlamalar olmadan hər şey daha yaxşı oldu. Ancaq mükəmməlliyə heç bir məhdudiyyət yoxdur!

Tətbiqimiz artıq təxminən 150 gradle moduluna bölünmüşdü. Gradle uzaq keşi adətən bu halda yaxşı işləyir, ona görə də biz onu sınamaq qərarına gəldik.

Gradle uzaq keşi fərdi modullarda fərdi tapşırıqlar üçün qurma artefaktlarını keşləyə bilən xidmətdir. Gradle əslində kodu tərtib etmək əvəzinə HTTP-dən istifadə edərək uzaq önbelleği döyür və kiminsə artıq bu tapşırığı yerinə yetirib-yetirmədiyini soruşur. Əgər belədirsə, o, sadəcə nəticəni yükləyir.

Gradle uzaqdan keşini idarə etmək asandır, çünki Gradle Docker təsvirini təmin edir. Biz bunu üç saat ərzində bacardıq.

Etməli olduğunuz şey Docker-i işə salmaq və layihədə bir sətir yazmaq idi. Ancaq tez bir zamanda işə salınsa da, hər şeyin yaxşı işləməsi üçün kifayət qədər vaxt lazımdır.

Aşağıda cache misses qrafiki var.

Başlanğıcda cache misses faizi təxminən 65 idi. Üç həftədən sonra biz bu dəyəri 20%-ə çatdıra bildik. Məlum oldu ki, Android tətbiqinin topladığı tapşırıqlar qəribə keçid asılılıqlarına malikdir, buna görə Gradle keşi qaçırıb.

Keşi birləşdirərək, qurmağı çox sürətləndirdik. Ancaq montajdan əlavə, cihaz testləri də var və onlar çox vaxt aparır. Ola bilsin ki, hər çəkmə sorğusu üçün bütün testləri yerinə yetirmək lazım deyil. Bunu öyrənmək üçün təsir analizindən istifadə edirik.

Təsir təhlili

Çəkmə sorğusu ilə biz git diff toplayırıq və dəyişdirilmiş Gradle modullarını tapırıq.

Yalnız dəyişdirilmiş modulları və onlardan asılı olan bütün modulları yoxlayan cihaz testlərini yerinə yetirməyin mənası var. Qonşu modullar üçün testlər keçirməyin mənası yoxdur: oradakı kod dəyişməyib və heç nə poza bilməz.

Cihaz testləri o qədər də sadə deyil, çünki onlar ən yüksək səviyyəli Tətbiq modulunda yerləşdirilməlidir. Hər testin hansı modula aid olduğunu başa düşmək üçün bayt kodu analizi ilə evristikadan istifadə etdik.

Ölçmə testlərinin işini təkmilləşdirmək, yalnız cəlb olunan modulları sınamaq üçün təxminən səkkiz həftə çəkdi.

Yoxlamaların sürətləndirilməsi tədbirləri uğurla nəticələnib. 45 dəqiqədən təxminən 15-ə qalxdıq. Quraşdırma üçün dörddə bir saat gözləmək artıq normaldır.

Amma indi tərtibatçılar şikayət etməyə başlayıblar ki, hansı konstruksiyaların işə salındığını, jurnalı harada görmək lazım olduğunu, quruluşun niyə qırmızı olduğunu, hansı testin uğursuz olduğunu və s.

Əlaqə ilə bağlı problemlər inkişafı ləngidir, ona görə də biz hər bir PR haqqında mümkün qədər aydın və ətraflı məlumat verməyə və qurmağa çalışdıq. Bitbucket-də PR-a şərhlərlə başladıq, hansı quruluşun uğursuz olduğunu və niyə uğursuz olduğunu göstərdik və Slack-də hədəf mesajlar yazdıq. Sonda biz səhifə üçün hazırda işlək vəziyyətdə olan bütün quruluşların siyahısı və onların statusu ilə PR panel yaratdıq: növbəyə qoyulmuş, işlək, qəzalı və ya tamamlanmışdır. Quraşdırmanın üzərinə klikləyib onun jurnalına daxil ola bilərsiniz.

Altı həftə ətraflı rəyə sərf olundu.

Planlar

Yaxın tarixə keçək. Əlaqə problemini həll edərək, biz yeni səviyyəyə çatdıq - öz emulyator təsərrüfatımızı qurmağa qərar verdik. Çoxlu testlər və emulyatorlar olduqda, onları idarə etmək çətindir. Nəticədə, bütün emulyatorlarımız çevik resurs idarəetməsi ilə k8s klasterinə keçdi.

Bundan əlavə, başqa planlar da var.

• Linti qaytarın (və digər statik analiz). Biz artıq bu istiqamətdə işləyirik.
• Hər şeyi PR blokerində işlədin başdan sona testlər bütün SDK versiyalarında.

Beləliklə, Avitoda Davamlı İnteqrasiyanın inkişaf tarixini izlədik. İndi təcrübəli bir nöqteyi-nəzərdən bir neçə məsləhət vermək istəyirəm.

Советы

Təkcə bir məsləhət verə bilsəm, bu belə olardı:

Zəhmət olmasa qabıq skriptləri ilə diqqətli olun!

Bash çox çevik və güclü vasitədir, skriptləri yazmaq üçün çox rahat və sürətlidir. Amma siz onunla tələyə düşə bilərsiniz və təəssüf ki, biz buna düşdük.

Hamısı tikinti maşınlarımızda işləyən sadə skriptlərlə başladı:

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

Ancaq bildiyiniz kimi, zaman keçdikcə hər şey inkişaf edir və mürəkkəbləşir - gəlin bir skripti digərindən işə salaq, bəzi parametrləri ora keçirək - sonda biz indi hansı səviyyədə bash yuvasında olduğumuzu müəyyən edən bir funksiya yazmalı olduq. lazımi sitatları daxil etmək, hər şeyə başlamaq üçün.

Bu cür skriptlərin hazırlanması üçün əmək xərclərini təsəvvür edə bilərsiniz. Mən sizə bu tələyə düşməməyi məsləhət görürəm.

Nə əvəz edilə bilər?

• İstənilən skript dili. -a yazın Python və ya Kotlin Skripti daha rahatdır, çünki bu, skriptlər deyil, proqramlaşdırmadır.
• Və ya formada bütün qurma məntiqini təsvir edin Fərdi gradle tapşırıqları layihəniz üçün.

Biz ikinci variantı seçmək qərarına gəldik və indi biz sistematik olaraq bütün bash skriptlərini silirik və çoxlu fərdi gradle tapşırıqları yazırıq.

İpucu #2: İnfrastrukturu kodda saxlayın.

Davamlı İnteqrasiya parametri Jenkins və ya TeamCity və s.-nin UI interfeysində deyil, mətn faylları şəklində birbaşa layihə deposunda saxlandıqda rahatdır. Bu versiyaya imkan verir. Kodu geri qaytarmaq və ya başqa filialda qurmaq çətin olmayacaq.

Skriptlər layihədə saxlanıla bilər. Ətraf mühitlə nə etməli?

İpucu №3: Docker ətraf mühitə kömək edə bilər.

Bu, mütləq Android tərtibatçılarına kömək edəcək; təəssüf ki, iOS-da hələ yoxdur.

Bu, jdk və android-sdk ehtiva edən sadə docker faylının nümunəsidir:

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

Bu Docker faylını (sizə bir sirr deyəcəyəm, onu yazmalı deyilsiniz, sadəcə GitHub-dan hazır şəkildə çəkin) və şəkli yığdıqdan sonra tətbiqi qura biləcəyiniz virtual maşın əldə edirsiniz. və Junit testlərini işə salın.

Bunun mənalı olmasının iki əsas səbəbi miqyaslılıq və təkrarlanabilirlikdir. Docker-dən istifadə edərək, əvvəlki ilə eyni mühitə sahib olacaq onlarla qurma agentini tez bir zamanda yetişdirə bilərsiniz. Bu, CI mühəndislərinin həyatını xeyli asanlaşdırır. Android-sdk-ni docker-ə sıxışdırmaq olduqca asandır, lakin emulyatorlarla bu bir az daha çətindir: bir az daha çox işləməli olacaqsınız (yaxud hazır olanı yenidən GitHub-dan endirin).

Məsləhət No 4: unutmayın ki, yoxlamalar yoxlama xatirinə deyil, insanlar üçün edilir.

Tez və ən əsası, aydın rəy tərtibatçılar üçün çox vacibdir: nə qırıldı, hansı test uğursuz oldu, quruluş jurnalını harada görə bilərəm.

İpucu #5: Davamlı İnteqrasiyanı inkişaf etdirərkən praqmatik olun.

Hansı növ səhvlərin qarşısını almaq istədiyinizi, nə qədər resurs, vaxt və kompüter vaxtı sərf etməyə hazır olduğunuzu aydın şəkildə anlayın. Çox uzun çəkən yoxlamalar, məsələn, bir gecəyə təxirə salına bilər. Və çox vacib olmayan səhvləri tutanlar tamamilə tərk edilməlidir.

İpucu #6: Hazır alətlərdən istifadə edin.

İndi bulud CI təmin edən bir çox şirkət var.

Bu kiçik komandalar üçün yaxşı bir həlldir. Heç bir şeyi dəstəkləməyə ehtiyac yoxdur, sadəcə bir az pul ödəyin, tətbiqinizi qurun və hətta cihaz testlərini keçirin.

İpucu №7: Böyük bir komandada daxili həllər daha sərfəlidir.

Ancaq gec-tez, komanda böyüdükcə, daxili həllər daha sərfəli olacaq. Bu qərarlarla bağlı bir problem var. İqtisadiyyatda gəlirlərin azalması qanunu var: istənilən layihədə hər bir sonrakı təkmilləşdirmə getdikcə daha çətin olur və getdikcə daha çox investisiya tələb edir.

İqtisadiyyat bütün həyatımızı, o cümlədən Davamlı İnteqrasiyanı təsvir edir. Mən Davamlı İnteqrasiyamızın inkişafının hər bir mərhələsi üçün əmək xərclərinin cədvəlini qurdum.

Aydındır ki, istənilən təkmilləşdirmə getdikcə çətinləşir. Bu qrafikə baxanda başa düşə bilərsiniz ki, Davamlı İnteqrasiya komanda ölçüsünün böyüməsinə uyğun olaraq inkişaf etdirilməlidir. İki nəfərlik bir komanda üçün daxili emulyator təsərrüfatının inkişafına 50 gün sərf etmək vasat bir fikirdir. Ancaq eyni zamanda, böyük bir komanda üçün Davamlı İnteqrasiyanı ümumiyyətlə etməmək də pis fikirdir, çünki inteqrasiya problemləri, kommunikasiyanın düzəldilməsi və s. daha çox vaxt aparacaq.

Biz belə bir fikirlə başladıq ki, avtomatlaşdırma lazımdır, çünki insanlar bahalıdır, səhv edirlər və tənbəldirlər. Amma insanlar da avtomatlaşır. Buna görə də bütün eyni problemlər avtomatlaşdırmaya aiddir.

• Avtomatlaşdırma bahalıdır. Əmək cədvəlini xatırlayın.
• Avtomatlaşdırmaya gəldikdə, insanlar səhv edirlər.
• Bəzən avtomatlaşdırmaq çox tənbəl olur, çünki hər şey belə işləyir. Nəyə görə başqa bir şeyi təkmilləşdirməlisən, niyə bütün bu Davamlı İnteqrasiya?

Ancaq mənim statistikam var: montajların 20% -ində səhvlər tutulur. Bu, bizim tərtibatçılarımızın kodu zəif yazması ilə əlaqədar deyil. Çünki tərtibatçılar əmindirlər ki, əgər hansısa səhvə yol versələr, o, inkişafda qalmayacaq, avtomatlaşdırılmış yoxlamalarla tutulacaq. Müvafiq olaraq, tərtibatçılar nəyisə yerli olaraq işlətmək və sınaqdan keçirməkdənsə, kod yazmağa və maraqlı şeylərə daha çox vaxt sərf edə bilərlər.

Davamlı İnteqrasiya Təcrübəsi. Amma orta səviyyədə.

Yeri gəlmişkən, Nikolay Nesterov təkcə özü böyük hesabatlar vermir, həm də proqram komitəsinin üzvüdür. AppsConf və başqalarına sizin üçün mənalı çıxışlar hazırlamağa kömək edir. Növbəti konfrans proqramının tamlığı və faydalılığı mövzular üzrə qiymətləndirilə bilər cədvəli. Və təfərrüatlar üçün 22-23 aprel tarixlərində Infospace-ə gəlin.

Mənbə: www.habr.com