Šiandien dauguma programinės įrangos produktų yra kuriami komandose. Sėkmingo komandos vystymosi sąlygos gali būti pavaizduotos paprastos diagramos pavidalu.

Kai parašysite kodą, turite įsitikinti, kad jis:

1. Работает.
2. Tai nieko nepažeidžia, įskaitant kodą, kurį parašė jūsų kolegos.

Jei tenkinamos abi sąlygos, tada esate kelyje į sėkmę. Norėdami lengvai patikrinti šias sąlygas ir nenukrypti nuo pelningo kelio, sugalvojome Continuous Integration.

CI yra darbo eiga, kai kaip įmanoma dažniau integruojate savo kodą į bendrą produkto kodą. Ir jūs ne tik integruojate, bet ir nuolat tikrinate, ar viskas veikia. Kadangi tikrinti reikia daug ir dažnai, verta pagalvoti apie automatizavimą. Galite viską patikrinti rankiniu būdu, bet neturėtumėte, ir štai kodėl.

• Mieli žmonės. Bet kurio programuotojo darbo valanda yra brangesnė nei bet kurio serverio darbo valanda.
• Žmonės daro klaidas. Todėl gali kilti situacijų, kai testai buvo vykdomi netinkamoje šakoje arba testuotojams buvo sudarytas netinkamas įsipareigojimas.
• Žmonės yra tingūs. Kartkartėmis, kai baigiu užduotį, kyla mintis: „Ką čia patikrinti? Parašiau dvi eilutes – viskas veikia! Manau, kad kai kuriems iš jūsų taip pat kartais kyla tokių minčių. Bet jūs visada turėtumėte patikrinti.

Kaip nuolatinė integracija buvo įdiegta ir plėtojama „Avito“ mobiliojo ryšio kūrimo komandoje, kaip jie per dieną pagamino nuo 0 iki 450 ir kaip konstruojamos mašinos surenkamos 200 valandų per dieną, sako Nikolajus Nesterovas (nnesterovas) yra visų evoliucinių CI/CD Android programos pakeitimų dalyvis.

Istorija paremta „Android“ komandos pavyzdžiu, tačiau dauguma metodų tinka ir „iOS“.

Kažkada „Avito Android“ komandoje dirbo vienas žmogus. Pagal apibrėžimą jam nereikėjo nieko iš nuolatinės integracijos: nebuvo su kuo integruotis.

Tačiau aplikacija augo, atsirado vis daugiau naujų užduočių, atitinkamai augo ir komanda. Tam tikru momentu atėjo laikas formaliau nustatyti kodo integravimo procesą. Buvo nuspręsta naudoti Git srautą.

Git srauto koncepcija yra gerai žinoma: projektas turi vieną bendrą kūrimo šaką ir kiekvienai naujai funkcijai kūrėjai nupjauna atskirą šaką, įsipareigoja jai, stumia ir, kai nori sujungti savo kodą į kūrimo šaką, atidaro traukti prašymą. Norėdami pasidalinti žiniomis ir aptarti metodus, pristatėme kodo peržiūrą, tai yra, kolegos turi patikrinti ir patvirtinti vienas kito kodą.

Patikrinimai

Matyti kodą akimis yra šaunu, bet to nepakanka. Todėl įvedami automatiniai patikrinimai.

• Pirmiausia patikriname ARK susirinkimas.
• Daug Junito testai.
• Mes svarstome kodo aprėptį, nes atliekame testus.

Norėdami suprasti, kaip turėtų būti vykdomi šie patikrinimai, pažvelkime į „Avito“ kūrimo procesą.

Schematiškai jį galima pavaizduoti taip:

• Kūrėjas rašo kodą savo nešiojamajame kompiuteryje. Integravimo patikras galite vykdyti čia pat – arba naudodami įvykdymo kabliuką, arba tiesiog paleiskite patikras fone.
• Kai kūrėjas nustūmė kodą, jis atidaro ištraukimo užklausą. Norint, kad jo kodas būtų įtrauktas į kūrimo šaką, būtina pereiti kodo peržiūrą ir surinkti reikiamą skaičių patvirtinimų. Čia galite įjungti patikrinimus ir kūrimą: kol visos versijos nebus sėkmingos, ištraukimo užklausos negalima sujungti.
• Sujungus ištraukimo užklausą ir įtraukus kodą į kūrimą, galite pasirinkti patogų laiką: pavyzdžiui, naktį, kai visi serveriai yra laisvi, ir atlikti tiek patikrinimų, kiek norite.

Niekam nepatiko skenuoti savo nešiojamąjį kompiuterį. Kai kūrėjas baigia naudoti funkciją, jis nori greitai ją perkelti ir atidaryti ištraukimo užklausą. Jei šiuo metu paleidžiamos ilgos patikros, tai ne tik nėra labai malonu, bet ir lėtina plėtrą: kol nešiojamasis kompiuteris kažką tikrina, su juo neįmanoma normaliai dirbti.

Mums labai patiko tikrinti naktimis, nes laiko ir serverių daug, galima klajoti. Tačiau, deja, kai funkcijos kodas pradedamas kurti, kūrėjas turi daug mažiau motyvacijos taisyti klaidas, kurias rado CI. Periodiškai pagaudavau save galvojant, kai peržiūrėjau visas rytiniame pranešime rastas klaidas, kad kažkada vėliau jas ištaisysiu, nes dabar Jira yra šauni nauja užduotis, kurią tiesiog noriu pradėti daryti.

Jei patikrinimai blokuoja ištraukimo užklausą, tada yra pakankamai motyvacijos, nes kol versijos nebus žalios, kodas nepateks į plėtrą, o tai reiškia, kad užduotis nebus atlikta.

Dėl to pasirinkome tokią strategiją: naktimis vykdome maksimalų įmanomą patikrinimų rinkinį, o kritiškiausius ir, svarbiausia, greičiausius, paleidžiame pagal traukos užklausą. Tačiau tuo neapsiribojame – lygiagrečiai optimizuojame patikrinimų greitį, kad perkeltume juos iš naktinio režimo į užklausų patikrinimus.

Tuo metu visos mūsų versijos buvo baigtos gana greitai, todėl tiesiog įtraukėme ARK kūrimą, Junit testus ir kodo aprėpties skaičiavimus kaip ištraukimo užklausos blokatorių. Mes jį įjungėme, pagalvojome ir atsisakėme kodo aprėpties, nes manėme, kad mums to nereikia.

Prireikė dviejų dienų, kol visiškai sukonfigūravome pagrindinį KI (toliau laiko įvertis yra apytikslis, reikalingas mastui).

Po to pradėjome galvoti toliau – ar net tikriname teisingai? Ar teisingai vykdome plėtinius pagal ištraukimo užklausas?

Pradėjome kurti nuo paskutinio atšakos, iš kurios buvo atidaryta ištraukimo užklausa, įpareigojimas. Tačiau šio įsipareigojimo testai gali parodyti tik tai, kad kūrėjo parašytas kodas veikia. Bet jie neįrodo, kad jis nieko nesulaužė. Tiesą sakant, turite patikrinti kūrimo šakos būseną po to, kai funkcija sujungiama į ją.

Norėdami tai padaryti, parašėme paprastą bash scenarijų premerge.sh:

#!/usr/bin/env bash

set -e

git fetch origin develop

git merge origin/develop

Čia visi naujausi kūrimo pakeitimai tiesiog ištraukiami ir sujungiami į dabartinę šaką. Pridėjome premerge.sh scenarijų kaip pirmąjį visų kūrimo žingsnį ir pradėjome tikrinti, ko tiksliai norime, t. integracija.

Problemai lokalizuoti, sprendimui rasti ir šiam scenarijui parašyti prireikė trijų dienų.

Programa vystėsi, atsirado vis daugiau užduočių, augo komanda, o premerge.sh kartais ėmė mus nuvilti. „Develop“ turėjo prieštaringų pakeitimų, kurie sulaužė kūrimą.

Pavyzdys, kaip tai vyksta:

Du kūrėjai vienu metu pradeda dirbti su A ir B funkcijomis. Funkcijos A kūrėjas projekte aptinka nenaudojamą funkciją answer() ir kaip geras skautas jį pašalina. Tuo pačiu metu funkcijos B kūrėjas savo filiale prideda naują šios funkcijos iškvietimą.

Kūrėjai baigia savo darbą ir tuo pačiu metu atidaro ištraukimo užklausą. Paleidžiamos versijos, premerge.sh tikrina abi ištraukimo užklausas, susijusias su naujausia kūrimo būsena – visi patikrinimai yra žali. Po to A ypatybės traukimo užklausa sujungiama, B funkcijos traukimo užklausa sujungiama... Boom! Develop pertraukos, nes kūrimo kode yra iškvietimas į neegzistuojančią funkciją.

Kai jis nesiruošia vystytis, jis vystosi vietinė nelaimė. Visa komanda negali nieko surinkti ir pateikti testavimui.

Taip jau susiklostė, kad dažniausiai dirbau su infrastruktūros užduotimis: analitika, tinklas, duomenų bazės. Tai yra, aš parašiau tas funkcijas ir klases, kurias naudoja kiti kūrėjai. Dėl to labai dažnai patekdavau į panašias situacijas. Netgi kurį laiką kabėjau šią nuotrauką.

Kadangi tai mums netiko, pradėjome ieškoti būdų, kaip to išvengti.

Kaip nepalaužti vystytis

Pirmasis variantas: atnaujinant plėtrą atkurti visas ištraukimo užklausas. Jei mūsų pavyzdyje ištraukimo užklausa su funkcija A yra pirmoji, kuri įtraukiama į plėtrą, B funkcijos ištraukimo užklausa bus atkurta ir atitinkamai patikrinimai nepavyks dėl kompiliavimo klaidos.

Norėdami suprasti, kiek tai užtruks, apsvarstykite pavyzdį su dviem PR. Atidarome du PR: dvi versijos, dvi patikros. Pirmąjį PR sujungus į plėtrą, antrąjį reikia atstatyti. Iš viso dviem PR reikia atlikti tris patikrinimus: 2 + 1 = 3.

Iš principo tai gerai. Bet mes pažiūrėjome statistiką ir tipiška situacija mūsų komandoje buvo 10 atvirų PR, o tada patikrinimų skaičius yra progreso suma: 10 + 9 +... + 1 = 55. Tai yra, priimti 10 PR, jums reikia atstatyti 55 kartus. Ir tai yra ideali situacija, kai visi patikrinimai praeina iš pirmo karto, kai niekas neatidaro papildomos ištraukimo užklausos, kol šie tuzinai yra apdorojami.

Įsivaizduokite save kaip kūrėją, kuris turi pirmas paspausti mygtuką „sujungti“, nes jei kaimynas tai padarys, turėsite palaukti, kol vėl bus baigtos visos versijos... Ne, tai neveiks. , tai labai sulėtins vystymąsi.

Antras galimas būdas: rinkti ištraukimo užklausas po kodo peržiūros. Tai reiškia, kad atidarote ištraukimo užklausą, surenkate reikiamą skaičių patvirtinimų iš kolegų, pataisote tai, ko reikia, ir paleidžiate kūrimą. Jei jie sėkmingi, ištraukimo užklausa sujungiama į plėtrą. Tokiu atveju papildomų paleidimų iš naujo nėra, tačiau grįžtamasis ryšys labai sulėtėja. Kaip kūrėjas, kai atidarau ištraukimo užklausą, iš karto noriu pamatyti, ar ji veiks. Pavyzdžiui, jei bandymas nepavyksta, turite greitai jį ištaisyti. Uždelsto kūrimo atveju grįžtamasis ryšys sulėtėja, taigi ir visa plėtra. Tai mums irgi netiko.

Dėl to liko tik trečiasis variantas - dviračiu Sportas. Visas mūsų kodas, visi šaltiniai yra saugomi Bitbucket serverio saugykloje. Atitinkamai, mes turėjome sukurti „Bitbucket“ papildinį.

