Täna arendatakse enamik tarkvaratooteid meeskondades. Meeskonnatöö edusamme saab kujutada lihtsa skeemina.

Pärast koodi kirjutamist peate veenduma, et see:

1. Töötaks.
2. Ei rikuks midagi, sealhulgas teie kolleegide kirjutatud koodi.

Kui mõlemad tingimused on täidetud, siis olete edukuse teel. Kui soovite neid tingimusi hõlpsasti kontrollida ja mitte kasulikult teelt kõrvale kalduda, leiutati pidev integratsioon.

CI on tööprotsess, kus integreerite oma koodi toote üldisesse koodi võimalikult tihti. Ja mitte ainult integreerite, vaid ka pidevalt kontrollite, et kõik töötaks. Kuna tuleb palju ja tihti kontrollida, tasub mõelda automatiseerimise peale. Kõike saab manuaalselt kontrollida, kuid see ei ole tark, ja siin on miks.

• Inimesed on kallid. Ühe programmeerija töö tund maksab rohkem kui ühe serveri töö tund.
• Inimesed eksivad. Seetõttu võivad tekkida olukorrad, kui testid käivitatakse vale haru peal või koostatakse vale kommity testijate jaoks.
• Inimesed on laisad. Perioodiliselt, kui lõpetan mõne ülesande, tuleb mul pähe mõte: „Mida siin kontrollida? Kirjutasin kaks rida — kindlasti töötab kõik!” Arvan, et mõnel teist tulevad sellised mõtted vahel ka meelde. Kuid kontrollida tuleb alati.

Kuidas Rakendati ja Arendati Pidevat Integratsiooni Avito mobiiliarenduse meeskonnas, kuidas jõuti nullist 450 kogumiseni päevas ja mida kogumismasinad iga päev 200 tunni eest teevad, räägib Nikolai Nesterov (nnesterov) — osaleja kõigis CI/CD Android-rakenduse evolutsioonimuutustes.

Lugu on üles ehitatud Android meeskonna näitel, kuid enamik lähenemisi on rakendatavad ka iOS-is.

Kaua aega tagasi töötas Avito Android meeskonnas üks inimene. Talle ei olnud definitsiooni järgi pidev integratsioon vajalik: ei olnud kellegagi integreerida.

Kuid rakendus kasvas, ilmus üha rohkem uusi ülesandeid ja vastavalt suurenes meeskond. Ühel hetkel tuli aeg koodi integreerimise protsess formaalsemaks muuta. Otsustati kasutada Git flow'd.

Git flow kontseptsioon on teada: projektis on üks ühine arendusbranch, ja iga uue funktsiooni jaoks lõikavad arendajad eraldi haru, komiteerivad sellesse, tõukavad seda ja kui nad tahavad oma koodi arendusbranchi ühendada, avavad nad pull requesti. Teadmiste vahetamiseks ja lähenemiste arutamiseks oleme sisse viinud koodide ülevaate, kus kolleegid peavad üksteise koodi kontrollima ja kinnitama.

Kontrollid

Koodi vaatamine on äge, kuid sellega ei piisa. Seetõttu kehtestatakse automaatsed kontrollid.

• Esmalt kontrollime ARKi kogumist.
• Palju Junit teste.
• Arvutame koodi katvuse, kuna käivitame testid.

Et aru saada, kuidas neid kontrolle käivitada, vaatame arendusprotsessi Avitos.

Skeemiliselt saab seda ette kujutada nii:

• Arendaja kirjutab koodi oma sülearvutis. Integration checke saab käivitada otse siin — kas commit hook'iga või lihtsalt testide taustal käitamisega.
• Pärast seda, kui arendaja on koodi tõuganud, avab ta pull requesti. Selleks, et tema kood pääseks arendusbranchi, peab olema läbi viidud koodide ülevaade ja vajalik arv kinnitusi. Siia on võimalik ühendata kontrollid ja build'id: kuni kõik build'id ei ole edukad, ei saa pull requesti ühendada.
• Pärast seda, kui pull request on ühendatud ja kood on läinud arendusbranchi, saab valida sobiva aja: näiteks öösel, kui kõik serverid on vabad, ja käivitada teste nii palju kui võimalik.

