Dnes sa väčšina softvérových produktov vyvíja v tímoch. Podmienky úspešného rozvoja tímu možno znázorniť formou jednoduchého diagramu.

Po napísaní kódu sa musíte uistiť, že:

Funguje to.
Nič neporušuje, vrátane kódu, ktorý napísali vaši kolegovia.

Ak sú splnené obe podmienky, potom ste na ceste k úspechu. Aby sme tieto podmienky jednoducho skontrolovali a neodchýlili sa od ziskovej cesty, prišli sme s kontinuálnou integráciou.

CI je pracovný postup, v ktorom integrujete svoj kód do celkového kódu produktu tak často, ako je to možné. A nielenže sa integrujete, ale aj neustále kontrolujete, či všetko funguje. Keďže musíte veľa a často kontrolovať, oplatí sa premýšľať o automatizácii. Všetko môžete skontrolovať manuálne, ale nemali by ste, a tu je dôvod.

vážení ľudia. Hodina práce ktoréhokoľvek programátora je drahšia ako hodina práce akéhokoľvek servera.
Ľudia robia chyby. Preto môžu nastať situácie, keď boli testy spustené na nesprávnej vetve alebo bolo pre testerov skompilované nesprávne odovzdanie.
Ľudia sú leniví. Z času na čas, keď dokončím úlohu, vyvstane myšlienka: „Čo je potrebné skontrolovať? Napísal som dva riadky - všetko funguje! Myslím, že niektorí z vás majú tiež niekedy takéto myšlienky. Ale mali by ste vždy skontrolovať.

Ako bola implementovaná a vyvinutá nepretržitá integrácia v tíme vývoja mobilných zariadení Avito, ako prešli z 0 na 450 zostáv za deň a ako sa zostavy strojov montujú 200 hodín denne, hovorí Nikolai Nesterov (nnesterov) je účastníkom všetkých evolučných zmien aplikácie CI/CD pre Android.

Príbeh je založený na príklade príkazu Android, ale väčšina prístupov je použiteľná aj na iOS.

Kedysi jeden človek pracoval v tíme Avito Android. Podľa definície nepotreboval nič od nepretržitej integrácie: nebolo sa s kým integrovať.

Aplikácia sa ale rozrastala, pribúdalo nových a nových úloh a podľa toho rástol aj tím. V určitom momente je čas na formálnejšie vytvorenie procesu integrácie kódu. Bolo rozhodnuté použiť Git flow.

Koncept toku Git je dobre známy: projekt má jednu spoločnú vývojovú vetvu a pre každú novú funkciu vývojári odrežú samostatnú vetvu, zaviažu sa k nej, tlačia a keď chcú zlúčiť svoj kód do vývojovej vetvy, otvoria vytiahnuť žiadosť. Na zdieľanie znalostí a diskusiu o prístupoch sme zaviedli kontrolu kódu, to znamená, že kolegovia si musia navzájom kontrolovať a potvrdzovať svoj kód.

kontroly

Vidieť kód očami je skvelé, ale nestačí. Preto sa zavádzajú automatické kontroly.

V prvom rade skontrolujeme Montáž ARK.
Veľa Junit testy.
Zvažujeme pokrytie kódom, keďže prebiehajú testy.

Aby sme pochopili, ako by sa tieto kontroly mali vykonávať, pozrime sa na proces vývoja v Avito.

Schematicky sa to dá znázorniť takto:

Vývojár píše kód na svojom notebooku. Priamo tu môžete spustiť kontroly integrácie – buď pomocou háku odovzdania, alebo jednoducho spustiť kontroly na pozadí.
Keď vývojár vloží kód, otvorí požiadavku na stiahnutie. Aby sa jeho kód dostal do vývojovej vetvy, je potrebné prejsť code review a nazbierať potrebný počet potvrdení. Tu môžete povoliť kontroly a zostavenia: kým nebudú všetky zostavy úspešné, požiadavku na stiahnutie nemožno zlúčiť.
Po zlúčení požiadavky na stiahnutie a zahrnutí kódu do vývoja si môžete vybrať vhodný čas: napríklad v noci, keď sú všetky servery voľné, a spustiť toľko kontrol, koľko chcete.

