Tänapäeval töötatakse enamik tarkvaratooteid välja meeskondlikult. Eduka meeskonna arendamise tingimusi saab esitada lihtsa diagrammi kujul.

Kui olete koodi kirjutanud, peate veenduma, et see:

1. Работает.
2. See ei riku midagi, sealhulgas teie kolleegide kirjutatud koodi.

Kui mõlemad tingimused on täidetud, siis olete teel edu poole. Nende tingimuste hõlpsaks kontrollimiseks ja tulusalt teelt mitte kõrvale kaldumiseks tulime välja Continuous Integration.

CI on töövoog, mille käigus integreerite oma koodi nii sageli kui võimalik üldisesse tootekoodi. Ja te mitte ainult ei integreeri, vaid kontrollite ka pidevalt, et kõik töötab. Kuna kontrollida tuleb palju ja sageli, tasub mõelda automatiseerimisele. Saate kõike käsitsi kontrollida, kuid te ei tohiks seda teha, ja siin on põhjus.

• Kallid inimesed. Iga programmeerija töötund on kallim kui mis tahes serveri töötund.
• Inimesed teevad vigu. Seetõttu võib tekkida olukordi, kui testid viidi läbi valel harul või testijate jaoks koostati vale kohustus.
• Inimesed on laisad. Aeg-ajalt, kui mõne ülesande lõpetan, tekib mõte: “Mida siin kontrollida on? Kirjutasin kaks rida - kõik töötab! Ma arvan, et mõnel teist on ka mõnikord sellised mõtted. Kuid peate alati kontrollima.

Kuidas Avito mobiiliarendusmeeskonnas rakendati ja arendati pidevat integratsiooni, kuidas nad ehitasid 0-lt 450-le päevas ja kuidas ehitatakse masinaid kokku 200 tundi päevas, ütleb Nikolai Nesterov (nnesterov) on osaline kõigis CI/CD Androidi rakenduse evolutsioonilistes muudatustes.

Lugu põhineb Androidi käsu näitel, kuid enamik lähenemisviise on rakendatavad ka iOS-is.

Kunagi töötas üks inimene Avito Androidi meeskonnas. Definitsiooni järgi ei vajanud ta pidevast integratsioonist midagi: polnud kellegagi integreeruda.

Kuid rakendus kasvas, üha uusi ülesandeid ilmus ja meeskond kasvas vastavalt. Mingil hetkel on aeg koodide integreerimise protsess ametlikumalt paika panna. Otsustati kasutada Git voolu.

Git flow kontseptsioon on hästi teada: projektil on üks ühine arendusharu ja iga uue funktsiooni jaoks lõikavad arendajad eraldi haru, pühenduvad sellele, lükkavad ja kui nad soovivad oma koodi arendusharuga liita, avavad tõmba taotlus. Teadmiste jagamiseks ja lähenemisviiside arutamiseks võtsime kasutusele koodiülevaatuse, st kolleegid peavad üksteise koodi kontrollima ja kinnitama.

Kontrollid

Silmaga koodi nägemine on lahe, kuid mitte piisav. Seetõttu võetakse kasutusele automaatne kontroll.

• Kõigepealt kontrollime ARKi koost.
• Palju Juniti testid.
• Arvestame koodi levialaga, kuna teeme teste.

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

Seda saab skemaatiliselt kujutada järgmiselt:

• Arendaja kirjutab oma sülearvutisse koodi. Integratsioonikontrolli saate käivitada siinsamas – kas sidumiskonksuga või lihtsalt taustal.
• Pärast seda, kui arendaja on koodi lükanud, avab ta tõmbetaotluse. Et selle kood arendusharusse jõuaks, on vaja läbida koodi ülevaatus ja koguda vajalik arv kinnitusi. Siin saate lubada kontrollid ja järgud: kuni kõik järgud on edukad, ei saa tõmbamistaotlust liita.
• Pärast tõmbepäringu ühendamist ja koodi lisamist arendusse saate valida sobiva aja: näiteks öösel, kui kõik serverid on vabad, ja käivitada nii palju kontrolle, kui soovite.

Kellelegi ei meeldinud sülearvutis skannimine. Kui arendaja on funktsiooni lõpetanud, soovib ta seda kiiresti edasi lükata ja tõmbetaotluse avada. Kui praegu käivitatakse mõni pikk kontroll, pole see mitte ainult meeldiv, vaid aeglustab ka arengut: kui sülearvuti midagi kontrollib, pole sellega võimalik normaalselt töötada.