Kontrollide käitamine oma sülearvutis ei meeldinud kellelegi. Kui arendaja on funktsiooni lõpetanud, tahab ta selle kiirelt tõukama ja avada pull requesti. Kui sel hetkel käivitatakse pikad kontrollid, pole see mitte ainult ebamugav, vaid aeglustab ka arendust: kuni sülearvuti kontrollib, ei saa seal normaalselt töötada.

Öösel kontrolle käivitada meeldis meile väga, kuna aega ja servere on palju, saab ennast välja elada. Kuid kahjuks, kui funktsiooni kood oli läinud arendusbranchi, oli arendajal juba palju vähem motivatsiooni parandada vigu, mida CI leidis. Ma vahepeal püüdsin end korduvalt selle mõttega, kui vaatasin hommikusel aruandel kõik leitud vead, et parandan need kunagi hiljem, kuna praegu on Jira's äge uus ülesanne, mida tahaks alustada.

Kui kontrollid blokeerivad pull requesti, on motivatsiooni piisavalt, sest seni, kuni build'id ei ole edukad, ei pääse kood arendusbranchi, ja seega ülesanne ei saa olema lõpetatud.

Lõpuks valisime sellise strateegia: öösel jooksutame maksimaalset kontrollide kogumit, samas kui kõige kriitilisemad ja, mis kõige tähtsam, kiiremad neist käivitame pull request'i raames. Kuid sellega ei piirdunud — samaaegselt optimeerime kontrollide läbimise kiirus, et viia need öisest režiimist pull request'i kontrollideks.

Sel hetkel läbisid kõik meie ehitused piisavalt kiiresti, seetõttu lülitasime lihtsalt pull request'i blokeerijana sisse ARK'i ehituse, Junit-testid ja code coverage'i arvutamise. Lülitasime sisse, mõtlesime — ja loobusime code coverage'ist, kuna arvutasime, et see ei ole meile vajalik.

Kogu põhilise CI seadistamise jaoks läks meil kaks päeva (siin ja edaspidi on ajahinnang umbkaudne, vajalik mastaabi mõistmiseks).

Pärast seda hakkasime edasi mõtlema — kas me kontrollime õigesti? Kas me käivitame ehitused pull request'i raames õigesti?

Me käivitasime ehituse viimase commit'i peal haru, millest pull request avati. Kuid selle commit'i kontrollid võivad näidata ainult seda, et arendaja kirjutatud kood töötab. Kuid nad ei tõesta, et ta ei ole midagi rikkunud. Tegelikult tuleb kontrollida develop haru seisundit pärast seda, kui feature on sellesse lisatud.

Selleks kirjutasime lihtsa bash-skripti premerge.sh:

#!/usr/bin/env bash

set -e

git fetch origin develop

git merge origin/develop

Siin tõmmatakse lihtsalt kõik uusimad muudatused develop'ist ja lisatakse praegusse haru. Lisame skripti premerge.sh kõigi ehituste esimeseks sammuks ning hakkame kontrollima täpselt seda, mida soovime, ehk siis integreerimist.

Probleemide lokaliseerimise, lahenduse leidmise ja selle skripti kirjutamiseks läks kolm päeva.

Rakendus arenes, ülesandeid ilmus üha rohkem, meeskond kasvas ja premerge.sh hakkas meid mõnikord alt vedama. Develop'isse imbusid konflikti muutused, mis rikkusid ehitust.

Näide sellest, kuidas see juhtub:

Kaks arendajat alustavad samal ajal feature'ite A ja B loomist. Arendaja feature'ist A leiab projektis kasutamata funktsiooni answer() ja, nagu hea skaut, kustutab selle. Samal ajal lisab arendaja feature'ist B oma harusse uue kutsungi sellele funktsioonile.

Arendajad lõpetavad oma töö ja avavad samal ajal pull request'i. Ehitus käivitub, premerge.sh kontrollib mõlemat pull request'i värske develop'i seisundi suhtes — kõik kontrollid on rohelised. Pärast seda liidetakse feature A pull request, seejärel liidetakse feature B pull request... Pomm! Develop puruneb, kuna develop'i koodis on kutsung mitteolevale funktsioonile.

Kui develop ei kogune, siis see kohalik katastroof. Kogu meeskond ei suuda midagi kokku koguda ja testimiseks anda.

Nii juhtus, et ma tegelesin kõige sagedamini infrastruktuuriülesannetega: analüüs, võrk, andmebaasid. Just mina kirjutasin need funktsioonid ja klassid, mida teised arendajad kasutavad. Selle tõttu sattusin tihti sarnastesse olukordadesse. Mul oli isegi aega, mil selline pilt seisis.

