Tänapäeval arendatakse enamik tarkvaratooteid meeskondades. Meeskonna arendamise edu tingimusi võib esitada lihtsa skeemina.

Koodi kirjutades peaksite veenduma, et see:

1. Töötab.
2. Ei rikku midagi, sealhulgas teie kolleegide kirjutatud koodi.

Kui mõlemad tingimused on täidetud, siis olete edusamme tegemas. Nende tingimuste lihtsaks kontrollimiseks ja kasulikult edasiviivale teele jäämiseks on välja töötatud pidev integreerimine.

CI on töövoog, kus integreerite oma koodi võimalikult sageli tootekoodi. Ja mitte lihtsalt integreerite, vaid kontrollite pidevalt, et kõik toimib. Kuna tuleb sageli ja palju kontrollida, on mõistlik mõelda automatiseerimise peale. Kõike saab käsitsi kontrollida, kuid seda ei tohiks teha, ja siin on põhjus.

• Inimesed on kallid. Iga programmeerija töötunni hind ületab igasuguste serverite töötunni hinda.
• Inimesed teevad vigu. Seetõttu võivad tekkida olukorrad, kus testid käivitatakse vale haru peal või koostatakse vale kommit testeritele.
• Inimesed on laisad. Aeg-ajalt, kui mul on mõni ülesanne lõpetatud, tekib mul mõte: „Milleks siin üldse midagi kontrollida? Kirjutasin kaks rida — kindlasti kõik töötab!” Mõtlen, et ka mõnel teist võivad sellised mõtted aeg-ajalt pähe tulla. Kuid kontrollida tuleb alati.

Kuidas juurutati ja arendati jätkuvat integreerimist Avito mobiiliviimiste meeskonnas, kuidas jõuti 0-lt 450 kogumiseni päevas, ja milline on build-masinate 200 tunni kogumine päevas, räägib Nikolai Nesterov (nnesterov) — osaleja kõigis CI/CD Android-rakenduse evolutsiooniliste muutuste juures.

Jutustus põhineb Android-meeskonna näitel, kuid enamik lähenemisviise on rakendatavad ka iOS-i puhul.

Kaua aega tagasi töötas Avito Android-meeskonnas vaid üks inimene. Talle ei olnud mingil juhul vajalik mitte midagi jätkuva integreerimise kohta: kellegagi ei olnud vaja integreeruda.

Kuid rakendus kasvas, uusi ülesandeid tuli järjest juurde ja seega kasvas ka meeskond. Ühel hetkel tuli aeg, mil oli vajalik koodi integreerimise protsess formaalsemaks muuta. Otsustati kasutada Git flow'd.

Git flow kontseptsioon on teada: projektis on üks ühine haru develop, ja iga uue funktsiooni jaoks loovad arendajad eraldi haru, commitivad sinna, pushivad, ja kui nad soovivad oma koodi haru develop'iga ühendada, avavad pull request'i. Teadmiste vahetamiseks ja lähenemiste aruteluks oleme sisse viinud koodivaatluse, mis tähendab, et kolleegid peavad üksteise koodi kontrollima ja kinnitama.

Kontrollid

Koodi vaatamine on suurepärane, kuid mitte piisav. Seetõttu on sisse viidud automaatsed kontrollid.

• Esmalt kontrollime ARK komponentide koostamist.
• Palju Junit teste.
• Arvutame koodikatvuse, kuna käivitame teste.

Et mõista, kuidas neid kontrolle käivitada, vaatame Avito arendusprotsessi.

Skeemiliselt võib selle esitada järgmiselt:

• Arendaja kirjutab koodi oma sülearvutis. Integreerimiskontrolle saab käivitada otse siin — kas commit hook'i abil või lihtsalt taustal kontrolle käivitades.
• Pärast seda, kui arendaja on koodi pushinud, avab ta pull request'i. Selleks, et tema kood jõuaks haru develop, peab ta läbima koodivaatluse ja koguma vajaliku arvu kinnitusi. Siin saab sisse lülitada kontrollid ja build'id: seni, kuni kõik build'id ei ole edukad, ei saa pull request'i ühendada.
• Pärast seda, kui pull request on kokku sulandatud ja kood on arenduses, saab valida sobiva aja: näiteks öösel, kui kõik serverid on vabad, ja käivitada teste nii palju kui võimalik.