Meile väga meeldis öösel tšekke teha, sest aega ja servereid on palju, saab ringi kolada. Kuid kahjuks on funktsioonikoodi arendamise ajal arendajal palju vähem motivatsiooni CI leitud vigu parandada. Tabasin end perioodiliselt mõtlemast, kui vaatasin kõiki hommikuaruandest leitud vigu, et parandan need kunagi hiljem, sest nüüd on Jiras uus lahe ülesanne, mida tahan lihtsalt tegema hakata.

Kui kontrollid blokeerivad tõmbetaotluse, siis on motivatsiooni piisavalt, sest seni, kuni buildid ei muutu roheliseks, ei satu kood arendusse, mis tähendab, et ülesannet ei täideta.

Selle tulemusel valisime järgmise strateegia: käivitame öösel maksimaalse võimaliku kontrollikomplekti ja käivitame tõmbetaotlusel neist kõige kriitilisemad ja mis kõige tähtsam - kiiremad. Kuid me ei piirdu sellega – paralleelselt optimeerime kontrollide kiirust, et viia need öörežiimist üle päringu kontrollimiseks.

Sel ajal said kõik meie ehitused üsna kiiresti valmis, nii et tõmbasime tõmbepäringu blokeerijana lihtsalt ARK-i ehituse, Juniti testid ja koodikatte arvutused. Lülitasime selle sisse, mõtlesime selle üle ja loobusime koodi levialast, kuna arvasime, et meil pole seda vaja.

Põhilise CI täielikuks seadistamiseks kulus meil kaks päeva (edaspidi on ajaline hinnang ligikaudne, vajalik mastaabi jaoks).

Pärast seda hakkasime edasi mõtlema – kas me üldse kontrollime õigesti? Kas me käitame tõmbetaotlusi õigesti?

Alustasime ehitamist selle haru viimaselt kinnistamisel, millest tõmbamistaotlus avati. Kuid selle kohustuse testid näitavad ainult seda, et arendaja kirjutatud kood töötab. Kuid need ei tõesta, et ta midagi ei rikkunud. Tegelikult peate kontrollima arendusharu olekut pärast seda, kui funktsioon on sellesse liidetud.

Selleks kirjutasime lihtsa bash-skripti premerge.sh:

#!/usr/bin/env bash

set -e

git fetch origin develop

git merge origin/develop

Siin tõmmatakse kõik arenduse viimased muudatused lihtsalt üles ja liidetakse praeguse haruga. Lisasime skripti premerge.sh esimese sammuna kõikidesse järgudesse ja hakkasime täpselt kontrollima, mida me tahame, st. integratsiooni.

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

Rakendus arenes, ülesandeid ilmus üha rohkem, meeskond kasvas ja premerge.sh hakkas meid mõnikord alt vedama. Developis olid vastuolulised muudatused, mis katkestasid ehituse.

Näide selle kohta, kuidas see juhtub:

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

Arendajad lõpetavad oma töö ja avavad samal ajal tõmbetaotluse. Järgid käivitatakse, premerge.sh kontrollib mõlemat tõmbetaotlust viimase arendusoleku kohta – kõik kontrollid on rohelised. Pärast seda liidetakse funktsiooni A tõmbetaotlus, funktsiooni B tõmbetaotlus... Buum! Develop katkeb, kuna arenduskood sisaldab kutset olematule funktsioonile.

Kui see ei arene, siis areneb kohalik katastroof. Kogu meeskond ei saa midagi koguda ja testimiseks esitada.

Juhtus nii, et tegelesin kõige sagedamini infrastruktuuri ülesannetega: analüüs, võrk, andmebaasid. See tähendab, et mina kirjutasin need funktsioonid ja klassid, mida teised arendajad kasutavad. Seetõttu sattusin väga sageli sarnastesse olukordadesse. Mul oli see pilt isegi mõnda aega rippumas.

Kuna see meile ei sobinud, hakkasime uurima võimalusi, kuidas seda vältida.

Kuidas mitte murda arendada