Kuna see meid ei rahuldanud, hakkasime välja töötama variantide, kuidas seda ennetada.

Kuidas mitte developit lõhkuda

Esimene variant: kõik pull requestid uuendamisel uuesti kokku panna. Kui meie näites pull request funktsiooniga A esimene jõuab developisse, siis pull request funktsiooniga B pannakse uuesti kokku ja seega ei läbene kontrollide tõttu kompileerimisviga.

Kuna aru saada, kui palju aega see võtab, vaatame kahe PR näidet. Avame kaks PR: kaks ehitust, kaks kontrolli käivitamist. Pärast seda, kui esimene PR on developisse sulandunud, tuleb teine uuesti kokku panna. Kokku kulub kahe PR jaoks kolme kontrolli käivitamist: 2 + 1 = 3.

Põhimõtteliselt pole paha. Aga me vaatasime statistikat ja meie meeskonnas oli tüüpiliseks olukorraks 10 avatud PR-i, ja siis on kontrollide arv: aritmeetilise progresseerumise summa: 10 + 9 +… + 1 = 55. See tähendab, et 10 PR-i aktsepteerimiseks tuleb uuesti kokku panna 55 korda. Ja see on ideaalsetes tingimustes, kui kõik kontrollid lähevad esimesel korral läbi, ja keegi ei ava täiendavat pull requesti, kuni see kümme töödeldakse.

Kujutage ette end arendajana, kellele tuleb pingutada, et vajutada nuppu 'merge' esimesena, sest kui seda teeb naaber, tuleb oodata, kuni kõik koosteprotsessid uuesti lähevad... Ei, nii ei saa, see aeglustab tõsiselt arendust.

Teine võimalik viis: koguda pull request pärast koodivaatust. See tähendab, et avate pull requesti, kogute vajalik arv kinnitusi kolleegidelt, parandate, mis on vajalik, ja seejärel käitate ehitused. Kui need on edukad, liidetakse pull request developiga. Sel juhul pole täiendavaid uuesti käivitamisi, kuid tagasiside aeglustub oluliselt. Mina arendajana tahan pull requesti avades kohe näha, kas see koostatakse. Näiteks, kui mõni test kukub, tuleb see kiiresti parandada. Edasilükatud kooste puhul aeglustub tagasiside, ja seega kogu arendus. See ei rahuldanud ka meid.

Kokkuvõttes jäi ainult kolmas variant — ratast leiutadaKogu meie kood ja kõik meie lähtekoodid on salvestatud Bitbucket-serveri hoidlas. Seega pidime arendama Bitbucketile pistikprogrammi.

See pistikprogramm ületab pull request'ide sulandumismehhanismi. Algus on standardne: avatakse PR, käivitatakse kõik ehitused, toimub koodikontroll. Kuid pärast koodikontrolli läbimist, kui arendaja otsustab vajutada 'merge', kontrollib pistikprogramm, millise arenduse oleku suhtes kontrollid käivitatakse. Kui pärast ehitusi arendus on uuendatud, ei luba pistikprogramm sellist pull requesti põhiharusse sulanduda. See lihtsalt käivitab ehitused uuema arenduse suhtes.

Meie konfliktsete muudatuste näites ei läbinud sellised ehitused kompileerimisvea tõttu. Seega peab funktsiooni B arendaja koodi parandama, kontrollid uuesti käivitama, siis rakendab pistikprogramm automaatselt pull requesti.

Enne selle pistikprogrammi rakendamist oli meil keskmiselt 2,7 kontrolli käivitamist ühe pull requesti kohta. Pistikprogrammi kasutamise järel on see kasvanud 3,6 kontrolli käivitamiseni. See rahuldab meid.

Tasub märkida, et sellel pistikprogrammil on puudus: see käivitab ehituse ainult üks kord. See tähendab, et jääb väike aken, mille kaudu võivad konfliktse muudatusega arendusse sattuda. Kuid selle tõenäosus on väike ning me lubasime endale selle kompromissi käivituste arvu ja tõrgete tõenäosuse vahel. Kahe aasta jooksul juhtus see vaid üks kord, seega arvatavasti on see õigustatud.

Bitbucket'i pistikprogrammi esimese versiooni kirjutamiseks kulus meil kaks nädalat.