Testide käitamine oma sülearvutis ei olnud kellelegi meeltmööda. Kui arendaja on funktsionaalsuse lõpetanud, soovib ta selle kiiresti osutada ja avada pull requesti. Kui sel hetkel käivitatakse mingeid pikki teste, on see mitte ainult ebameeldiv, vaid pidurdab ka arendust: seni kuni sülearvuti midagi testib, ei ole seal normaalselt tööd teha.

Öösel testide käitamine oli meile väga meeltmööda, sest aega ja servereid on palju, võib vabalt testida. Kuid kahjuks, kui funktsionaalsuse kood on arenduses, on arendajal tõenäoliselt palju vähem motivatsiooni parandada CI leidnud vigu. Aeg-ajalt tabasin end mõttelt, kui vaatasin hommikusest raportist üles leitud vigu, et parandan need kunagi hiljem, sest praegu on Jira's äge uus ülesanne, mida tahaks kohe tegema hakata.

Kui teste takistavad pull requesti, on motivatsioon piisav, sest seni kuni ehitused ei ole roheline, ei pääse kood arendusse ja seega ei saa ülesanne lõpuleviidud.

Lõpuks valisime sellise strateegia: öösel teeme võimalikult palju kontrollerite teste ja kõige kriitilisemad ning, mis kõige tähtsam, kiireimad, запускаем pull request'is. Kuid me ei peatu sellega — samal ajal optimeerime kontrollide läbimise kiirus, et viia need öörežiimist üle pull request'i kontrollimiseks.

Sel ajal läbisid kõik meie kogumid piisavalt kiiresti, seega lülitasime pull request'i blokkerisse AРК kogumise, Junit-testid ja koodi katvuse kalkulatsiooni. Lülitasime sisse, mõtlesime ja loobusime koodi katvusest, kuna arvasime, et see pole meile vajalik.

Kogu põhisi CI seadistamiseks kulus meil kaks päeva (siin ja edaspidi on ajakava umbkaudne, vajalik ulatuse mõistmiseks).

Pärast seda hakkasime mõtlema edasi — kas me kontrollime üldse õigesti? Kas me käivitame kogumid pull request'is õigesti?

Käivitame kogumise viimase haru commit'i peal, mille alusel pull request avati. Kuid selle commit'i kontrollid võivad näidata vaid, et kood, mille arendaja kirjutas, töötab. Kuid need ei tõenda, et ta midagi rikub. Tegelikult tuleks kontrollida haru develop seisundit pärast seda, kui funktsioon on sinna viidud.

Selle jaoks kirjutasime me 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 kõige värskemad muudatused develop'ist ja liidetakse praegusesse haru. Me lisasime skripti premerge.sh kõigi ehituste esimeseks sammuks ning hakkasime kontrollima täpselt seda, mida me tahame, nimelt integratsiooni.

Probleemide lokaliseerimiseks, lahenduse leidmiseks ja selle skripti kirjutamiseks kulus kolm päeva.

Rakendus arenes, ülesandeid tuli üha rohkem, meeskond kasvas ja premerge.sh hakkas meid mõnikord alt vedama. Develop'isse tungisid vastuolulised muudatused, mis lõhkusid ehituse.

Näide sellest, kuidas see juhtub:

Kaks arendajat hakkavad samal ajal töötama funktsioonide A ja B kallal. Funktsiooni A arendaja leiab projektist kasutamata funktsiooni answer() ja, nagu hea skaut, eemaldab selle. Samal ajal lisab funktsiooni B arendaja oma harusse uue väljakutse sellele funktsioonile.

Arendajad lõpetavad töö ja avavad samal ajal pull request'i. Käivitatakse ehitused, premerge.sh kontrollib mõlemat pull request'i arvestades värsket olukorda develop'is — kõik kontrollid on rohelised. Pärast seda liidetakse funktsiooni A pull request, liidetakse funktsiooni B pull request… Bum! Develop läheb katki, sest koodis on kutsumine mitteeksisteerivale funktsioonile.