Nikomu sa nepáčilo spúšťanie skenovania na svojom notebooku. Keď vývojár dokončí funkciu, chce ju rýchlo stlačiť a otvoriť požiadavku na stiahnutie. Ak sa v tejto chvíli spustia nejaké dlhé kontroly, nie je to nielen príjemné, ale aj spomaľuje vývoj: kým notebook niečo kontroluje, nedá sa na ňom normálne pracovať.

Veľmi sa nám páčilo spúšťanie kontrol v noci, pretože je veľa času a serverov, môžete sa túlať. Bohužiaľ, keď sa kód funkcie dostane do vývoja, vývojár má oveľa menšiu motiváciu opraviť chyby, ktoré CI našiel. Pri pohľade na všetky chyby nájdené v rannej správe som sa pravidelne pristihol, ako som si myslel, že ich niekedy neskôr opravím, pretože teraz je v Jire skvelá nová úloha, ktorú chcem začať robiť.

Ak kontroly zablokujú požiadavku na stiahnutie, potom je motivácia dostatočná, pretože kým sa zostavy nezafarbia na zeleno, kód sa nedostane do vývoja, čo znamená, že úloha nebude dokončená.

V dôsledku toho sme zvolili nasledujúcu stratégiu: v noci spúšťame maximálnu možnú sériu kontrol a spúšťame najkritickejšie z nich, a čo je najdôležitejšie, najrýchlejšie na žiadosť o stiahnutie. Tým však nekončíme – súbežne optimalizujeme rýchlosť kontrol, aby sme ich preniesli z nočného režimu na kontroly žiadostí.

V tom čase boli všetky naše zostavy dokončené pomerne rýchlo, takže sme jednoducho zahrnuli zostavu ARK, testy Junit a výpočty pokrytia kódu ako blokovanie požiadavky na stiahnutie. Zapli sme to, premýšľali o tom a opustili sme pokrytie kódom, pretože sme si mysleli, že to nepotrebujeme.

Kompletné nastavenie základného CI (ďalej je časový odhad približný, potrebný pre mierku) nám trvalo dva dni.

Potom sme začali premýšľať ďalej - kontrolujeme to správne? Spúšťame zostavy na základe požiadaviek na stiahnutie správne?

Spustili sme zostavenie na poslednom odovzdaní vetvy, z ktorej bola otvorená požiadavka na stiahnutie. Testy tohto odovzdania však môžu iba ukázať, že kód, ktorý vývojár napísal, funguje. Ale nedokazujú, že nič neporušil. V skutočnosti musíte skontrolovať stav vývojovej vetvy po zlúčení funkcie.

Aby sme to dosiahli, napísali sme jednoduchý bash skript premerge.sh:

#!/usr/bin/env bash

set -e

git fetch origin develop

git merge origin/develop

Tu sú všetky najnovšie zmeny z vývoja jednoducho vytiahnuté a zlúčené do aktuálnej vetvy. Pridali sme skript premerge.sh ako prvý krok vo všetkých zostavách a začali sme kontrolovať presne to, čo chceme, tj integrácia.

Lokalizácia problému, nájdenie riešenia a napísanie tohto skriptu trvalo tri dni.

Aplikácia sa vyvíjala, pribúdalo viac a viac úloh, tím rástol a premerge.sh nás občas začal sklamať. Develop mal protichodné zmeny, ktoré narušili zostavu.

Príklad, ako sa to deje:

Dvaja vývojári súčasne začnú pracovať na funkciách A a B. Vývojár funkcie A objaví v projekte nevyužitú funkciu answer() a ako správny skaut ho odstráni. Vývojár funkcie B zároveň vo svojej pobočke pridáva nové volanie tejto funkcie.

Vývojári dokončia svoju prácu a zároveň otvoria požiadavku na stiahnutie. Zostavenia sú spustené, premerge.sh kontroluje obe požiadavky na stiahnutie týkajúce sa najnovšieho stavu vývoja – všetky kontroly sú zelené. Potom je zlúčená požiadavka na stiahnutie funkcie A, zlúčená požiadavka na stiahnutie funkcie B... Bum! Vývojové prestávky, pretože vývojový kód obsahuje volanie neexistujúcej funkcie.

Keď sa to nebude rozvíjať, tak áno miestna katastrofa. Celý tím nemôže nič zbierať a posielať na testovanie.

Stalo sa, že som najčastejšie pracoval na úlohách infraštruktúry: analytika, sieť, databázy. To znamená, že som to bol ja, kto napísal tie funkcie a triedy, ktoré používajú iní vývojári. Z tohto dôvodu som sa v podobných situáciách ocitol veľmi často. Dokonca som mal tento obrázok chvíľu visieť.