Uued kontrollid

Samaanl ajal kasvas meie meeskond. Uusi kontrolli lisandusid.

Mõtlesime: miks parandada vigu, kui neid saab ennetada? Seetõttu rakendasime staatilise koodi analüüsi. Alustasime lint'ist, mis on osa Android SDK-st. Kuid see ei osanud toona üldse töötada Kotlin'i koodiga, samas kui meie rakendusest oli juba 75% kirjutatud Kotlin-is. Seega lisasime lint'ile sisse ehitatud Android Studio kontrollid.

Selle jaoks pidime tõeliselt vaeva nägema: võtma Android Studio, pakendama selle Dockerisse ja käivitama CI's virtuaalse monitoriga, et see arvaks, et see käivitatakse reaalses sülearvutis. Kuid see toimis.

Samuti hakkasime sel ajal kirjutama palju instrumentatsiooniteste ja rakendasime ekraanipildistamise testimist.See, kui genereeritakse referentskuva eraldi väikese vaate jaoks, ja test seisneb selles, et antud vaates võetakse kuvatõmmis ja võrreldakse seda referentsiga otse piksliti. Kui on erinevus, siis kuskil on skeem vale või on stiilides midagi valesti.

Kuid instrumentatsiooni testid ja kuvatõmmise testid tuleb käivitada seadmetes: emulaatorites või reaalses seadmes. Arvestades, et teste on palju ja neid käitatakse tihti, on vajalik terve farm. Oma farmi loomine oleks liiga töömahukas, seetõttu leidsime alternatiivi — Firebase Test Lab.

Firebase Test Lab

Valiti, sest Firebase on Google'i toode, mis tähendab, et see peaks olema usaldusväärne ja ei sure tõenäoliselt kunagi välja. Hind on taskukohane: 5 $ tunnis reaalse seadme kasutamise eest, 1 $ tunnis emulaatori kasutamise eest.

Firebase Test Labi rakendamiseks meie CI-s kulus umbes kolm nädalat.

Kuid meeskond jätkas kasvu ning Firebase hakkas meid kahjuks alt vedama. Sel ajal puudus sellel mistahes SLA. Mõnikord pidi Firebase ootama, kuni vajalik arv seadmeid teste jaoks on vabastatud, selle asemel, et hakata teste kohe käivitama, nagu me soovisime. Ooteaeg oli kuni pool tundi, mis on väga pikk. Instrumentatsiooni teste käidi iga PR-i puhul ning viivitused aeglustasid arendust, seejärel saime arve kuu kohta, kust tuli ringisumma. Ühesõnaga, otsustasime Firebase'ist loobuda ja teha seda ise, kuna meeskond oli piisavalt kasvanud.

Docker + Python + bash

Võtsime Docker'i, panime emulaatorid sisse, kirjutasime lihtsa programmi Pythonis, mis vajaliku hetke saabudes käivitab vajalikul arvu emulaatoreid vajalikus versioonis ja kui vaja, lõpetab need. Ja muidugi paar bash-skripti — need on hädavajalikud.

Oma testimiskeskkonna loomisele kulus viis nädalat.

Kokkuvõttes tuli igale pull requestile ulatuslik, liitumist blokeeriv kontrollide loetelu:

• ARK-i kogumine;
• Junit-testid;
• Lint;
• Android Studio kontrollid;
• Instrumentatsiooni testid;
• Kuvatõmmise testid.

See takistas palju võimalikke rikkeid. Tehniliselt töötab kõik, kuid arendajad kurtsid, et tulemusi oodati liiga kaua.

Liiga kaua — kui kaua? Me eksportisime andmed Bitbucket'ist ja TeamCity'st analüüsimisse ja mõistsime, et keskmine ooteaeg on 45 minutit. See tähendab, et arendaja ootab, et avades pull request, keskmiselt 45 minutit tulemusi. Minu arvates on see väga palju ja nii ei saa töötada.

Muidugi, me otsustasime kiirendada kõiki meie ehitusi.

Kiirendame

Kui nägime, et ehitused seisavad sageli järjekorras, siis esimesena ostsime juurde riistvara — ulatuslik areng on kõige lihtsam. Ehitused ei seisa enam järjekorras, kuid ooteaeg vähenes vaid veidi, kuna mõned kontrollimised kestavad endiselt liiga kaua.

Eemaldame liiga pikad kontrollid