Kui develop ei suuda töötada, on see kohalik katastroof. Kogu meeskond ei suuda midagi koguda ega testimiseks anda.

Nii juhtus, et olen sagedamini tegelenud infrastruktuuri ülesannetega: analüüs, võrk, andmebaasid. See tähendab, et just mina kirjutasin need funktsioonid ja klassid, mida teised arendajad kasutavad. Seetõttu sattusin tihti sarnastesse olukordadesse. Mul oli isegi ühel perioodil selline pilt.

Kuna see ei rahuldanud meid, hakkasime uurima võimalusi, kuidas seda ennetada.

Kuidas mitte katkestada develop

Esimene variant: kõik pull requestid (PR) ümber kompileerida, kui develop'i värskendatakse. Kui meie näites PR funktsiooni A läheb esimesena develop'i, siis kompileeritakse PR funktsiooni B ümber ning seega ei lähe testimised läbi, kuna tekib kompileerimisviga.

Et mõista, kui kaua selleks aega kulub, vaatame kahte PR-i näidet. Avame kaks PR-i: kaks ehitust, kaks testide käivitamist. Pärast seda, kui esimene PR on devlapi sisse voolu läinud, tuleb teine ümber kompileerida. Kokku kulub kahe PR-i jaoks kolm testimise käivitamist: 2 + 1 = 3.

Põhimõtteliselt on kõik normaalne. Kuid me vaatasime statistikat ja meie meeskonnas oli tavaline olukord, kus oli 10 avatud PR-i, ning seega kontrollide arv on summa: 10 + 9 +… + 1 = 55. See tähendab, et 10 PR-i aktsepteerimiseks tuleb kokku 55 korda uuesti üles ehitada. Ja see on ideaalne olukord, kus kõik kontrollid läbivad esimese korraga, ja keegi ei ava lisanduvaid pull request'e, samal ajal kui seda kümmet töödeldakse.

Kujutage ette end arendajana, kes peab esimesena nuppu 'merge' vajutama, sest kui seda teeb naaber, tuleb oodata, kuni kõik kogumised uuesti läbi käivad... Ei, nii ei saa, see takistab tõsiselt arendust.

Teine võimalus: koguda pull request pärast koodide ülevaatust. See, you open a pull request, gather the necessary approvals from colleagues, fix what needs to be fixed, and then run the builds. If they are successful, the pull request is merged with develop. In this case, there are no additional restarts, but feedback slows down significantly. As a developer, when I open a pull request, I want to see immediately if it builds. For example, if a test fails, it needs to be fixed quickly. If the build is delayed, feedback slows down, which affects the entire development process. This was also unsatisfactory for us.

In the end, only the third option remained — bicycle. All our code, all our source files are stored in a repository on the Bitbucket server. Accordingly, we had to develop a plugin for Bitbucket.

See plugina ühiselt pull requestide sulgemise mehhanismi. Algus on tavaline: pull request avatakse, kõik kogumised käivitatakse, toimub koodide ülevaatus. Kuid pärast seda, kui koodide ülevaatus on läbitud ja arendaja otsustab "ühendada" nuppu vajutada, kontrollib plugina, millise oleku korral arendustiim testid käivitati. Kui pärast kogumisi on arendussi mõni uuendus toimunud, ei luba plugina sellist pull requesti põhiharusse liita. Ta lihtsalt käivitab kogumised uuesti värskema arendusseisu suhtes.

Meie konfliktsete muudatuste näites ei lähe sellised kogumised läbi kompileerimise veateate tõttu. Vastavalt on arendaja B funktsionaalsuse koodi parandamise kohustuses, et uuesti testida, siis plugina rakendab automaatselt pull requesti.

Enne selle plugina rakendamist oli meil keskmiselt 2.7 testimist ühe pull requesti kohta. Plugina rakendamisega tõusis see 3.6 testimiseni. See meid rahuldas.

Tuleb märkida, et sellel pluginal on puudus: see käivitab ehituse uuesti ainult üks kord. See tähendab, et jääb väike aken, mille kaudu võivad arengusse sattuda konfliktivad muudatused. Kuid selle tõenäosus on madal, ja me nägime raskust koguste ja purunemise tõenäosuse vahel. Kahte aastat jooksul on see toimunud vaid üks kord, seega ilmselt mitte asjata.