Keďže nám to nevyhovovalo, začali sme skúmať možnosti, ako tomu zabrániť.

Ako sa nerozvinúť

Prvá možnosť: prebudovať všetky požiadavky na stiahnutie pri aktualizácii vývoj. Ak je v našom príklade požiadavka na stiahnutie s vlastnosťou A prvá, ktorá bude zahrnutá do vývoja, požiadavka na vytiahnutie funkcie B sa prebuduje, a preto kontroly zlyhajú kvôli chybe kompilácie.

Ak chcete pochopiť, ako dlho to bude trvať, zvážte príklad s dvoma PR. Otvárame dve PR: dve zostavy, dve série kontrol. Po zlúčení prvého PR do developmentu je potrebné prebudovať druhé. Celkovo si dve PR vyžadujú tri série kontrol: 2 + 1 = 3.

V princípe je to v poriadku. Pozreli sme sa však na štatistiku a typická situácia v našom tíme bola 10 otvorených PR a potom počet kontrol je súčet progresie: 10 + 9 +... + 1 = 55. To znamená prijať 10 PR, potrebujete 55-krát prestavať. A to je v ideálnej situácii, keď všetky kontroly prejdú na prvýkrát, keď nikto neotvorí dodatočnú požiadavku na stiahnutie, kým sa tieto desiatky spracovávajú.

Predstavte si seba ako vývojára, ktorý musí ako prvý kliknúť na tlačidlo „zlúčiť“, pretože ak to urobí sused, budete musieť počkať, kým znova prejdú všetky stavby... Nie, nebude to fungovať , vážne to spomalí vývoj.

Druhý možný spôsob: zbierať požiadavky na stiahnutie po kontrole kódu. To znamená, že otvoríte požiadavku na stiahnutie, zozbierate požadovaný počet schválení od kolegov, opravíte, čo je potrebné, a potom spustíte zostavy. Ak sú úspešné, požiadavka na stiahnutie sa zlúči s vývojom. V tomto prípade nie sú žiadne ďalšie reštarty, ale spätná väzba je značne spomalená. Ako vývojár, keď otvorím požiadavku na stiahnutie, okamžite chcem zistiť, či to bude fungovať. Napríklad, ak test zlyhá, musíte to rýchlo opraviť. V prípade oneskoreného zostavenia sa spomaľuje spätná väzba, a tým aj celý vývoj. Ani toto nám nevyhovovalo.

V dôsledku toho zostala iba tretia možnosť - bicykel. Všetok náš kód, všetky naše zdroje sú uložené v úložisku na serveri Bitbucket. Preto sme museli vyvinúť doplnok pre Bitbucket.

Tento doplnok prepíše mechanizmus na zlučovanie požiadaviek na stiahnutie. Začiatok je štandardný: otvorí sa PR, spustia sa všetky zostavy, dokončí sa preskúmanie kódu. Ale keď je kontrola kódu dokončená a vývojár sa rozhodne kliknúť na „zlúčiť“, doplnok skontroluje, proti ktorému stavu vývoja boli kontroly spustené. Ak bol development po zostavení aktualizovaný, plugin nedovolí zlúčiť takúto požiadavku na stiahnutie do hlavnej vetvy. Jednoducho reštartuje zostavy relatívne nedávneho vývoja.

V našom príklade s konfliktnými zmenami takéto zostavy zlyhajú v dôsledku chyby kompilácie. V súlade s tým bude musieť vývojár funkcie B opraviť kód, reštartovať kontroly, potom doplnok automaticky použije požiadavku na stiahnutie.

Pred implementáciou tohto doplnku sme v priemere dosiahli 2,7 spustenia kontroly na žiadosť o stiahnutie. S doplnkom došlo k spusteniu 3,6. Toto nám vyhovovalo.

Stojí za zmienku, že tento doplnok má nevýhodu: iba raz reštartuje zostavu. To znamená, že stále existuje malé okno, cez ktoré sa môžu rozvinúť konfliktné zmeny. Ale pravdepodobnosť je nízka a urobili sme tento kompromis medzi počtom spustení a pravdepodobnosťou zlyhania. Za dva roky vystrelilo len raz, tak to asi nebolo márne.

Napísanie prvej verzie doplnku Bitbucket nám trvalo dva týždne.

Nové šeky