Meie pidev integratsioon suudab tuvastada selliseid vigu ja probleeme.

• Ei kogu. CI suudab leida kompileerimisviga, kui konfliktsete muudatuste tõttu midagi ei kogu. Nagu ma juba ütlesin, sel juhul ei saa keegi midagi koguda, arendamine seiskub ja kõik on närvis.
• Viga käitumises. Näiteks, kui rakendus kogub, kuid nuppu vajutades kukub kokku või nupp ei reageeri üldse. See on halb, sest selline viga võib kasutajani jõuda.
• Viga kujunduses. Näiteks, nupp reageerib, kuid on 10 pikslit vasakule nihkunud.
• Tehnilise võla suurenemine.

Vaadates seda nimekirja, mõistsime, et kriitilised on ainult esimesed kaks punkti. Selliseid probleeme tahame me esmajärjekorras avastada. Kujunduse ülevaate etapis avastatakse kujunduse vead ja neid on lihtne parandada. Tehnilise võlaga tegelemine nõuab eraldi protsessi ja planeerimist, seetõttu otsustasime seda pull request'is mitte kontrollida.

Selle klassifitseerimise põhjal läbisime kogu kontrollide nimekirja. Tõmbasime Linti läbi ja edastasime selle käivitamise öösse: lihtsalt, et see annaks aru, kui palju probleeme projektis on. Tehnilise võlaga oleme kokku leppinud, et töötame eraldi, ning Android Studio kontrollidest loobusime täielikult. Android Studio Dockeris kontrollide käivitamine kõlab huvitavalt, kuid toob palju ebameeldivusi toetuses. Iga Android Studio versiooni uuendamine - see on võitlus arusaamatute vigadega. Samuti oli raske toetada ekraanikuva teste, kuna biblioteka ei töötanud väga stabiilselt, esines valehäireid. Ekraanikuva teste eemaldati kontrollide nimekirjast.

Kokku oli meil jäänud:

• ARK-i kogumine;
• Junit-testid;
• Instrumentatsiooni testid.

Gradle kaugvahend

Ilma raskete kontrollideta on kõik parem. Kuid täiuslikkusel ei ole piire!

Meie rakendus oli juba jagatud umbes 150 gradle mooduliks. Tüüpiliselt toimib sellisel juhul Gradle kaugvahend hästi ja otsustasime seda proovida.

Gradle remote cache on teenus, mis suudab vahemälu hoida ehitusartefakte eraldi ülesannete jaoks erinevates moodulites. Gradle, selle asemel et koodi tegelikult kompileerida, küsib remote cache'ist HTTP kaudu, kas keegi on juba seda ülesannet täitnud. Kui jah, laadib ta lihtsalt tulemuse alla.

Gradle remote cache'i käivitamine on lihtne, sest Gradle pakub Docker'i kujundust. Suutsime selle teostada kolme tunni jooksul.

Vaja oli lihtsalt käivitada Docker ja kirjutada projektis üks rida. Kuigi see saab kiiresti käivituda, et kõik hästi töötaks, on vajalikul ajakulul üsna palju aega.

Allpool on vahekaart cache misses.

Alguses oli cache'ist möödalaskmise protsent umbes 65. kolme nädala pärast suutsime selle väärtuse langetada 20%-ni. Selgus, et Android rakenduse ülesannete kogumine sisaldab kummalisi transitiivseid sõltuvusi, mille tõttu Gradle jäi vahemälu mööda.

Cache'i kasutuselevõtuga kiirus kasvas märkimisväärselt. Kuid peale ehituse käivitatakse ka instrumentatsiooni teste, mis võivad võtta kaua aega. Võib-olla ei ole mõtet kõiki testide kontrollida iga pull request'i korral. Selle välja selgitamiseks kasutame mõjude analüüsi.

Mõjude analüüs

Pull request'i korral kogume git diff'i ja leiame muudetud Gradle moodulid.

Mõistlik on käivitada ainult need instrumentatsiooni testid, mis kontrollivad muudetud mooduleid ja kõiki mooduleid, mis neist sõltuvad. Naaber moodulite testide käitamine ei ole mõttekas: seal kood ei muutunud ja midagi ei tohi puruneda.

Instrumentatsiooni testide puhul ei ole kõik nii lihtne, kuna need peavad olema rakenduse kõige kõrgemal tasemel moodulis. Kasutasime bait-koodi analüüsile põhinevat heuristikat, et mõista, millise mooduliga iga test on seotud.