Šis papildinys nepaiso ištraukimo užklausos sujungimo mechanizmo. Pradžia standartinė: atsidaro PR, paleidžiami visi mazgai, baigta kodo peržiūra. Tačiau kai kodo peržiūra bus baigta ir kūrėjas nusprendžia spustelėti „sujungti“, papildinys patikrina, pagal kurią kūrimo būseną buvo vykdomos patikros. Jei plėtra buvo atnaujinta po kūrimo, įskiepis neleis tokios ištraukimo užklausos sujungti į pagrindinę šaką. Tai tiesiog iš naujo paleis palyginti neseniai sukurtos versijos kūrimą.

Mūsų pavyzdyje su prieštaringais pakeitimais tokios versijos nepavyks dėl kompiliavimo klaidos. Atitinkamai B funkcijos kūrėjas turės pataisyti kodą, iš naujo paleisti patikras, tada įskiepis automatiškai pritaikys ištraukimo užklausą.

Prieš diegdami šį papildinį, mes vidutiniškai atlikome 2,7 peržiūros vieną ištraukimo užklausą. Su papildiniu buvo 3,6 paleidimo. Tai mums tiko.

Verta paminėti, kad šis papildinys turi trūkumą: jis tik vieną kartą paleidžia kūrimą iš naujo. Tai reiškia, kad vis dar yra mažas langas, per kurį gali išsivystyti prieštaringi pokyčiai. Tačiau to tikimybė yra maža, todėl mes padarėme kompromisą tarp paleidimų skaičiaus ir nesėkmės tikimybės. Per dvejus metus iššovė tik vieną kartą, tad tikriausiai ne veltui.

Prireikė dviejų savaičių, kol parašėme pirmąją „Bitbucket“ papildinio versiją.

Nauji čekiai

Tuo tarpu mūsų komanda toliau augo. Pridėta naujų čekių.

Pagalvojome: kam daryti klaidas, jei jų galima išvengti? Ir todėl jie įgyvendinami statinio kodo analizė. Pradėjome nuo pūkelių, kurie yra įtraukti į „Android“ SDK. Bet tuo metu jis visiškai nemokėjo dirbti su Kotlin kodu, o mes jau turėjome 75% programos, parašytos Kotlin. Todėl į pūkelius buvo pridėta įmontuotų „Android Studio“ tikrina.

Norėdami tai padaryti, turėjome daug iškraipyti: paimkite Android Studio, supakuokite ją į Docker ir paleiskite CI su virtualiu monitoriumi, kad manytų, kad veikia tikrame nešiojamajame kompiuteryje. Bet pavyko.

Taip pat per tą laiką pradėjome daug rašyti prietaisų testai ir įgyvendintas ekrano kopijų testavimas. Tai yra tada, kai atskiram mažam vaizdui sukuriama atskaitos ekrano kopija, o testą sudaro ekrano kopija iš rodinio ir palyginimas su standartine tiesiogiai po pikselį. Jei yra neatitikimų, tai reiškia, kad kažkur suklydo išdėstymas arba kažkas negerai stiliuose.

Tačiau prietaisų testai ir ekrano kopijų testai turi būti atliekami įrenginiuose: emuliatoriuose arba tikruose įrenginiuose. Atsižvelgiant į tai, kad bandymų yra daug ir jie atliekami dažnai, reikia viso ūkio. Pradėti savo ūkį yra per daug darbo jėgos, todėl radome paruoštą variantą – Firebase Test Lab.

„Firebase“ bandymų laboratorija

Jis buvo pasirinktas, nes „Firebase“ yra „Google“ produktas, o tai reiškia, kad jis turėtų būti patikimas ir mažai tikėtina, kad kada nors mirs. Kainos yra priimtinos: 5 USD už tikro įrenginio veikimo valandą, 1 USD už emuliatoriaus veikimo valandą.

„Firebase Test Lab“ įdiegimas mūsų CI užtruko maždaug tris savaites.