Medzitým sa náš tím stále rozrastal. Boli pridané nové kontroly.

Mysleli sme si: prečo robiť chyby, ak sa im dá predísť? A preto ich implementovali statická analýza kódu. Začali sme s lint, ktorý je súčasťou súpravy Android SDK. Lenže on vtedy vôbec nevedel pracovať s kódom Kotlin a to sme už 75% aplikácie mali napísanú v Kotline. Preto sa k vláknam pridávali vstavané Kontroly Android Studio.

Aby sme to urobili, museli sme urobiť veľa zvrátenosti: vziať Android Studio, zabaliť ho do Dockera a spustiť ho na CI s virtuálnym monitorom, aby si myslel, že beží na skutočnom notebooku. Ale podarilo sa.

V tomto období sme si začali veľa písať prístrojové skúšky a implementované testovanie snímky obrazovky. Toto je, keď sa vytvorí referenčná snímka obrazovky pre samostatný malý pohľad a test pozostáva z vytvorenia snímky obrazovky z pohľadu a jej porovnanie so štandardom priamo pixel po pixeli. Ak sa vyskytne nezrovnalosť, znamená to, že sa rozloženie niekde pokazilo alebo niečo nie je v poriadku v štýloch.

Testy prístrojového vybavenia a testy snímok obrazovky však musia byť spustené na zariadeniach: na emulátoroch alebo na skutočných zariadeniach. Vzhľadom na to, že existuje veľa testov a často sa vykonávajú, je potrebná celá farma. Založenie vlastnej farmy je príliš náročné na prácu, preto sme našli hotovú možnosť – Firebase Test Lab.

testovacie laboratórium firebase

Bol vybraný, pretože Firebase je produkt Google, čo znamená, že by mal byť spoľahlivý a je nepravdepodobné, že by niekedy zomrel. Ceny sú primerané: 5 USD za hodinu prevádzky skutočného zariadenia, 1 USD za hodinu prevádzky emulátora.

Implementácia Firebase Test Lab do našej CI trvalo približne tri týždne.

Ale tím sa ďalej rozrastal a Firebase nás, žiaľ, začal sklamať. V tom čase nemal žiadnu SLA. Niekedy nás Firebase prinútil počkať, kým sa uvoľní požadovaný počet zariadení na testy, a nezačal ich spúšťať okamžite, ako sme chceli. Čakanie v rade trvalo až pol hodiny, čo je veľmi dlhá doba. Na každom PR prebiehali prístrojové testy, meškania skutočne spomalili vývoj a potom prišiel mesačný účet s okrúhlou sumou. Vo všeobecnosti bolo rozhodnuté opustiť Firebase a pracovať interne, pretože tím sa dostatočne rozrástol.

Docker + Python + bash

Vzali sme Docker, napchali doň emulátory, napísali jednoduchý program v Pythone, ktorý v správnom čase spustí potrebný počet emulátorov v správnej verzii a v prípade potreby ich zastaví. A samozrejme pár bash skriptov – kde by sme bez nich boli?

Vytvorenie vlastného testovacieho prostredia trvalo päť týždňov.

Výsledkom bolo, že pre každú požiadavku na stiahnutie existoval rozsiahly zoznam kontrol blokujúcich zlúčenie:

montáž ARK;
Junit testy;
Lint;
kontroly Android Studio;
Prístrojové skúšky;
Testy snímok obrazovky.

Tým sa predišlo mnohým možným poruchám. Technicky všetko fungovalo, no vývojári sa sťažovali, že čakanie na výsledky bolo príliš dlhé.

Ako dlho je príliš dlho? Nahrali sme údaje z Bitbucket a TeamCity do analytického systému a uvedomili sme si to priemerná doba čakania 45 minút. To znamená, že vývojár pri otvorení požiadavky na stiahnutie čaká v priemere 45 minút na výsledky zostavenia. Podľa mňa je to veľa a takto sa pracovať nedá.

Samozrejme, rozhodli sme sa urýchliť všetky naše stavby.

Zrýchlime

Prvá vec, ktorú urobíme, je, že budovy často stoja v rade kúpil ďalší hardvér — extenzívny vývoj je najjednoduchší. Stavby sa prestali radiť, ale čakacia doba sa skrátila len mierne, pretože niektoré kontroly samotné trvali veľmi dlho.

Odstraňovanie šekov, ktoré trvá príliš dlho