Esimene võimalus: arendage värskendamisel uuesti kõik tõmbamistaotlused. Kui meie näites on tõmbepäring funktsiooniga A esimene, mis arendusse kaasatakse, ehitatakse funktsiooni B tõmbepäring ümber ja vastavalt sellele ka kontroll ebaõnnestub kompileerimisvea tõttu.

Et mõista, kui kaua see aega võtab, vaadake näidet kahe PR-ga. Avame kaks PR-d: kaks ehitamist, kaks kontrolli. Pärast seda, kui esimene PR on arenduseks liidetud, tuleb teine ​​ümber ehitada. Kokku nõuavad kaks PR-d kolme kontrolli: 2 + 1 = 3.

Põhimõtteliselt on kõik korras. Kuid me vaatasime statistikat ja tüüpiline olukord meie meeskonnas oli 10 avatud PR-i ja siis on kontrollide arv progressi summa: 10 + 9 +... + 1 = 55. See tähendab, et aktsepteerida 10 PR-id, peate 55 korda ümber ehitama. Ja see on ideaalses olukorras, kui kõik kontrollid läbivad esimest korda, kui keegi ei ava nende tosina töötlemise ajal täiendavat tõmbamistaotlust.

Kujutage ette end arendajana, kes peab esimesena klõpsama nupul "ühenda", sest kui naaber seda teeb, siis peate ootama, kuni kõik ehitused uuesti läbi saavad... Ei, see ei tööta , see aeglustab tõsiselt arengut.

Teine võimalik viis: koguge pärast koodi ülevaatamist tõmbamistaotlusi. See tähendab, et avate tõmbamistaotluse, kogute kolleegidelt nõutava arvu kinnitusi, parandate vajaliku ja käivitate seejärel järgud. Kui need on edukad, liidetakse tõmbetaotlus arenduseks. Sel juhul täiendavaid taaskäivitusi ei toimu, kuid tagasiside aeglustub oluliselt. Kui avan tõmbetaotluse, tahan arendajana kohe näha, kas see töötab. Näiteks kui test ebaõnnestub, peate selle kiiresti parandama. Hilinenud koostamise korral aeglustub tagasiside ja seega ka kogu arendus. See ka meile ei sobinud.

Selle tulemusel jäi alles ainult kolmas võimalus - jalgrattasõit. Kogu meie kood ja kõik allikad on salvestatud Bitbucketi serveri hoidlasse. Sellest lähtuvalt pidime Bitbucketi jaoks välja töötama pistikprogrammi.

See pistikprogramm alistab tõmbamistaotluse ühendamise mehhanismi. Algus on standardne: PR avaneb, kõik koostud käivitatakse, koodi ülevaatus on lõpule viidud. Kuid kui koodi ülevaatus on lõpule viidud ja arendaja otsustab klõpsata nupul „Ühenda”, kontrollib pistikprogramm, millise arenduse oleku suhtes kontrolle tehti. Kui arendust on pärast ehitamist värskendatud, ei luba plugin sellist tõmbamistaotlust põhiharusse liita. See lihtsalt taaskäivitab suhteliselt hiljutise arenduse järgud.

Meie vastuoluliste muudatustega näites ebaõnnestuvad sellised järgud kompileerimisvea tõttu. Sellest lähtuvalt peab funktsiooni B arendaja koodi parandama, kontrolli uuesti käivitama, seejärel rakendab pistikprogramm automaatselt tõmbamistaotluse.

Enne selle pistikprogrammi juurutamist tegime ühe tõmbamistaotluse kohta keskmiselt 2,7 ülevaatust. Pistikprogrammiga käivitati 3,6 korda. See meile sobis.

Väärib märkimist, et sellel pistikprogrammil on üks puudus: see taaskäivitab ehitamise ainult üks kord. See tähendab, et ikkagi jääb väike aken, mille kaudu võivad tekkida vastuolulised muutused. Kuid selle tõenäosus on väike ja me tegime selle kompromissi käivituste arvu ja ebaõnnestumise tõenäosuse vahel. Kahe aasta jooksul tulistas see vaid korra, nii et ilmselt polnud see asjata.

Bitbucketi pistikprogrammi esimese versiooni kirjutamiseks kulus meil kaks nädalat.

Uued tšekid

Vahepeal meie meeskond jätkas kasvamist. Lisatud on uued tšekid.