Tačiau komanda toliau augo, o „Firebase“, deja, pradėjo mus nuvilti. Tuo metu jis neturėjo jokio SLA. Kartais „Firebase“ priversdavo laukti, kol bus laisvų reikiamų įrenginių testams, ir nepradėdavo jų vykdyti iš karto, kaip norėjome. Laukimas eilėje užtruko iki pusvalandžio, o tai yra labai ilgas laikas. Prietaisų testai buvo atliekami kiekviename PR, vėlavimai tikrai sulėtino plėtrą, o tada mėnesinė sąskaita buvo apvali suma. Apskritai buvo nuspręsta atsisakyti „Firebase“ ir dirbti namuose, nes komanda pakankamai išaugo.

Docker + Python + bash

Paėmėme Docker, prikimšome į jį emuliatorių, surašėme paprastą programą Python, kuri reikiamu momentu atneša reikiamą emuliatorių skaičių reikiamoje versijoje ir prireikus juos sustabdo. Ir, žinoma, pora bash scenarijų – kur mes būtume be jų?

Savo bandymo aplinkai sukurti prireikė penkių savaičių.

Todėl kiekvienai ištraukimo užklausai buvo pateiktas platus sujungimą blokuojančių patikrų sąrašas:

• ARK surinkimas;
• Junito testai;
• Pūkeliai;
• Android Studio patikrinimai;
• Instrumentiniai testai;
• Ekrano kopijų testai.

Taip buvo išvengta daugelio galimų gedimų. Techniškai viskas veikė, tačiau kūrėjai skundėsi, kad rezultatų laukti per ilgai.

Kiek laiko yra per ilgas? Į analizės sistemą įkėlėme duomenis iš Bitbucket ir TeamCity ir tai supratome vidutinis laukimo laikas 45 min. Tai yra, kūrėjas, atidarydamas ištraukimo užklausą, vidutiniškai laukia 45 minutes kūrimo rezultatų. Mano nuomone, tai yra daug, ir jūs negalite taip dirbti.

Žinoma, mes nusprendėme paspartinti visas savo statybas.

Paspartinkime

Matydami, kad pastatai dažnai stovi eilėje, pirmiausia darome įsigijo daugiau techninės įrangos — ekstensyvi plėtra yra pati paprasčiausia. Statiniai nustojo stovėti eilėse, tačiau laukimo laikas sumažėjo tik šiek tiek, nes kai kurie patikrinimai užtruko labai ilgai.

Per ilgai trunkančių čekių pašalinimas

Mūsų nuolatinis integravimas gali užfiksuoti tokio tipo klaidas ir problemas.

• Nesiruošiu. CI gali užfiksuoti kompiliavimo klaidą, kai kas nors nesukuriama dėl prieštaringų pakeitimų. Kaip jau sakiau, tada niekas nieko negali surinkti, vystymasis sustoja ir visi nervinasi.
• Elgesio klaida. Pavyzdžiui, kai programa sukurta, bet užstringa paspaudus mygtuką arba mygtukas visai nepaspaudžiamas. Tai blogai, nes tokia klaida gali pasiekti vartotoją.
• Išdėstymo klaida. Pavyzdžiui, spustelėtas mygtukas, bet jis pasislinko 10 pikselių į kairę.
• Techninės skolos padidėjimas.

Peržiūrėję šį sąrašą supratome, kad tik pirmieji du punktai yra svarbūs. Pirmiausia norime pagauti tokias problemas. Išdėstymo klaidos aptinkamos dizaino peržiūros etape ir tada jas galima lengvai ištaisyti. Techninių skolų tvarkymas reikalauja atskiro proceso ir planavimo, todėl nusprendėme jo nebandyti pagal ištraukimo užklausą.