Naša nepretržitá integrácia by mohla zachytiť tieto typy chýb a problémov.

Nechystám sa. CI môže zachytiť chybu kompilácie, keď sa niečo nezostaví kvôli konfliktným zmenám. Ako som už povedal, potom nikto nemôže nič zostaviť, vývoj sa zastaví a všetci sú nervózni.
Chyba v správaní. Napríklad, keď je aplikácia postavená, ale spadne, keď stlačíte tlačidlo, alebo sa tlačidlo nestlačí vôbec. To je zlé, pretože takáto chyba sa môže dostať k používateľovi.
Chyba v rozložení. Napríklad sa kliklo na tlačidlo, ale posunulo sa o 10 pixelov doľava.
Nárast technického dlhu.

Po prezretí tohto zoznamu sme si uvedomili, že kritické sú iba prvé dva body. Takéto problémy chceme podchytiť ako prvé. Chyby v rozložení sa objavia vo fáze kontroly návrhu a potom sa dajú ľahko opraviť. Riešenie technického dlhu si vyžaduje samostatný proces a plánovanie, preto sme sa rozhodli, že ho nebudeme testovať na vyžiadanie.

Na základe tejto klasifikácie sme pretriasli celý zoznam kontrol. Preškrtnutý Lint a odložil jej spustenie zo dňa na deň: len preto, aby vypracoval správu o tom, koľko problémov bolo v projekte. Dohodli sme sa, že budeme pracovať oddelene s technickým dlhom, a Kontroly Android Studio boli úplne opustené. Android Studio v Dockeri na spustenie inšpekcií znie zaujímavo, ale spôsobuje veľa problémov s podporou. Akákoľvek aktualizácia verzií Android Studio znamená boj s nepochopiteľnými chybami. Bolo tiež ťažké podporiť testy screenshotov, pretože knižnica nebola príliš stabilná a boli tam falošné pozitíva. Testy snímok obrazovky boli odstránené z kontrolného zoznamu.

V dôsledku toho nám zostalo:

montáž ARK;
Junit testy;
Prístrojové skúšky.

Vzdialená vyrovnávacia pamäť Gradle

Bez náročných kontrol sa všetko zlepšilo. Ale dokonalosť nemá žiadne hranice!

Naša aplikácia už bola rozdelená do približne 150 modulov. Vzdialená vyrovnávacia pamäť Gradle v tomto prípade zvyčajne funguje dobre, preto sme sa rozhodli ju vyskúšať.

Gradle remote cache je služba, ktorá dokáže cache budovať artefakty pre jednotlivé úlohy v jednotlivých moduloch. Gradle namiesto toho, aby skutočne skompiloval kód, používa HTTP na zaklopanie na vzdialenú vyrovnávaciu pamäť a spýta sa, či už niekto túto úlohu vykonal. Ak áno, jednoducho stiahne výsledok.

Spustenie vzdialenej vyrovnávacej pamäte Gradle je jednoduché, pretože Gradle poskytuje obraz Docker. Zvládli sme to za tri hodiny.

Stačilo spustiť Docker a napísať jeden riadok do projektu. Ale hoci sa dá spustiť rýchlo, zaberie to pomerne veľa času, kým všetko dobre dopadne.

Nižšie je uvedený graf chýbajúcich vyrovnávacích pamätí.

Na úplnom začiatku bolo percento vynechaní vyrovnávacej pamäte asi 65. Po troch týždňoch sa nám podarilo túto hodnotu zvýšiť na 20 %. Ukázalo sa, že úlohy, ktoré aplikácia pre Android zhromažďuje, majú zvláštne prechodné závislosti, kvôli ktorým Gradle vynechal vyrovnávaciu pamäť.

Pripojením vyrovnávacej pamäte sme výrazne urýchlili zostavenie. No okrem montáže sú tu aj prístrojové skúšky a tie trvajú dlho. Možno nie je potrebné spustiť všetky testy pre každú požiadavku na stiahnutie. Aby sme to zistili, používame analýzu dopadov.

Analýza vplyvu

Na žiadosť o stiahnutie zhromažďujeme git diff a nájdeme upravené moduly Gradle.

Má zmysel spúšťať iba testy prístrojového vybavenia, ktoré skontrolujú zmenené moduly a všetky moduly, ktoré sú na nich závislé. Testovanie susedných modulov nemá zmysel: tamojší kód sa nezmenil a nič sa nemôže zlomiť.