Mõtlesime: milleks teha vigu, kui neid saab ära hoida? Ja sellepärast nad rakendasid staatilise koodi analüüs. Alustasime lint, mis sisaldub Androidi SDK-s. Aga sel ajal ei osanud ta üldse Kotlini koodiga töötada ja meil oli Kotlinis juba 75% rakendusest kirjutatud. Seetõttu lisati linale sisseehitatud Android Studio kontrollib.

Selleks pidime tegema palju perversi: võtke Android Studio, pakkige see Dockerisse ja käivitage see virtuaalse monitoriga CI-s, nii et see arvab, et see töötab päris sülearvutis. Aga see töötas.

Selle aja jooksul hakkasime ka palju kirjutama instrumentatsiooni testid ja rakendatud ekraanipiltide testimine. See on siis, kui eraldi väikese vaate jaoks luuakse võrdlusekraanitõmmis ja test seisneb vaatest ekraanipildi tegemises ja selle võrdlemises standardse otse piksli haaval. Kui on lahknevus, tähendab see, et paigutus on kuskil valesti läinud või stiilides on midagi valesti.

Kuid mõõteriistade ja ekraanipiltide teste tuleb käivitada seadmetes: emulaatorites või pärisseadmetes. Arvestades, et teste on palju ja neid tehakse sageli, on vaja tervet farmi. Oma talu loomine on liiga töömahukas, seega leidsime valmis variandi – Firebase Test Lab.

Firebase'i testlabor

See valiti, kuna Firebase on Google'i toode, mis tähendab, et see peaks olema usaldusväärne ja tõenäoliselt ei sure. Hinnad on mõistlikud: reaalse seadme töötund 5 dollarit, emulaatori töötund 1 dollar.

Firebase'i testlabori juurutamine meie CI-s võttis aega umbes kolm nädalat.

Kuid meeskond kasvas jätkuvalt ja Firebase hakkas meid kahjuks alt vedama. Sel ajal tal SLA-d ei olnud. Mõnikord pani Firebase ootama, kuni vajalik arv seadmeid on testimiseks vabad, ega hakanud neid kohe täitma, nagu soovisime. Järjekorras ootamine võttis aega kuni pool tundi, mis on väga pikk aeg. Igal PR-l tehti aparatuuri testid, viivitused pidurdasid tõesti arengut ja siis tuli igakuine arve ümmargune summa. Üldiselt otsustati Firebase'ist loobuda ja ettevõttesiseselt töötada, kuna meeskond oli piisavalt kasvanud.

Docker + Python + bash

Võtsime Dockeri, toppisime sinna emulaatorid, kirjutasime Pythonis lihtsa programmi, mis õigel ajal käivitab õiges versioonis vajaliku arvu emulaatoreid ja vajadusel peatab. Ja muidugi paar bash-skripti – kus me oleksime ilma nendeta?

Oma testkeskkonna loomiseks kulus viis nädalat.

Selle tulemusel oli iga tõmbamistaotluse jaoks ulatuslik liitmist blokeerivate kontrollide loend:

• ARK koost;
• Juniti testid;
• Lint;
• Android Studio kontrollib;
• Instrumentide testid;
• Ekraanipiltide testid.

See hoidis ära paljud võimalikud rikked. Tehniliselt kõik toimis, kuid arendajad kurtsid, et tulemuste ootamine on liiga pikk.

Kui kaua on liiga pikk? Laadisime Bitbucketi ja TeamCity andmed analüüsisüsteemi ja saime sellest aru keskmine ooteaeg 45 minutit. See tähendab, et arendaja ootab tõmbetaotlust avades ehitamise tulemusi keskmiselt 45 minutit. Minu arvates on seda palju ja te ei saa niimoodi töötada.

Loomulikult otsustasime kiirendada kõiki oma ehitamisi.

Kiirustame

Nähes, et ehitised seisavad sageli järjekorras, on esimene asi, mida teeme ostis juurde riistvara — ulatuslik arendus on kõige lihtsam. Ehitised lõpetasid järjekorra, kuid ooteaeg vähenes veidi, kuna mõned kontrollid ise kestsid väga kaua.

Liiga kaua aegavõtvate tšekkide eemaldamine

Meie pidev integreerimine võib seda tüüpi vigu ja probleeme tabada.