Esimese versiooni kirjutamine Bitbucketile võttis meil kaks nädalat.

Uued kontrollid

Samal ajal jätkas meie meeskond kasvu. Meile lisandusid uued kontrollid.

Me mõtlesime: miks parandada vigu, kui neid saab ennetada? Ja seetõttu rakendasime koodi staatiline analüüs. Alustasime lintiga, mis on osa Android SDK-st. Kuid sel ajal ei osanud see üldse töötada Kotlin-koodiga, samas kui meie rakendusest oli juba 75% kirjutatud Kotlinis. Seetõttu lisasime lintile integreeritud Android Studio kontrolle.

Selleks tuli meeleheitlikult tegutseda: võtta Android Studio, pakkida see Dockerisse ja käivitada CI-s virtuaalse monitoriga, et ta arvestaks, et see töötab reaalses sülearvutis. Kuid see töötas.

Samuti alustasime sel ajal palju instrumentatsiooniteste ja rakendasime screenshot-teste.. See on hetk, mil genereeritakse referentskuva eraldi väikesele vaatele, ja test seisneb selles, et vaate ekraanipilt võetakse ja võrreldakse referentsiga piksel-piksel. Kui on erinevus, tähendab see, et kuskil on paigutus vale või stiilides on midagi valesti.

Kuid instrumentatsioonitestid ja ekraanipiltide testid tuleb käivitada seadmetes: emulaatoritel või reaalsetel seadmetel. Arvestades, et teste on palju ja need käivitatakse tihti, on vajalik terve farm. Oma farmi rajamine on liiga töömahukas, seega leidsime valmis lahenduse — Firebase Test Lab.

Firebase Test Lab

Valiti, kuna Firebase on Google'i toode, mis tähendab, et see peaks olema usaldusväärne ja tõenäoliselt mitte kunagi surema. Hinnad on taskukohased: 5 $ tunni eest reaalset seadet, 1 $ tunni eest emulaatorit.

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

Kuid meeskond jätkas kasvu ja kahjuks alustas Firebase meid alt vedama. Sel ajal ei olnud tal mingit SLA-d. Mõnikord pidi Firebase ootama, kuni vajalik arv seadmeid testimiseks vabastatakse, mitte ei alustanud nende täitmist kohe, nagu me soovisime. Ooteaeg järjekorras kestis kuni poole tunni, mis oli väga pikk. Instrumentatsiooni testid käidi läbi iga PR-i juures, viivitused pidurdasid arendust ja seejärel tuli veel kuu arve suure summa eest. Kokkuvõttes otsustati Firebase'ist loobuda ja hakata in-house arendama, kuna meeskond oli piisavalt suur.

Docker + Python + bash

Võtsime Dockeri, panime sinna emulaatorid, kirjutasime lihtsa programmi Pythonis, mis vajalikul hetkel käivitab vajaliku arvu emulaatoreid soovitud versioonis ja kui vaja, peatab need. Ja loomulikult paar bash-skripti — kuidas siis ilma nendeta?

Oma testimisruumi loomiseks kulus viis nädalat.

Tulemuseks oli igale pull request'ile laialdane, sulgemise blokeeriv kontrollide loetelu:

• ARK kogumine;
• Junit-testid;
• Lint;
• Android Studio kontrollid;
• Instrumentatsiooni testid;
• Kuvapilditesti.

See vältis palju võimalikke rikkeid. Tehniliselt kõik töötas, kuid arendajad kaebasid, et tulemuste ootamine on liiga pikk.

Liiga pikk — kui kaua see kestab? Laadime Bitbucketist ja TeamCityst andmed analüüsi süsteemi ja saame aru, et keskmine ootamisaeg on 45 minutit. See tähendab, et arendaja ootab keskmiselt oma pull request'i tulemusi 45 minutit. Minu arvates on see väga palju ja nii ei saa töötada.

Muidugi otsustasime kiirendada kõiki meie build'e.

Aktiivselt parandame

Nägin, et buildid jäävad sageli järjekorda, seega ostsime kõigepealt rohkem riistvara — ekstensiivne areng on kõige lihtsam. Buildid lakkasid järjekorras seismast, kuid ootamisaeg vähenes vaid veidi, sest mõned kontrollid olid iseenesest väga pikad.