Prístrojové testy nie sú také jednoduché, pretože musia byť umiestnené v nadradenom module Aplikácia. Použili sme heuristiku s analýzou bajtového kódu, aby sme pochopili, do ktorého modulu každý test patrí.

Modernizácia prevádzky testov prístrojového vybavenia tak, aby testovali len príslušné moduly, trvala približne osem týždňov.

Opatrenia na urýchlenie kontrol fungovali úspešne. Zo 45 minút sme stúpli na približne 15. Je už normálne čakať na zostavenie štvrť hodiny.

Teraz sa však vývojári začali sťažovať, že nerozumejú, ktoré zostavy sa spúšťajú, kde vidieť denník, prečo je zostava červená, ktorý test zlyhal atď.

Problémy so spätnou väzbou spomaľujú vývoj, preto sme sa snažili poskytnúť čo najjasnejšie a najpodrobnejšie informácie o každom PR a stavbe. Začali sme s komentármi v Bitbuckete k PR, ktoré uvádzali, ktorá zostava zlyhala a prečo, a napísali sme cielené správy v Slacku. Na záver sme pre stránku vytvorili PR dashboard so zoznamom všetkých aktuálne spustených zostáv a ich stavom: vo fronte, spustené, zrútené alebo dokončené. Môžete kliknúť na zostavu a dostať sa do jej denníka.

Šesť týždňov sa venovalo podrobnej spätnej väzbe.

Plány

Prejdime do nedávnej histórie. Po vyriešení problému so spätnou väzbou sme dosiahli novú úroveň - rozhodli sme sa vybudovať vlastnú emulátorovú farmu. Keď existuje veľa testov a emulátorov, je ťažké ich spravovať. V dôsledku toho sa všetky naše emulátory presunuli do klastra k8s s flexibilnou správou zdrojov.

Okrem toho existujú aj ďalšie plány.

Vrátiť Lint (a iné statické analýzy). V tomto smere už pracujeme.
Spustite všetko na blokovači PR end-to-end testy na všetkých verziách SDK.

Takže sme sledovali históriu vývoja kontinuálnej integrácie v Avito. Teraz by som chcel dať pár rád skúseného pohľadu.

Советы

Ak by som mohol dať len jednu radu, bola by to táto:

Buďte opatrní pri skriptoch shellu!

Bash je veľmi flexibilný a výkonný nástroj, písanie skriptov je veľmi pohodlné a rýchle. Ale môžete sa ním dostať do pasce a my sme do nej, žiaľ, padli.

Všetko to začalo jednoduchými skriptami, ktoré bežali na našich zostavovacích strojoch:

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

Ale, ako viete, všetko sa časom vyvíja a komplikuje - spúšťajme jeden skript od druhého, dajme tam nejaké parametre - nakoniec sme museli napísať funkciu, ktorá určí, na akej úrovni bash hniezdenia sme teraz v poradí vložiť potrebné úvodzovky, aby to všetko začalo.

Viete si predstaviť mzdové náklady na vývoj takýchto skriptov. Radím vám, aby ste sa nedostali do tejto pasce.

Čo sa dá nahradiť?

Akýkoľvek skriptovací jazyk. Písať Python alebo Kotlin Script pohodlnejšie, pretože je to programovanie, nie skripty.
Alebo opíšte celú logiku zostavenia vo formulári Vlastné úlohy na úrovni pre váš projekt.

Rozhodli sme sa zvoliť druhú možnosť a teraz systematicky odstraňujeme všetky bash skripty a píšeme veľa vlastných gradle úloh.

Tip #2: Uložte infraštruktúru v kóde.

Je vhodné, keď nastavenie Continuous Integration nie je uložené v UI rozhraní Jenkins alebo TeamCity a pod., ale vo forme textových súborov priamo v úložisku projektu. To dáva možnosť verzií. Nebude ťažké vrátiť späť alebo zostaviť kód na inej vetve.

Skripty môžu byť uložené v projekte. Čo robiť so životným prostredím?

Tip č. 3: Docker môže pomôcť s ochranou životného prostredia.

Určite to pomôže vývojárom Androidu; iOS, bohužiaľ, zatiaľ žiadny nemá.

Toto je príklad jednoduchého súboru docker, ktorý obsahuje jdk a 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