Instrumentatsiooni testide töö moderniseerimine, et nad kontrolliksid ainult kaasatud mooduleid, võttis aega umbes kaheksa nädalat.

Kontrollimise kiirendamise meetmed toimisid edukalt. 45 minutist jõudsime umbes 15 minutini. Veerand tundi ootamine build'is on nüüd normaalne.

Aga nüüd on arendajad hakanud kurtma, et neile ei ole selge, millised build'id käivitatakse, kust logsid vaadata, miks build on punane, milline test kukkus ja nii edasi.

Tagasiside probleemid aeglustavad arendust, seega oleme püüdnud tagada võimalikult arusaadava ja üksikasjaliku teabe iga PR ja buildi kohta. Alustasime Bitbucketis PR kommentaaridega, märkides, milline build ebaõnnestus ja miks, ning saatsime adresseeritud sõnumeid Slackis. Lõpuks lõime PR-i juhtpaneeli lehe, kus on kõigi praegu käimasolevate buildide nimekiri ja nende olek: ootel, käimas, ebaõnnestunud või lõpetatud. Saate buildile klõpsata ja pääseda selle logisse.

Üksikasjalikule tagasisidele kulus kuus nädalat.

Plaane

Liigume edasi viimastele uudistele. Tagasiside probleemide lahendamisega tõstsime oma tegevuse uuele tasemele — otsustasime ehitada oma emulaatorite farmi. Kui teste ja emulaatoreid on palju, on nende haldamine keeruline. Lõpuks kolisid kõik meie emulaatorid k8s-klassi, kus ressursside haldamine on paindlik.

Lisaks on veel muid plaane.

• Tagasi Linti (ja muude staatiliste analüüside). Me juba töötame selle suunas.
• Käivitage PR-i blokeerija kõik end-to-end testid kõikide SDK versioonide peal.

Nii et me oleme jälginud Continuous Integrationi arengu ajalugu Avitos. Nüüd tahan anda mõned näpunäited kogenud vaatenurgast.

Nõuanded

Kui ma saaksin anda ainult ühe nõuande, siis see oleks:

Palun olge ettevaatlikud shell-skriptidega!

Bash on väga paindlik ja võimas tööriist, selle abil on mugav ja kiire skripte kirjutada. Kuid sellega võib sattuda lõksu, ja me, kahjuks, sattusime sellesse.

Kõik algas lihtsatest skriptidest, mis käivitati meie build-masinal:

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

Kuid nagu teada, kõik areneb ja keerukamaks ajaga — laseme ühel skriptil teisest käivituda, laseme sinna mõned parameetrid — lõpuks tuli kirjutada funktsioon, mis määrab, millisel bashi sisetase me praegu oleme, et sobitada õiged jutumärgid, nii et see kõik käivituks.

Võite ette kujutada, kui palju ressursse kulus selliste skriptide arendamisele. Soovitan mitte siseneda sellesse lõksu.

Mida võiks selle asemel kasutada?

• Mitsugust skriptimiskeelt. Kirjutamine Pythonis või Kotlin Scriptis on mugavam, sest see on programmeerimine, mitte skriptid.
• Või kirjeldada kogu buildide loogikat Custom gradle ülesannetena oma projekti jaoks.

Otsustasime valida teise variandi ja praegu eemaldame järk-järgult kõik bash-skriptid ning kirjutame palju kohandatud gradle-ülesandeid.

Nõuanne nr 2: hoidke infrastruktuuri koodis.

Mugav on, kui Continuous Integration seadistus ei hoiu UI-interfäänis nagu Jenkins või TeamCity, vaid tekstifailidena otse projekti hoidlas. See tagab versioonikontrolli. Ei ole raske tagasi minna või koguda koodi teises harus.

Skripte saab projektis hoida. Aga mis teha keskkonnaga?

Nõuanne nr 3: Docker aitab keskkonna seadistamisel.

Android-arendajatele aitab see kindlasti, iOS-i puhul kahjuks mitte.

See on lihtsa docker-faili näide, mis sisaldab jdk ja 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

# Laadige alla 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

# Installige Android Build Tool ja raamatukogud
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

Kirjutasin selle docker-faili (ütlen saladuseks, et seda ei pea kirjutama, vaid valmis versiooni saab GitHubist) ja pildi kokku panemisega saate virtuaalse masina, millel saate rakendust koguda ja Junit-testimist käivitada.