Eemaldame liiga pikad kontrollid

Meie pidev integreerimine suudab selliseid vigu ja probleeme tuvastada.

• Ei koondata. CI suudab tabada kompileerimviga, kui konfliktsete muudatuste tõttu midagi ei koo. Nagu ma juba ütlesin, siis tollal ei suuda keegi midagi kokku panna, areng seiskub ja kõik on ärevuses.
• Käitumise viga. Näiteks, kui rakendus käivitatakse, kuid nuppu vajutades see kukub või nupp ei reageeri üldse. See on halb, sest selline viga võib jõuda kasutajani.
• Disaini viga. Näiteks, nupp reageerib, kuid on 10 pikslit vasakule nihkunud.
• Tehnilise võla suurenemine.

Seda nimekirja vaadates mõistsime, et kriitilised on vaid esimesed kaks punkti. Selliseid probleeme soovime esmajärjekorras tuvastada. Disaini vigade avastamine toimub disaini ülevaate etapis ja seal on neid lihtne parandada. Tehnilise võla haldamine nõuab eraldi protsessi ja planeerimist, seetõttu otsustasime seda pull request'il mitte kontrollida.

Selle klassifitseerimise põhjal läbisime kogu kontrollide nimekirja. Välistasime Linti ja lükkasime selle käivitamise ööse: lihtsalt et saada aruandlust, kui palju probleeme projektis on. Tehnilise võlaga oleme kokku leppinud töötama eraldi, ja Android Studio kontrolle oleme täielikult loobunud. Android Studio Dockeris vigade kontrollimiseks kõlab huvitavalt, kuid toob palju ebamugavusi ühilduvuses. Iga Android Studio versiooni uuendus on võitlus arusaamatute tõrgetega. Samuti oli ekraanipildi testide toetamine keeruline, sest teek toimis ebastabiilselt ja esines valehäiresid. Ekraanipildi teste eemaldati kontrollide nimekirjast.

Lõpuks jäid meil alles:

• ARK kogumine;
• Junit-testid;
• Instrumentatsioonitestid.

Gradle kaugvälimälu

Ilma keeruliste kontrollideta on kõik parem. Kuid täiustamisel ei ole piire!

Meie rakendus oli juba jagatud umbes 150 gradle mooduliks. Tavaliselt töötab sellisel juhul Gradle kaugvälimälu hästi, ja otsustasime seda proovida.

Gradle kaugvälimälu on teenus, mis suudab kahetseda kogumise artefakte eraldi ülesannete jaoks erinevates moodulites. Gradle, selle asemel et reaalselt koodi kompileerida, küsib HTTP kaudu kaugvälimälult, kas keegi on selle ülesande juba täitnud. Kui jah, siis laadib lihtsalt tulemuse alla.

Gradle kaugvälimälu käivitamine on lihtne, sest Gradle pakub Docker'i pilti. Meil õnnestus seda teha kolme tunni jooksul.

Kogu, mida oli vaja, oli Docker käivitamine ja projekti ühele reale kirjutamine. Kuigi selle kiirelt tööle saamine on võimalik, kulub selle tõrgeteta toimimiseks siiski rohkelt aega.

Allpool on cache misside graafik.

Alguses oli cache'i möödalaskmise protsent umbes 65. Kolme nädala pärast suudeti see väärtus viia 20%ni. Selgus, et Android rakenduse kogutavad ülesanded omavad kummalisi transitiivseid sõltuvusi, mistõttu Gradle jättis cache'i kõrvale.

Cache'i ühendamine kiirendas meie ehitust märgatavalt. Kuid lisaks ehitusele käivad ka instrumentation testid, ja need võtavad kaua aega. Võib-olla ei pea kõiki teste jooksutama iga pull request'i puhul. Selle selgitamiseks kasutame impaktilahendust.

Impaktilahendus

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

On mõttekas käivitada ainult need instrumentation testid, mis kontrollivad muudetud mooduleid ja kõiki mooduleid, mis neist sõltuvad. Kõrvalloodud moodulite teste pole mõtet käivitada: seal ei ole kood muutunud, seega ei saa midagi puruneda.