Remdamiesi šia klasifikacija, sumaišėme visą čekių sąrašą. Nubrauktas Lintas ir atidėjo jo paleidimą nakčiai: tik tam, kad būtų parengta ataskaita apie tai, kiek problemų kilo projekte. Sutarėme dirbti atskirai su technine skola, ir „Android Studio“ patikrinimų buvo visiškai atsisakyta. „Android Studio“ programoje „Docker“, skirta tikrinimams, skamba įdomiai, tačiau sukelia daug problemų dėl palaikymo. Bet koks „Android Studio“ versijų atnaujinimas reiškia kovą su nesuprantamomis klaidomis. Taip pat buvo sunku palaikyti ekrano kopijų testus, nes biblioteka nebuvo labai stabili ir buvo klaidingų teigiamų rezultatų. Ekrano kopijų testai buvo pašalinti iš kontrolinio sąrašo.

Dėl to mums liko:

• ARK surinkimas;
• Junito testai;
• Instrumentiniai testai.

Gradle nuotolinė talpykla

Be didelių patikrinimų viskas tapo geriau. Tačiau tobulumui ribų nėra!

Mūsų programa jau buvo padalinta į maždaug 150 gradle modulių. Gradle nuotolinė talpykla šiuo atveju paprastai veikia gerai, todėl nusprendėme tai išbandyti.

„Gradle“ nuotolinė talpykla yra paslauga, kuri gali talpykloje saugoti atskirų modulių užduočių kūrimo artefaktus. „Gradle“, užuot iš tikrųjų sudaręs kodą, naudoja HTTP, kad pasibelstų į nuotolinę talpyklą ir paklaustų, ar kas nors jau atliko šią užduotį. Jei taip, jis tiesiog atsisiunčia rezultatą.

Paleisti „Gradle“ nuotolinę talpyklą paprasta, nes „Gradle“ pateikia „Docker“ vaizdą. Mums pavyko tai padaryti per tris valandas.

Tereikėjo paleisti „Docker“ ir parašyti vieną eilutę projekte. Bet nors jį galima paleisti greitai, prireiks nemažai laiko, kol viskas gerai veiktų.

Žemiau yra talpyklos praleidimų grafikas.

Pačioje pradžioje talpyklos praleidimų procentas buvo apie 65. Po trijų savaičių pavyko šią reikšmę padidinti iki 20%. Paaiškėjo, kad užduotys, kurias renka „Android“ programa, turi keistų pereinamųjų priklausomybių, dėl kurių „Gradle“ praleido talpyklą.

Prijungę talpyklą labai paspartinome kūrimą. Tačiau be surinkimo, yra ir prietaisų bandymai, ir jie trunka ilgai. Galbūt ne visi testai turi būti atliekami atliekant kiekvieną ištraukimo užklausą. Norėdami tai išsiaiškinti, naudojame poveikio analizę.

Poveikio analizė

Pagal ištraukimo užklausą surenkame git skirtumą ir randame modifikuotus „Gradle“ modulius.

Tikslinga vykdyti tik prietaisų testus, kurie tikrina pakeistus modulius ir visus nuo jų priklausančius modulius. Nėra prasmės vykdyti testus kaimyniniams moduliams: kodas ten nepasikeitė ir niekas negali sugesti.

Instrumentų testai nėra tokie paprasti, nes jie turi būti aukščiausio lygio programų modulyje. Norėdami suprasti, kuriam moduliui priklauso kiekvienas testas, naudojome euristiką su baitinio kodo analize.

Prietaisų bandymų veikimo atnaujinimas, kad būtų tikrinami tik susiję moduliai, užtruko apie aštuonias savaites.

Patikrinimų paspartinimo priemonės veikė sėkmingai. Nuo 45 minučių pakilome iki maždaug 15. Jau normalu, kad pastatymo laukti ketvirtį valandos.

Tačiau dabar kūrėjai pradėjo skųstis, kad nesupranta, kurios versijos yra paleidžiamos, kur galima pamatyti žurnalą, kodėl konstrukcija yra raudona, kuris testas nepavyko ir pan.