Po napísaní tohto súboru Docker (poviem vám tajomstvo, nemusíte ho písať, ale stačí ho stiahnuť hotový z GitHubu) a zostaviť obrázok, získate virtuálny stroj, na ktorom môžete zostaviť aplikáciu a spustite testy Junit.

Dva hlavné dôvody, prečo to dáva zmysel, sú škálovateľnosť a opakovateľnosť. Pomocou dockeru môžete rýchlo vytvoriť tucet zostavovacích agentov, ktorí budú mať presne rovnaké prostredie ako predchádzajúci. To značne uľahčuje život inžinierom CI. Je celkom jednoduché vložiť android-sdk do dockeru, ale s emulátormi je to trochu zložitejšie: budete musieť pracovať trochu tvrdšie (alebo si znova stiahnuť hotový z GitHub).

Rada č.4: nezabúdajte, že kontroly sa nerobia pre kontroly, ale pre ľudí.

Rýchla a hlavne jasná spätná väzba je pre vývojárov veľmi dôležitá: čo sa pokazilo, aký test zlyhal, kde môžem vidieť buildlog.

Tip č. 5: Buďte pragmatickí pri vývoji kontinuálnej integrácie.

Jasne pochopte, akým typom chýb chcete predchádzať, koľko zdrojov, času a počítačového času ste ochotní minúť. Kontroly, ktoré trvajú príliš dlho, môžu byť napríklad odložené zo dňa na deň. A tie z nich, ktoré zachytávajú nie veľmi dôležité chyby, by sa mali úplne opustiť.

Tip #6: Použite hotové nástroje.

V súčasnosti existuje veľa spoločností, ktoré poskytujú cloud CI.

Toto je dobré riešenie pre malé tímy. Nepotrebujete nič podporovať, stačí zaplatiť trochu peňazí, zostaviť si aplikáciu a dokonca spustiť prístrojové testy.

Tip č. 7: Vo veľkom tíme sú interné riešenia ziskovejšie.

Ale skôr či neskôr, ako tím rastie, budú interné riešenia ziskovejšie. S týmito rozhodnutiami je jeden problém. V ekonómii platí zákon klesajúcej návratnosti: v každom projekte je každé ďalšie zlepšenie čoraz ťažšie a vyžaduje si stále viac investícií.

Ekonomika opisuje celý náš život, vrátane kontinuálnej integrácie. Pre každú fázu vývoja našej kontinuálnej integrácie som zostavil harmonogram mzdových nákladov.

Je jasné, že akékoľvek zlepšenie je čoraz ťažšie. Pri pohľade na tento graf môžete pochopiť, že nepretržitú integráciu je potrebné rozvíjať v súlade s rastom veľkosti tímu. Pre tím dvoch ľudí je stráviť 50 dní vývojom internej emulátorovej farmy priemerný nápad. Ale zároveň pre veľký tím je nerobiť kontinuálnu integráciu tiež zlý nápad, pretože problémy s integráciou, opravovaním komunikácie atď. zaberie to ešte viac času.

Začali sme s myšlienkou, že automatizácia je potrebná, pretože ľudia sú drahí, robia chyby a sú leniví. Ľudia sa však aj automatizujú. Preto sa všetky rovnaké problémy týkajú automatizácie.

Automatizácia je drahá. Pamätajte na rozvrh práce.
Pokiaľ ide o automatizáciu, ľudia robia chyby.
Niekedy je veľmi lenivé automatizovať, pretože všetko tak funguje. Prečo vylepšovať niečo iné, prečo celá táto nepretržitá integrácia?

Ale mám štatistiku: chyby sa vychytajú v 20% zostavách. A nie je to preto, že by naši vývojári písali kód zle. Vývojári sú totiž presvedčení, že ak urobia nejakú chybu, neskončí to vo vývoji, ale zachytia ju automatické kontroly. V súlade s tým môžu vývojári stráviť viac času písaním kódu a zaujímavých vecí, namiesto toho, aby niečo spúšťali a testovali lokálne.

Precvičte si nepretržitú integráciu. Ale s mierou.

Mimochodom, Nikolaj Nesterov nielen sám podáva skvelé správy, ale je aj členom programového výboru AppsConf a pomáha ostatným pripraviť pre vás zmysluplné prejavy. Úplnosť a užitočnosť ďalšieho programu konferencie možno posúdiť podľa tém v harmonogram. A pre podrobnosti príďte do Infospace 22. – 23. apríla.

Zdroj: hab.com

Vývoj CI v tíme vývoja mobilných zariadení