Instrumentation testidega ei ole kõik nii lihtne, kuna need peavad olema kõige kõrgema taseme rakenduse moodulis. Kasutasime heuristikast bytecode'i analüüsi, et mõista, millisele moodulile iga test kuulub.

Instrumentation testide täiendamine, et nad kontrolliksid ainult aktiivseid mooduleid, kestis umbes kaheksa nädalat.

Kontrollide kiirusmeetmed töötasid edukalt. 45 minutist oleme jõudnud umbes 15 minutini. Veerand tundi oodata buildi on nüüd normaalne.

Aga nüüd hakkasid arendajad kurtma, et nad ei saa aru, millised buildid käivitatakse, kus vaadata logi, miks build on punane, milline test on kukkunud jne.

Tagasiside probleemid aeglustavad arendust, seetõttu püüdsime pakkuda maksimaalselt arusaadavat ja detailset teavet iga PR ja buildi kohta. Alustasime Bitbucketis PR-i kommentaaridega, märkides, milline build kukkus ja miks, saatsime adresseeritud sõnumeid Slackis. Lõpuks tegime PR-i jaoks armatuurlaud, kus on loetelu kõikidest buildidest, mis praegu käivitatakse, ja nende olekust: ootel, käivitatakse, kukkus või lõppes. Buildile saab klikkida ja vaadata selle logi.

Detailide tagasisidele kulus kuus nädalat.

Tunniplaanid

Liigume edasi uusima loo juurde. Tagasiside probleemi lahendamisega jõudsime uuele tasemele — otsustasime luua oma emulaatorite farmi. Kui teste ja emulaatoreid on palju, on nende haldamine keeruline. Lõppkokkuvõttes on kõik meie emulaatorid kolitud k8s-klastrisse paindliku ressursihaldusega.

Lisaks on veel teisi plaane.

• Tagasta Lint (ja muud staatilised analüüsid). Me juba töötame selle suunas.
• Käivitada PR-blokeerijana kõik end-to-end testid kõikide SDK versioonide jaoks.

Nii oleme jälginud Continuous Integration'i 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 ettevaatlik shell-skriptide suhtes!

Bash on väga paindlik ja võimas tööriist, sellel on mugav ja kiire skriptide kirjutamine. Kuid selle sisse võib langeda lõksu, ja me, kahjuks, langesime sellesse.

Kõik algas lihtsatest skriptidest, mida käitati meie ehitusmasinatel:

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

Kuid nagu teada, areng ja keerukus on ajaga laiemaks läinud — laseme ühe skripti teise seest välja, edastame sinna mingid parameetrid — lõppkokkuvõttes pidime kirjutama funktsiooni, mis määrab, millisel bash-i sügaval tasemel me parasjagu oleme, et sisestada õige jutumärk, et kõik toimiks.

Kas saate ette kujutada nende skriptide arendamiseks vajalikke ressursse? Soovin mitte sattuda sellesse lõksu.

Mida saab kasutada asendajana?

• Iga skripti keelt. Kirjutamine Pythonis või Kotlin Scriptis on mugavam, sest see on programmeerimine, mitte skriptid.
• Või kirjeldada kogu build-loogikat Custom gradle tasks teie projekti jaoks.

Meie otsustasime valida teise võimaluse ja praegu eemaldame järk-järgult kõik bash-skriptid ning kirjutame palju kohandatud gradle-tasks.

nõuanne nr 2: hoida infrastruktuur koodina.

On mugav, kui pideva integreerimise seadistamine ei ole Jenkins, TeamCity jm kasutajaliidese kaudu, vaid tekstifailide kujul otse projekti hoidlas. See tagab versioonihalduse. Tagasiviimine või koodi kogumine teisel harul ei ole keeruline.

Skripte saab hoida projektis. Aga mis teha keskkonnaga?

nõuanne nr 3: keskkonnas võib aidata Docker.

Androidi arendajatele on see kindlasti kasuks, iOSi jaoks kahjuks ei ole.

See on näide lihtsast docker-failist, 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

# Laadi 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