Problemos su grįžtamuoju ryšiu lėtina plėtrą, todėl stengėmės pateikti kuo aiškesnę ir išsamesnę informaciją apie kiekvieną PR ir kūrimą. Pradėjome nuo komentarų „Bitbucket“ PR, nurodydami, kuris kūrimas nepavyko ir kodėl, ir parašėme tikslinius pranešimus „Slack“. Galų gale sukūrėme puslapio PR ataskaitų suvestinę su visų šiuo metu veikiančių versijų sąrašu ir jų būsena: eilėje, paleista, uždengta arba baigta. Galite spustelėti pastatymą ir patekti į jo žurnalą.

Šešios savaitės buvo skirtos išsamiam atsiliepimui.

Planai

Pereikime prie naujausios istorijos. Išsprendę grįžtamojo ryšio problemą pasiekėme naują lygį – nusprendėme sukurti savo emuliatorių fermą. Kai yra daug testų ir emuliatorių, juos sunku valdyti. Todėl visi mūsų emuliatoriai perėjo į k8s klasterį su lanksčiu išteklių valdymu.

Be to, yra ir kitų planų.

• Grąžinti Lint (ir kita statinė analizė). Šia kryptimi jau dirbame.
• Paleiskite viską PR blokatoriuje galutiniai testai visose SDK versijose.

Taigi, mes atsekėme Avito nuolatinės integracijos kūrimo istoriją. Dabar noriu duoti keletą patarimų iš patyrusio taško.

Советы

Jei galėčiau duoti tik vieną patarimą, tai būtų toks:

Būkite atsargūs su apvalkalo scenarijais!

Bash yra labai lankstus ir galingas įrankis, juo labai patogu ir greita rašyti scenarijus. Bet su juo galite pakliūti į spąstus, ir mes, deja, į juos patekome.

Viskas prasidėjo nuo paprastų scenarijų, kurie buvo vykdomi mūsų kūrimo mašinose:

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

Bet, kaip žinote, laikui bėgant viskas vystosi ir darosi vis sudėtingesnė – paleiskime vieną scenarijų iš kito, perduokime ten kai kuriuos parametrus – galų gale turėjome parašyti funkciją, kuri nustato, kokiame bash lizdo lygyje dabar esame tvarkingi. įterpti reikiamas kabutes, kad viskas prasidėtų.

Galite įsivaizduoti darbo sąnaudas kuriant tokius scenarijus. Patariu nepakliūti į šiuos spąstus.

Ką galima pakeisti?

• Bet kokia scenarijų kalba. Parašyti Python arba Kotlin scenarijus patogiau, nes tai programavimas, o ne scenarijai.
• Arba apibūdinkite visą kūrimo logiką formoje Individualizuotos gradle užduotys jūsų projektui.

Nusprendėme pasirinkti antrąjį variantą, o dabar sistemingai triname visus bash scenarijus ir rašome daug pasirinktinių gradle užduočių.

2 patarimas: saugokite infrastruktūrą kode.

Patogu, kai Continuous Integration nustatymas saugomas ne Jenkins ar TeamCity ir pan. vartotojo sąsajoje, o tekstinių failų pavidalu tiesiai projekto saugykloje. Tai suteikia versijų galimybę. Bus nesunku atkurti arba sukurti kodą kitoje šakoje.

Scenarijai gali būti saugomi projekte. Ką daryti su aplinka?

3 patarimas: „Docker“ gali padėti tausoti aplinką.

Tai tikrai padės „Android“ kūrėjams, deja, „iOS“ jos dar neturi.

Tai yra paprasto docker failo, kuriame yra jdk ir android-sdk, pavyzdys:

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

Parašę šį Docker failą (išduosiu paslaptį, jūs neturite jo rašyti, o tiesiog ištraukite jį paruoštą iš GitHub) ir surinkę vaizdą, gaunate virtualią mašiną, kurioje galite kurti programą ir paleiskite Junito testus.

Dvi pagrindinės priežastys, kodėl tai prasminga, yra mastelio keitimas ir pakartojamumas. Naudodami docker galite greitai sukurti keliolika kūrimo agentų, kurių aplinka bus lygiai tokia pati kaip ir ankstesnė. Tai labai palengvina CI inžinierių gyvenimą. Gana lengva įstumti „Android-sdk“ į „Docker“, tačiau naudojant emuliatorius tai yra šiek tiek sunkiau: turėsite šiek tiek daugiau dirbti (arba vėl atsisiųsti gatavą iš „GitHub“).