• Ei kavatse. CI võib tabada kompileerimisvea, kui midagi ei ehitata vastuoluliste muudatuste tõttu. Nagu ma juba ütlesin, siis ei saa keegi midagi kokku panna, areng peatub ja kõik lähevad närvi.
• Viga käitumises. Näiteks kui rakendus on ehitatud, kuid jookseb nupule vajutamisel kokku või nuppu ei vajutata üldse. See on halb, sest selline viga võib kasutajani jõuda.
• Viga paigutuses. Näiteks klõpsatakse nuppu, kuid see on nihkunud 10 pikslit vasakule.
• Tehnilise võla suurenemine.

Pärast selle loendi vaatamist mõistsime, et ainult kaks esimest punkti on kriitilised. Me tahame sellistest probleemidest kõigepealt aru saada. Paigutuse vead avastatakse kujunduse ülevaatamise etapis ja neid saab seejärel hõlpsasti parandada. Tehniliste võlgade käsitlemine nõuab eraldi protsessi ja planeerimist, mistõttu otsustasime seda mitte testida tõmbetaotluse alusel.

Selle klassifikatsiooni alusel raputasime kogu tšekkide loendi kokku. Lint läbi kriipsutatud ja lükkas selle käivitamise üleöö edasi: lihtsalt selleks, et see koostaks aruande selle kohta, kui palju probleeme projektis oli. Leppisime kokku, et töötame eraldi tehnilise võlaga ja Android Studio kontrollidest loobuti täielikult. Android Studio Dockeris kontrollide käitamiseks kõlab huvitavalt, kuid tekitab toega palju probleeme. Iga Android Studio versiooni värskendus tähendab võitlust arusaamatute vigadega. Samuti oli raske toetada ekraanipiltide teste, kuna raamatukogu ei olnud väga stabiilne ja esines valepositiivseid tulemusi. Ekraanipiltide testid on kontrollnimekirjast eemaldatud.

Selle tulemusena jäi meile:

• ARK koost;
• Juniti testid;
• Instrumentatsiooni testid.

Gradle'i kaugvahemälu

Ilma raskete kontrollideta muutus kõik paremaks. Kuid täiuslikkusele pole piire!

Meie rakendus oli juba jagatud umbes 150 astmemooduliks. Gradle'i kaugvahemälu töötab sel juhul tavaliselt hästi, seega otsustasime seda proovida.

Gradle'i kaugvahemälu on teenus, mis suudab vahemällu salvestada üksikute moodulite üksikute ülesannete jaoks artefakte. Gradle kasutab koodi tegeliku kompileerimise asemel HTTP-d, et koputada kaugvahemällu ja küsida, kas keegi on selle ülesande juba täitnud. Kui jah, laadib see lihtsalt tulemuse alla.

Gradle'i kaugvahemälu käitamine on lihtne, kuna Gradle pakub Dockeri kujutist. Saime sellega hakkama kolme tunniga.

Piisab, kui käivitada Docker ja kirjutada projekti üks rida. Kuid kuigi selle saab kiiresti käivitada, kulub üsna palju aega, et kõik hästi toimiks.

Allpool on vahemälu vahelejäämise graafik.

Kohe alguses oli vahemälu vahelejäämise protsent umbes 65. Kolme nädala pärast õnnestus see väärtus tõsta 20%-ni. Selgus, et ülesannetel, mida Androidi rakendus kogub, on kummalised transitiivsed sõltuvused, mille tõttu jäi Gradle vahemälu vahele.

Vahemälu ühendamisega kiirendasime ehitamist oluliselt. Kuid lisaks kokkupanekule tehakse ka mõõteriistade katseid ja need võtavad kaua aega. Võib-olla ei pea iga tõmbamistaotluse jaoks kõiki teste käivitama. Selle väljaselgitamiseks kasutame mõjuanalüüsi.

Mõjuanalüüs

Tõmbetaotlusel kogume git diff ja leiame muudetud Gradle moodulid.

Mõttekas on läbi viia ainult instrumentatsioonitestid, mis kontrollivad muudetud mooduleid ja kõiki neist sõltuvaid mooduleid. Naabermoodulite teste pole mõtet teha: kood pole seal muutunud ja miski ei saa puruneda.

Instrumentide testid pole nii lihtsad, sest need peavad asuma rakenduste tipptasemel moodulis. Kasutasime heuristikat koos baitkoodianalüüsiga, et mõista, millisesse moodulisse iga test kuulub.