# Paigalda Android Build Tool ja teegid
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 (salaja ütlen, et seda ei ole vaja ise kirjutada, saab valmis võtta GitHubist) ja pildi kokku panemisega saate virtuaalse masina, millel saate rakendust koostada ja Junit teste käivitada.

Kaks peamist argumenti, miks see mõistlik on: skaleeritavus ja korduvus. Dockerit kasutades saab kiiresti üles tõsta kümneid ehitusagensid, millel on täpselt sama keskkond nagu eelneval. See teeb CI-inseneride elu oluliselt kergemaks. Android-sdk pakkimine Dockerisse on üsna lihtne, emulaatoritega on natuke keerulisem: tuleb veidi vaeva näha (või laadida GitHubist valmis lahendus).

Nõuanne nr 4: ärge unustage, et kontrolle tehakse mitte kontrollide pärast, vaid inimeste jaoks.

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

Nõuanne nr 5: olge pragmaatilised pideva integratsiooni arendamisel.

Selgelt mõistke, milliseid tõrkeid soovite ära hoida, kui palju olete valmis ressursse, aega ja masina aega kulutama. Liiga pikaajalised kontrollid võib näiteks ööseks üle kanda. Ja nende seast, mis püüavad mitte eriti olulisi vigu, tasub täielikult loobuda.

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

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

Väikeste meeskondade jaoks on see head lahendus. Pole vaja midagi toetada, lihtsalt maksate veidi raha, koguge oma rakendus ja isegi jooksutage instrumentatsiooni teste.

Nõuanne nr 7: suure meeskonna jaoks on kasulikumad in-house lahendused.

Kuid varem või hiljem, meeskonna suurenedes, hakkavad in-house lahendused olema kasumlikumad. Nende lahendustega on üks aspekt. Majanduses on kahanemise seadus: igas projektis saab iga järgmise täiustuse tegemine järjest keerulisemaks, nõudes üha rohkem investeeringuid.

Majandus kirjeldab kogu meie elu, sealhulgas pidevat integreerimist. Olen koostanud diagrammi tööjõukulu kohta iga etapi kohta meie pideva integreerimise arendamisel.

On näha, et iga täiustuse saavutamine muutub järjest keerulisemaks. Seda diagrammi vaadates on võimalik mõista, et pidevat integreerimist tuleb arendada koos meeskonna suuruse kasvuga. Kahe inimese meeskond on 50 päeva investeerimine sisemiste emulaatorite talu arendamisse üsna tobe idee. Kuid sama halb idee on ka suurte meeskondade puhul pideva integreerimisega mitte tegeleda, kuna integraatsiooni probleemide, suhtlemise parandamise jne tegelemine võtab veel rohkem aega.

Alustasime tõdemusega, et automatiseerimine on vajalik, kuna inimesed on kallid, nad teevad vigu ja kipuvad olema laisikud. Kuid automatiseerimise teevad samuti inimesed. Seetõttu kehtivad kõik need probleemid ka automatiseerimise kohta.

• Automatiseerimine on kallis. Pidage meeles tööjõu kulude graafikut.
• Automatiseerimise käigus teevad inimesed vigu.
• Mõnikord on automatiseerimine väga tüütu, kuna kõik töötab niigi. Miks veel midagi parandada, miks kogu see pidev integreerimine?

Aga mul on statistika: 20%-l ehitustest tuvastatakse vigu. See ei juhtu mitte seetõttu, et meie arendajad kirjutavad halba koodi. See toimub seetõttu, et arendajad usuvad, et kui nad teevad mõne vea, siis see ei pääse develop'i. Automaatkontrollid püüavad selle kinni. Seega saavad arendajad kulutada rohkem aega koodi kirjutamisele ja huvitavatele asjadele ning mitte midagi kohalikult jooksutada ja kontrollida.

Tegelege pideva integreerimisega. Kuid mõõdukalt.

Muide, Nikolai Nesterov mitte ainult ei tee lahedaid ettekandeid, vaid kuulub ka programmikomiteesse, AppsConf ja aitab teistel valmistada teile sisukaid esinemisi. Tulevase konverentsi programmi täielikkust ja kasulikkust saab hinnata teemade järgi kava. Ja üksikasjade saamiseks tulge 22.-23. aprillil Infopinda.

Allikas: habr.com