Patarimas Nr.4: nepamirškite, kad patikrinimai atliekami ne dėl patikrinimų, o dėl žmonių.

Kūrėjams labai svarbūs greiti ir, svarbiausia, aiškūs atsiliepimai: kas sugedo, koks testas nepavyko, kur galiu pamatyti buildlog.

5 patarimas: kurdami nuolatinę integraciją būkite pragmatiški.

Aiškiai supraskite, kokio tipo klaidų norite išvengti, kiek išteklių, laiko ir laiko kompiuteriui norite skirti. Pavyzdžiui, per ilgai trunkantys patikrinimai gali būti atidėti nakčiai. O tų, kurios pagauna ne itin svarbias klaidas, reikėtų visiškai atsisakyti.

6 patarimas: naudokite paruoštus įrankius.

Dabar yra daug kompanijų, teikiančių debesų CI.

Tai geras sprendimas mažoms komandoms. Jums nereikia nieko remti, tiesiog sumokėkite šiek tiek pinigų, sukurkite programą ir net atlikite prietaisų testus.

7 patarimas: didelėje komandoje vidiniai sprendimai yra pelningesni.

Tačiau anksčiau ar vėliau, komandai augant, vidiniai sprendimai taps pelningesni. Su šiais sprendimais yra viena problema. Ekonomikoje galioja mažėjančios grąžos dėsnis: bet kuriame projekte kiekvienas paskesnis tobulinimas yra vis sunkesnis ir reikalauja vis daugiau investicijų.

Ekonomika apibūdina visą mūsų gyvenimą, įskaitant nuolatinę integraciją. Sudariau darbo sąnaudų grafiką kiekvienam mūsų nuolatinės integracijos kūrimo etapui.

Akivaizdu, kad bet koks tobulėjimas darosi vis sunkesnis. Žvelgdami į šį grafiką galite suprasti, kad nuolatinė integracija turi būti plėtojama atsižvelgiant į komandos dydžio augimą. Dviejų žmonių komandai skirti 50 dienų vidinio emuliatoriaus ūkio kūrimui yra vidutiniška idėja. Bet tuo pat metu didelei komandai iš viso nedaryti Nuolatinės integracijos taip pat yra bloga mintis, nes integracijos problemos, komunikacijos taisymas ir pan. tai užtruks dar daugiau laiko.

Pradėjome nuo minties, kad reikia automatizuoti, nes žmonės brangūs, klysta ir yra tingūs. Tačiau žmonės taip pat automatizuoja. Todėl visos tos pačios problemos galioja ir automatizavimui.

• Automatika yra brangi. Prisiminkite darbo grafiką.
• Kalbant apie automatizavimą, žmonės daro klaidų.
• Kartais labai tingi automatizuoti, nes viskas veikia taip. Kam dar ką nors tobulinti, kam visa tai nuolatinė integracija?

Bet turiu statistiką: klaidos užfiksuojamos 20% surinkimų. Ir tai ne todėl, kad mūsų kūrėjai blogai rašo kodą. Taip yra todėl, kad kūrėjai yra įsitikinę, kad jei padarys kokią nors klaidą, ji nepasibaigs kūrimu, o bus užfiksuota automatinių patikrinimų. Atitinkamai, kūrėjai gali praleisti daugiau laiko rašydami kodą ir įdomius dalykus, o ne ką nors paleisdami ir bandydami vietoje.

Praktikuokite nuolatinę integraciją. Bet saikingai.

Beje, Nikolajus Nesterovas ne tik pats rengia puikius pranešimus, bet ir yra programos komiteto narys AppsConf ir padeda kitiems paruošti jums prasmingas kalbas. Kitos konferencijos programos išsamumą ir naudingumą galima įvertinti pagal temas tvarkaraštį. O detaliau – į Infospace balandžio 22-23 d.

Šaltinis: www.habr.com