Kaks peamist argumenti, miks see on mõttekas: skaliseeritavus ja korduvus. Dockeriga saab kiiresti üles seada tosin ehitustegevust, millel on täpselt sama keskkond nagu eelmisel. See lihtsustab CI-inseneride elu tohutult. Android-sdk't dockerisse tõukamine on väga lihtne, emulaatoritega on veidi keerulisem: natuke peab pingutama (või jälle GitHubist valmis versiooni alla laadima).

Nõuanne nr 4: ärge unustage, et kontrollid ei toimu kontrollide pärast, vaid inimeste jaoks.

Arendajatele on väga tähtis kiire ja, mis kõige tähtsam, arusaadav tagasiside: mis neil katki läks, milline test kukkus läbi, kus build-logi vaadata.

Nõuanne nr 5: olge pragmaatilised Continuous Integration'i arendamisel.

Selgelt mõista, milliseid vigade tüüpe soovite ennetada, kui palju olete valmis ressursse, aega ja masinasaega kulutama. Liiga pikad kontrollid saab näiteks ööseks edasi lükata. Ja nendest, mis avastavad mitte väga olulisi vigu, saab üldse loobuda.

Nõuanne nr 6: kasutage valmis tööriistu.

Praegu on palju ettevõtteid, mis pakuvad pilvepõhist CI-d.

Väikestele meeskondadele on see hea lahendus. Ei ole vaja midagi hallata, lihtsalt maksate natuke raha, kogute oma rakenduse ja isegi käigate instrumentatsioonitestide.

Nõuanne #7: suurtes meeskondades on kasulikum in-house lahendused.

Kuid ühel hetkel, koos meeskonna kasvuga, saavad in-house lahendused tasuvamaks. Nende lahendustega on üks aspekt. Majanduses on seadus kahanemisest: igas projektis muutub iga järgmine täiustamine aina raskemaks ja nõuab üha rohkem investeeringuid.

Majandus kirjeldab kogu meie elu, sealhulgas pidevat integreerimist. Olen koostanud graafiku tööjõu kulude kohta igas etapis meie pideva integreerimise arendamisel.

On näha, et iga täiustamine muutub aina keerulisemaks ja keerulisemaks. Vaadates seda graafikut, võib mõista, et pidevat integreerimist tuleb arendada koos meeskonna suuruse kasvuga. Kahe inimese meeskonnale kulutada 50 päeva sisemise emulaatorite farmi arendamiseks – see pole kõige parem idee. Kuid samas ei tegutseda suure meeskonnaga pideva integreerimise suunal – ka see on halb idee, kuna integreerimise probleemide lahendamiseks, suhtlemise parandamiseks jne kulub veelgi rohkem aega.

Alustasime sellest, et automatiseerimine on vajalik, sest inimesed on kallid, nad teevad vigu ja on laisad. Kuid automatiseerivad ka inimesed. Seetõttu kehtivad kõik need probleemid ka automatiseerimise kohta.

• Automatiseerimine on kallis. Meenutage tööjõu kulu graafikut.
• Automatiseerimise käigus teevad inimesed vigu.
• Automatiseerimine on mõnikord üsna tülikas, sest nii või naa kõik töötab. Miks veel midagi parandada, miks kogu see pidev integreerimine?

Aga mul on statistika: 20% kogumistest tuvastatakse vead. Ja see ei juhtu seetõttu, et meie arendajad kirjutavad halba koodi. See toimub seetõttu, et arendajad on kindlad, et kui nad teevad vea, ei jõua see develop'i, vaid tuvastavad selle automatiseeritud kontrollid. Seega saavad arendajad kulutada rohkem aega koodi kirjutamisele ja huvitavatele asjadele, mitte mitte kohapeal midagi käima ja kontrollima.

Tegelege pideva integreerimisega. Kuid mõistlikult.

Muide, Nikolai Nesterov mitte ainult ei tee lahedaid ettekandeid, vaid ta kuulub ka programmikomiteesse AppsConf ja aitab teistel valmistada teie jaoks sisukaid esitlusi. Lähima konverentsi programmi täiuslikkust ja kasulikkust saab hinnata teemade kaudu ajakavast. Täiendavate üksikasjade saamiseks tulge 22-23 aprillil Infoprostranstvo.

Allikas: habr.com