Seadmetestide töö ajakohastamine nii, et need testiksid ainult kaasatud mooduleid, võttis aega umbes kaheksa nädalat.

Kontrollide kiirendamise meetmed on toiminud edukalt. Alates 45 minutist tõusime umbes 15-ni. Veerand tundi ootamine on juba normaalne.

Kuid nüüd on arendajad hakanud kurtma, et nad ei saa aru, millised buildid käivitatakse, kust logi näha, miks on ehitus punane, milline test ebaõnnestus jne.

Probleemid tagasisidega aeglustavad arengut, seetõttu püüdsime anda võimalikult selget ja üksikasjalikku teavet iga PR ja ehituse kohta. Alustasime Bitbucketi kommentaaridega PR-le, näidates, milline ehitamine ebaõnnestus ja miks, ning kirjutasime Slackis sihitud sõnumeid. Lõppkokkuvõttes lõime lehe jaoks PR armatuurlaua, kus on loend kõigist praegu töötavatest ehitustest ja nende olek: järjekorras, töötab, jookseb kokku või on lõpetatud. Võite klõpsata konstruktsioonil ja avada selle logi.

Kuus nädalat kulus üksikasjalikule tagasisidele.

Plaanid

Liigume edasi lähiajaloole. Olles lahendanud tagasiside probleemi, jõudsime uuele tasemele - otsustasime ehitada oma emulaatorifarmi. Kui teste ja emulaatoreid on palju, on neid raske hallata. Selle tulemusel kolisid kõik meie emulaatorid paindliku ressursside haldamisega k8s-klastrisse.

Lisaks on muid plaane.

• Tagasi Lint (ja muu staatiline analüüs). Selles suunas me juba töötame.
• Käivitage kõik PR-blokeerijaga otsast lõpuni testid kõigis SDK versioonides.

Niisiis, oleme jälginud Avitos pideva integratsiooni arengu ajalugu. Nüüd tahan anda nõu kogenud vaatenurgast.

Советы

Kui ma saaksin anda vaid ühe nõu, oleks see järgmine:

Olge shelliskriptidega ettevaatlik!

Bash on väga paindlik ja võimas tööriist, sellega on väga mugav ja kiire skripte kirjutada. Kuid sellega võite lõksu langeda ja kahjuks sattusime sellesse.

Kõik sai alguse lihtsatest skriptidest, mis jooksid meie ehitusmasinatel:

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

Aga teadupärast kõik areneb ja muutub aja jooksul keerulisemaks - käivitame ühe skripti teisest, paneme sinna mõned parameetrid - lõpuks tuli kirjutada funktsioon, mis määrab, millisel bashi pesastuse tasemel me nüüd korras oleme vajalike tsitaatide sisestamiseks, et kõik alustada.

Võite ette kujutada selliste skriptide arendamise tööjõukulusid. Soovitan teil sellesse lõksu mitte langeda.

Mida saab asendada?

• Mis tahes skriptikeel. Kirjuta Python või Kotlin Script mugavam, sest see on programmeerimine, mitte skriptid.
• Või kirjeldage vormis kogu ehitusloogikat Kohandatud klasside ülesanded teie projekti jaoks.

Otsustasime valida teise võimaluse ja nüüd kustutame süstemaatiliselt kõik bash-skriptid ja kirjutame palju kohandatud gradle'i ülesandeid.

Nõuanne 2: salvestage infrastruktuur koodi.

See on mugav, kui säte Continuous Integration on salvestatud mitte Jenkinsi või TeamCity vms kasutajaliidesesse, vaid tekstifailidena otse projektihoidlasse. See annab versioonitavuse. Koodi tagasipööramine või teise haru juurde ehitamine ei ole keeruline.

Skripte saab projekti salvestada. Mida teha keskkonnaga?

Näpunäide nr 3: Docker saab keskkonnaga seotud olla.

See aitab kindlasti Androidi arendajaid; iOS-il seda kahjuks veel pole.

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

# 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

Olles kirjutanud selle Dockeri faili (ma ütlen sulle saladuse, sa ei pea seda kirjutama, vaid lihtsalt tõmbad GitHubist valmis kujul) ja pildi kokku pannud, saad virtuaalse masina, millele saad rakenduse ehitada ja käivitage Juniti testid.

Kaks peamist põhjust, miks see on mõttekas, on skaleeritavus ja korratavus. Dockeri abil saate kiiresti kasvatada kümmekond ehitusagenti, millel on täpselt sama keskkond kui eelmisel. See muudab CI-inseneride elu palju lihtsamaks. Android-sdk-d on üsna lihtne dockerisse lükata, kuid emulaatoritega on see pisut keerulisem: peate natuke rohkem vaeva nägema (või valmis laadima GitHubist uuesti alla).

Nõuanne nr 4: ärge unustage, et kontrolli ei tehta mitte kontrolli pärast, vaid inimeste pärast.

Kiire ja, mis kõige tähtsam, selge tagasiside on arendajatele väga oluline: mis läks katki, milline test ebaõnnestus, kus ma saan näha buildlogi.

Näpunäide nr 5: olge pideva integratsiooni arendamisel pragmaatiline.

Mõistke selgelt, millist tüüpi vigu soovite vältida, kui palju ressursse, aega ja arvutiaega olete nõus kulutama. Liiga kaua aega võtvad kontrollid võib näiteks üleöö edasi lükata. Ja need, mis tabavad mitte eriti olulisi vigu, tuleks täielikult loobuda.

Vihje nr 6: kasutage valmistööriistu.

Pilve CI-d pakuvad praegu palju ettevõtteid.

See on hea lahendus väikestele meeskondadele. Teil pole vaja midagi toetada, piisab, kui maksta veidi raha, koostada oma rakendus ja isegi käitada mõõteriistade teste.

Vihje nr 7: suures meeskonnas on ettevõttesisesed lahendused tulusamad.

Kuid varem või hiljem, kui meeskond kasvab, muutuvad majasisesed lahendused tulusamaks. Nende otsustega on üks probleem. Majanduses kehtib kahaneva tootluse seadus: iga projekti puhul on iga järgnev parendamine aina keerulisem ja nõuab aina rohkem investeeringuid.

Majandusteadus kirjeldab kogu meie elu, sealhulgas pidevat integratsiooni. Koostasin meie pideva integratsiooni iga arenguetapi tööjõukulude ajakava.

On selge, et igasugune parandamine muutub üha raskemaks. Seda graafikut vaadates saate aru, et pidevat integratsiooni tuleb arendada vastavalt meeskonna suuruse kasvule. Kaheliikmelise meeskonna jaoks on 50 päeva sisemise emulaatorifarmi väljatöötamine keskpärane idee. Aga samas on suure meeskonna jaoks ka Continuous Integration üldse tegemata jätmine halb mõte, sest lõimumisprobleemid, suhtluse parandamine jne. see võtab veelgi rohkem aega.

Alustasime mõttega, et automatiseerimist on vaja, sest inimesed on kallid, teevad vigu ja on laisad. Aga inimesed ka automatiseerivad. Seetõttu kehtivad automatiseerimise kohta kõik samad probleemid.

• Automatiseerimine on kallis. Pidage meeles töögraafikut.
• Kui rääkida automatiseerimisest, siis inimesed teevad vigu.
• Mõnikord on automatiseerimine väga laisk, sest kõik toimib nii. Milleks veel midagi parandada, milleks kogu see pidev integratsioon?

Aga mul on statistika: vead tabatakse 20% sõlmedest. Ja see ei tulene sellest, et meie arendajad kirjutavad koodi halvasti. Selle põhjuseks on asjaolu, et arendajad on kindlad, et kui nad teevad vea, ei jõua see väljatöötamiseni, vaid automaatkontrollid tabavad seda. Sellest lähtuvalt saavad arendajad kulutada rohkem aega koodi ja huvitavate asjade kirjutamisele, selle asemel, et midagi kohapeal käitada ja testida.

Harjutage pidevat integratsiooni. Aga mõõdukalt.

Muide, Nikolai Nesterov ei pea mitte ainult ise suurepäraseid ettekandeid, vaid on ka programmikomisjoni liige AppsConf ja aitab teistel teile sisukaid kõnesid ette valmistada. Järgmise konverentsiprogrammi terviklikkust ja kasulikkust saab hinnata teemade kaupa ajakava. Ja täpsemalt, tule inforuumi 22.-23.aprillil.

Allikas: www.habr.com