Nykyään useimmat ohjelmistotuotteet kehitetään ryhmissä. Onnistuneen tiimikehityksen edellytykset voidaan esittää yksinkertaisen kaavion muodossa.

Kun olet kirjoittanut koodin, varmista, että se:

1. Работает.
2. Se ei riko mitään, mukaan lukien kollegojesi kirjoittama koodi.

Jos molemmat ehdot täyttyvät, olet menestyksen tiellä. Jotta nämä ehdot voidaan helposti tarkistaa ja olla poikkeamatta kannattavalta tieltä, kehitimme jatkuvan integraation.

CI on työnkulku, jossa integroit koodisi yleiseen tuotekoodiin mahdollisimman usein. Etkä vain integroi, vaan myös tarkista jatkuvasti, että kaikki toimii. Koska sinun täytyy tarkistaa paljon ja usein, kannattaa harkita automaatiota. Voit tarkistaa kaiken manuaalisesti, mutta sinun ei pitäisi, ja tässä on syy.

• Rakkaat ihmiset. Minkä tahansa ohjelmoijan työtunti on kalliimpaa kuin minkä tahansa palvelimen tunti työtä.
• Ihmiset tekevät virheitä. Tästä syystä voi syntyä tilanteita, joissa testejä ajettiin väärällä haaralla tai testaajille on koottu väärä sitoumus.
• Ihmiset ovat laiskoja. Ajoittain, kun saan tehtävän valmiiksi, herää ajatus: ”Mitä siellä on tarkistettava? Kirjoitin kaksi riviä - kaikki toimii! Luulen, että joillakin teistä on joskus myös tällaisia ​​ajatuksia. Mutta aina kannattaa tarkistaa.

Miten Jatkuva integraatio otettiin käyttöön ja kehitettiin Aviton mobiilikehitystiimissä, kuinka he valmistuivat 0:sta 450:een päivässä ja kuinka rakennuskoneet kootaan 200 tuntia päivässä, Nikolai Nesterov (nnesterov) on mukana kaikissa CI/CD Android -sovelluksen evoluution muutoksissa.

Tarina perustuu Android-komennon esimerkkiin, mutta suurin osa lähestymistavoista on sovellettavissa myös iOS: lle.

Yksi henkilö työskenteli kerran Avito Android -tiimissä. Määritelmän mukaan hän ei tarvinnut mitään jatkuvasta integraatiosta: ei ollut ketään, jonka kanssa integroitua.

Mutta sovellus kasvoi, uusia tehtäviä ilmestyi yhä enemmän, ja tiimi kasvoi vastaavasti. Jossain vaiheessa on aika vahvistaa koodin integrointiprosessi virallisemmin. Päätettiin käyttää Git-virtausta.

Git flown konsepti on tuttu: projektilla on yksi yhteinen kehityshaara, ja jokaista uutta ominaisuutta varten kehittäjät leikkaavat erillisen haaran, sitoutuvat siihen, työntävät ja kun haluavat yhdistää koodinsa kehityshaaraan, avaa vedä pyyntö. Tietojen jakamiseksi ja lähestymistapojen keskustelemiseksi otimme käyttöön kooditarkistuksen, eli kollegoiden on tarkistettava ja vahvistettava toistensa koodi.

tarkastuksia

Koodin näkeminen silmillä on siistiä, mutta ei tarpeeksi. Siksi automaattiset tarkastukset otetaan käyttöön.

• Ensinnäkin tarkistamme ARK kokoonpano.
• Paljon Junitin testit.
• Otamme huomioon koodin kattavuuden, koska olemme suorittamassa testejä.

Ymmärtääksemme, kuinka nämä tarkistukset tulisi suorittaa, katsotaanpa Aviton kehitysprosessia.

Se voidaan esittää kaavamaisesti seuraavasti:

• Kehittäjä kirjoittaa koodia kannettavalle tietokoneelleen. Voit suorittaa integraatiotarkistuksia täällä - joko commit-hookilla tai yksinkertaisesti suorittaa tarkistuksia taustalla.
• Kun kehittäjä on työntänyt koodin, hän avaa vetopyynnön. Jotta sen koodi voidaan sisällyttää kehityshaaraan, on välttämätöntä käydä läpi koodin tarkistus ja kerätä tarvittava määrä vahvistuksia. Voit ottaa tarkistukset ja koontiversiot käyttöön täällä: ennen kuin kaikki koontiversiot ovat onnistuneita, vetopyyntöä ei voida yhdistää.
• Kun vetopyyntö on yhdistetty ja koodi on sisällytetty kehittämiseen, voit valita sopivan ajankohdan: esimerkiksi yöllä, kun kaikki palvelimet ovat vapaita, ja suorittaa niin monta tarkistusta kuin haluat.

Kukaan ei halunnut suorittaa skannauksia kannettavalla tietokoneella. Kun kehittäjä on saanut valmiiksi ominaisuuden, hän haluaa työntää sen nopeasti ja avata vetopyynnön. Jos tällä hetkellä käynnistetään pitkiä tarkistuksia, se ei ole vain kovin miellyttävää, vaan myös hidastaa kehitystä: kun kannettava tietokone tarkistaa jotain, on mahdotonta työskennellä normaalisti.

Tykkäsimme kovasti yöllisten tarkastusten tekemisestä, koska aikaa ja palvelimia on paljon, voit vaeltaa ympäriinsä. Mutta valitettavasti, kun ominaisuuskoodi alkaa kehittyä, kehittäjällä on paljon vähemmän motivaatiota korjata CI:n löytämät virheet. Sain itseni aika ajoin ajattelemaan, kun katsoin kaikkia aamuraportista löytyneitä virheitä, että korjaan ne joskus myöhemmin, koska nyt Jirassa on uusi siisti tehtävä, jota haluan vain aloittaa.

Jos tarkastukset estävät vetopyynnön, motivaatiota riittää, koska ennen kuin koontiversiot muuttuvat vihreäksi, koodi ei pääse kehittämään, mikä tarkoittaa, että tehtävää ei suoriteta.

Tämän seurauksena valitsimme seuraavan strategian: suoritamme maksimimäärän mahdollisia tarkistuksia yöllä ja käynnistämme niistä kriittisimmät ja mikä tärkeintä, nopeimmat vetopyynnöllä. Emme kuitenkaan pysähdy tähän – samanaikaisesti optimoimme tarkastusten nopeuden siirtääksemme ne yötilasta pyyntötarkistuksiin.

Tuolloin kaikki koontiversiomme valmistuivat melko nopeasti, joten otimme yksinkertaisesti ARK-koontiversion, Junit-testit ja koodipeittolaskelmat pull-pyynnön estäjäksi. Otimme sen käyttöön, ajattelimme sitä ja hylkäsimme koodin peiton, koska ajattelimme, että emme tarvitse sitä.

Perus-CI:n täydellinen määrittäminen kesti kaksi päivää (tästä eteenpäin aika-arvio on likimääräinen, tarvitaan mittakaavassa).

Sen jälkeen aloimme miettiä edelleen - tarkistammeko edes oikein? Suoritammeko rakenteet vetopyyntöjen perusteella oikein?

Aloitimme rakentamisen sen haaran viimeisestä toimituksesta, josta vetopyyntö avattiin. Mutta tämän sitoumuksen testit voivat osoittaa vain, että kehittäjän kirjoittama koodi toimii. Mutta ne eivät todista, että hän ei rikkonut mitään. Itse asiassa sinun on tarkistettava kehityshaaran tila sen jälkeen, kun ominaisuus on yhdistetty siihen.

Tätä varten kirjoitimme yksinkertaisen bash-skriptin premerge.sh:

#!/usr/bin/env bash

set -e

git fetch origin develop

git merge origin/develop

Täällä kaikki kehitystyön viimeisimmät muutokset vedetään ylös ja yhdistetään nykyiseen haaraan. Lisäsimme premerge.sh-komentosarjan ensimmäiseksi vaiheeksi kaikkiin koontiversioihin ja aloimme tarkistaa, mitä haluamme, eli liittäminen.

Ongelman paikallistaminen, ratkaisun löytäminen ja tämän käsikirjoituksen kirjoittaminen kesti kolme päivää.

Sovellus kehittyi, tehtäviä ilmestyi yhä enemmän, tiimi kasvoi ja premerge.sh alkoi joskus pettää meitä. Developissa oli ristiriitaisia ​​muutoksia, jotka rikkoivat rakentamisen.

Esimerkki siitä, kuinka tämä tapahtuu:

Kaksi kehittäjää alkaa samanaikaisesti työstää ominaisuuksia A ja B. Ominaisuuden A kehittäjä löytää projektista käyttämättömän ominaisuuden answer() ja, kuten hyvä partiopoika, poistaa sen. Samalla ominaisuuden B kehittäjä lisää uuden kutsun tälle funktiolle haarassaan.

Kehittäjät lopettavat työnsä ja avaavat vetopyynnön samanaikaisesti. Rakennukset käynnistetään, premerge.sh tarkistaa molemmat viimeisimmän kehitystilan vetopyynnöt - kaikki tarkistukset ovat vihreitä. Sen jälkeen ominaisuuden A vetopyyntö yhdistetään, ominaisuuden B vetopyyntö... Boom! Develop-katkoja, koska kehityskoodi sisältää kutsun olemattomaan funktioon.

Kun se ei kehity, se kehittyy paikallinen katastrofi. Koko tiimi ei voi kerätä mitään ja lähettää sitä testattavaksi.

Niin tapahtui, että työskentelin useimmiten infrastruktuuritehtävissä: analytiikka, verkko, tietokannat. Eli minä kirjoitin ne funktiot ja luokat, joita muut kehittäjät käyttävät. Tämän vuoksi jouduin usein samanlaisiin tilanteisiin. Minulla oli jopa tämä kuva roikkumassa jonkin aikaa.

Koska tämä ei sopinut meille, aloimme tutkia vaihtoehtoja tämän estämiseksi.

Miten ei katkaista kehitystä

Ensimmäinen vaihtoehto: rakentaa uudelleen kaikki vetopyynnöt päivityksen yhteydessä. Jos esimerkissämme vetopyyntö ominaisuudella A on ensimmäinen, joka sisällytetään kehittämiseen, ominaisuuden B vetopyyntö rakennetaan uudelleen, ja vastaavasti tarkistukset epäonnistuvat käännösvirheen vuoksi.

Ymmärtääksesi kuinka kauan tämä kestää, harkitse esimerkkiä, jossa on kaksi PR:tä. Avaamme kaksi PR:tä: kaksi koontiversiota, kaksi tarkistusajoa. Kun ensimmäinen PR on yhdistetty kehittämiseen, toinen on rakennettava uudelleen. Yhteensä kaksi PR:tä vaatii kolme tarkistusta: 2 + 1 = 3.

Periaatteessa ihan ok. Mutta katsoimme tilastoja, ja tyypillinen tilanne tiimissämme oli 10 avointa PR:tä, ja sitten tarkistusten määrä on etenemisen summa: 10 + 9 +... + 1 = 55. Eli hyväksyä 10 PR:t, sinun on rakennettava uudelleen 55 kertaa. Ja tämä on ihanteellinen tilanne, kun kaikki tarkastukset läpäisevät ensimmäisen kerran, kun kukaan ei avaa ylimääräistä vetopyyntöä näiden tusinan käsittelyn aikana.

Kuvittele itsesi kehittäjänä, jonka täytyy ensimmäisenä napsauttaa "yhdistä"-painiketta, koska jos naapuri tekee tämän, sinun on odotettava, kunnes kaikki versiot menevät uudelleen läpi... Ei, se ei toimi , se hidastaa kehitystä vakavasti.

Toinen mahdollinen tapa: kerätä vetopyyntöjä koodin tarkistuksen jälkeen. Toisin sanoen avaat pull-pyynnön, keräät tarvittavan määrän hyväksyntöjä kollegoilta, korjaat mitä tarvitaan ja käynnistät sitten koontiversiot. Jos ne onnistuvat, vetopyyntö yhdistetään kehittämiseen. Tässä tapauksessa ei ole ylimääräistä uudelleenkäynnistystä, mutta palaute hidastuu huomattavasti. Kehittäjänä, kun avaan vetopyynnön, haluan heti nähdä, toimiiko se. Jos esimerkiksi testi epäonnistuu, sinun on korjattava se nopeasti. Viivästyneen rakentamisen tapauksessa palaute hidastuu ja siten koko kehitys. Tämäkään ei sopinut meille.

Seurauksena oli vain kolmas vaihtoehto - pyörä. Kaikki koodimme, kaikki lähteemme on tallennettu Bitbucket-palvelimen arkistoon. Näin ollen meidän piti kehittää laajennus Bitbucketille.

Tämä laajennus ohittaa vetopyynnön yhdistämismekanismin. Alku on vakio: PR avautuu, kaikki kokoonpanot käynnistetään, koodin tarkistus on valmis. Mutta kun koodin tarkistus on valmis ja kehittäjä päättää napsauttaa "yhdistä", laajennus tarkistaa, mihin kehitystilaan tarkastukset suoritettiin. Jos kehitystä on päivitetty käännösten jälkeen, laajennus ei salli tällaisen vetopyynnön yhdistämistä päähaaraan. Se yksinkertaisesti käynnistää uudelleen suhteellisen tuoreen kehitystyön koontiversiot.

Esimerkissämme, jossa on ristiriitaisia ​​muutoksia, tällaiset koontiversiot epäonnistuvat käännösvirheen vuoksi. Näin ollen ominaisuuden B kehittäjän on korjattava koodi, käynnistettävä tarkistukset uudelleen, minkä jälkeen laajennus ottaa automaattisesti käyttöön vetopyynnön.

Ennen tämän laajennuksen käyttöönottoa arvioimme keskimäärin 2,7 tarkistusajoa vetopyyntöä kohti. Laajennuksen kanssa käynnistyi 3,6 kertaa. Tämä sopi meille.

On syytä huomata, että tällä laajennuksella on haittapuoli: se käynnistää rakennuksen uudelleen vain kerran. Eli vielä on pieni ikkuna, jonka läpi ristiriitaiset muutokset voivat kehittyä. Mutta tämän todennäköisyys on pieni, ja teimme tämän kompromissin käynnistysten määrän ja epäonnistumisen todennäköisyyden välillä. Kahdessa vuodessa se laukesi vain kerran, joten se ei luultavasti ollut turhaa.

Bitbucket-laajennuksen ensimmäisen version kirjoittaminen kesti kaksi viikkoa.

Uudet shekit

Samaan aikaan tiimimme kasvoi edelleen. Uusia shekkejä on lisätty.

Ajattelimme: miksi tehdä virheitä, jos ne voidaan estää? Ja siksi ne toteutettiin staattinen koodianalyysi. Aloitimme nukkaalla, joka sisältyy Android SDK:han. Mutta tuolloin hän ei osannut työskennellä Kotlin-koodin kanssa ollenkaan, ja meillä oli jo 75% sovelluksesta kirjoitettu Kotlinilla. Siksi nukkaan lisättiin sisäänrakennetut Android Studio tarkistaa.

Tätä varten meidän piti tehdä paljon perverssiä: ottaa Android Studio, pakata se Dockeriin ja ajaa se CI:ssä virtuaalisella näytöllä, jotta se luulee toimivansa oikealla kannettavalla tietokoneella. Mutta se toimi.

Tänä aikana aloimme myös kirjoittaa paljon instrumentointitestit ja toteutettu screenshot-testaus. Tällöin erilliselle pienelle näkymälle luodaan referenssikuvakaappaus ja testi koostuu siitä, että otetaan kuvakaappaus näkymästä ja verrataan sitä tavalliseen suoraan pikseli kerrallaan. Jos on ristiriita, se tarkoittaa, että asettelu on mennyt pieleen jossain tai jotain on vialla tyyleissä.

Mutta instrumentointitestit ja kuvakaappaustestit on suoritettava laitteilla: emulaattoreissa tai oikeissa laitteissa. Ottaen huomioon, että testejä on paljon ja niitä ajetaan usein, tarvitaan koko maatila. Oman tilan perustaminen on liian työlästä, joten löysimme valmiin vaihtoehdon - Firebase Test Lab.

Firebase Test Lab

Se valittiin, koska Firebase on Googlen tuote, mikä tarkoittaa, että sen pitäisi olla luotettava ja tuskin koskaan kuolee. Hinnat ovat kohtuulliset: 5 dollaria todellisen laitteen käyttötunnilta, 1 dollari emulaattorin käyttötunnilta.

Firebase Test Labin käyttöönotto CI:ssämme kesti noin kolme viikkoa.

Mutta tiimi jatkoi kasvuaan, ja Firebase alkoi valitettavasti pettää meitä. Tuolloin hänellä ei ollut SLA:ta. Joskus Firebase sai meidät odottamaan, kunnes tarvittava määrä laitteita oli vapaana testeihin, eikä aloittanut niiden suorittamista heti, kuten halusimme. Jonotus kesti jopa puoli tuntia, mikä on todella pitkä aika. Instrumentointitestit ajettiin joka PR:lle, viiveet todella hidastivat kehitystä, ja sitten kuukausilaskussa tuli pyöreä summa. Yleensä päätettiin luopua Firebasesta ja työskennellä talon sisällä, koska tiimi oli kasvanut tarpeeksi.

Docker + Python + bash

Otimme Dockerin, laitoimme siihen emulaattoreita, kirjoitimme Pythonissa yksinkertaisen ohjelman, joka oikealla hetkellä tuo esiin tarvittavan määrän emulaattoreita vaaditussa versiossa ja pysäyttää ne tarvittaessa. Ja tietysti pari bash-skriptiä – missä olisimme ilman niitä?

Oman testiympäristön luominen kesti viisi viikkoa.

Tämän seurauksena jokaista vetopyyntöä kohden oli laaja yhdistämisen estävä tarkistusluettelo:

• ARK kokoonpano;
• Junit testit;
• Nukka;
• Android Studio tarkistaa;
• Instrumentointitestit;
• Screenshot testit.

Tämä esti monet mahdolliset häiriöt. Teknisesti kaikki toimi, mutta kehittäjät valittivat, että tulosten odotus oli liian pitkä.

Kuinka pitkä on liian pitkä? Latasimme Bitbucketin ja TeamCityn tiedot analyysijärjestelmään ja huomasimme sen keskimääräinen odotusaika 45 minuuttia. Toisin sanoen kehittäjä odottaa vetopyyntöä avaaessaan keskimäärin 45 minuuttia koontituloksia. Mielestäni tämä on paljon, etkä voi työskennellä niin.

Tietysti päätimme nopeuttaa kaikkia rakentamiamme.

Nopeutetaan

Koska rakennukset seisovat usein jonossa, teemme ensimmäisenä osti lisää laitteita — Laaja kehittäminen on yksinkertaisinta. Rakennukset lopettivat jonottamisen, mutta odotusaika lyheni vain hieman, koska jotkin tarkastukset itse kestivät hyvin kauan.

Liian kauan vievien tarkistusten poistaminen

Jatkuva integraatiomme voi havaita tämäntyyppisiä virheitä ja ongelmia.

• Ei aio. CI voi havaita käännösvirheen, kun jotain ei rakenneta ristiriitaisten muutosten vuoksi. Kuten jo sanoin, kukaan ei voi koota mitään, kehitys pysähtyy ja kaikki hermostuvat.
• Virhe käytöksessä. Esimerkiksi kun sovellus on rakennettu, mutta se kaatuu, kun painat painiketta tai painiketta ei paineta ollenkaan. Tämä on huono asia, koska tällainen bugi voi tavoittaa käyttäjän.
• Virhe asettelussa. Esimerkiksi painiketta napsautetaan, mutta se on siirtynyt 10 pikseliä vasemmalle.
• Teknisen velan kasvu.

Katsottuamme tätä luetteloa huomasimme, että vain kaksi ensimmäistä kohtaa ovat kriittisiä. Haluamme saada sellaiset ongelmat ensin kiinni. Asetteluvirheet havaitaan suunnittelu-tarkistusvaiheessa, ja ne voidaan sitten helposti korjata. Teknisen velan käsittely vaatii erillisen prosessin ja suunnittelun, joten päätimme olla testaamatta sitä vetopyynnöllä.

Tämän luokituksen perusteella ravistelimme koko shekkiluetteloa. Lint yliviivattu ja lykkäsi sen käynnistämistä yöksi: vain siksi, että se tekisi raportin siitä, kuinka monta ongelmaa hankkeessa oli. Sovimme työskentelevämme erikseen teknisen velan kanssa, ja Android Studion tarkistukset hylättiin kokonaan. Android Studio Dockerissa tarkastusten suorittamiseen kuulostaa mielenkiintoiselta, mutta aiheuttaa paljon ongelmia tuessa. Kaikki päivitykset Android Studio -versioihin merkitsevät kamppailua käsittämättömien virheiden kanssa. Myös screenshot-testien tukeminen oli vaikeaa, koska kirjasto ei ollut kovin vakaa ja siinä oli vääriä positiivisia tuloksia. Screenshot-testit on poistettu tarkistuslistalta.

Tämän seurauksena meille jäi:

• ARK kokoonpano;
• Junit testit;
• Instrumentointitestit.

Gradlen etävälimuisti

Ilman raskaita tarkastuksia kaikki parani. Mutta täydellisyydellä ei ole rajaa!

Sovelluksemme oli jo jaettu noin 150 asteikkomoduuliin. Gradlen etävälimuisti toimii yleensä hyvin tässä tapauksessa, joten päätimme kokeilla sitä.

Gradle-etävälimuisti on palvelu, joka voi tallentaa välimuistiin yksittäisten moduulien yksittäisten tehtävien artefakteja. Gradle koodin kääntämisen sijaan koputtaa etävälimuistiin HTTP:n avulla ja kysyy, onko joku jo suorittanut tämän tehtävän. Jos kyllä, se yksinkertaisesti lataa tuloksen.

Gradlen etävälimuistin käyttäminen on helppoa, koska Gradle tarjoaa Docker-kuvan. Pystyimme tekemään tämän kolmessa tunnissa.

Sinun piti vain käynnistää Docker ja kirjoittaa yksi rivi projektiin. Mutta vaikka se voidaan käynnistää nopeasti, kestää melko paljon aikaa, ennen kuin kaikki toimii hyvin.

Alla on välimuistin puuttumiskaavio.

Heti alussa välimuistin poissaoloprosentti oli noin 65. Kolmen viikon jälkeen onnistuimme nostamaan tämän arvon 20 prosenttiin. Kävi ilmi, että Android-sovelluksen keräämillä tehtävillä on outoja transitiivisia riippuvuuksia, joiden vuoksi Gradle jäi välimuistista paitsi.

Välimuistin yhdistäminen nopeuti rakentamista huomattavasti. Mutta kokoonpanon lisäksi on myös instrumentointitestejä, ja ne vievät kauan. Kaikkia testejä ei ehkä tarvitse suorittaa jokaista vetopyyntöä varten. Selvittääksemme käytämme vaikutusanalyysiä.

Vaikutusanalyysi

Keräämme vetopyynnöstä git diff:n ja löydämme muokatut Gradle-moduulit.

On järkevää suorittaa vain instrumentointitestejä, jotka tarkistavat muuttuneet moduulit ja kaikki niistä riippuvat moduulit. Ei ole mitään järkeä testata viereisiä moduuleita: siellä oleva koodi ei ole muuttunut eikä mikään voi rikkoutua.

Instrumentointitestit eivät ole niin yksinkertaisia, koska ne on sijoitettava ylätason sovellusmoduuliin. Käytimme heuristiikkaa tavukoodianalyysin kanssa ymmärtääksemme, mihin moduuliin kukin testi kuuluu.

Instrumentointitestien toiminnan päivittäminen siten, että ne testaavat vain mukana olevia moduuleja, kesti noin kahdeksan viikkoa.

Tarkastuksia nopeuttavat toimenpiteet ovat toimineet menestyksekkäästi. 45 minuutista nousimme noin 15:een. On jo normaalia odottaa neljännestuntia rakentamista.

Mutta nyt kehittäjät ovat alkaneet valittaa siitä, etteivät he ymmärrä, mitä koontiversioita käynnistetään, missä nähdään loki, miksi versio on punainen, mikä testi epäonnistui jne.

Palauteongelmat hidastavat kehitystä, joten yritimme tarjota mahdollisimman selkeää ja yksityiskohtaista tietoa jokaisesta PR:stä ja rakentamisesta. Aloitimme kommenteilla Bitbucketissa PR:lle, mikä osoitti mikä koontiversio epäonnistui ja miksi, ja kirjoitimme kohdistettuja viestejä Slackiin. Lopulta loimme sivulle PR-hallintapaneelin, jossa on luettelo kaikista tällä hetkellä käynnissä olevista koontiversioista ja niiden tilasta: jonossa, käynnissä, kaatunut tai valmis. Voit napsauttaa rakennetta ja siirtyä sen lokiin.

Kuusi viikkoa käytettiin yksityiskohtaiseen palautteeseen.

suunnitelmat

Siirrytään lähihistoriaan. Palauteongelman ratkaistua pääsimme uudelle tasolle - päätimme rakentaa oman emulaattorifarmimme. Kun testejä ja emulaattoreita on paljon, niitä on vaikea hallita. Tämän seurauksena kaikki emulaattorimme siirtyivät k8s-klusteriin joustavan resurssienhallinnan avulla.

Lisäksi on muita suunnitelmia.

• Palauta Lint (ja muu staattinen analyysi). Työskentelemme jo tähän suuntaan.
• Suorita kaikki PR-estäjällä päästä päähän -testejä kaikissa SDK-versioissa.

Olemme siis jäljittäneet jatkuvan integraation kehityksen historiaa Avitossa. Haluan nyt antaa neuvoja kokeneen näkökulmasta.

Советы

Jos voisin antaa vain yhden neuvon, se olisi tämä:

Ole varovainen shell-skriptien kanssa!

Bash on erittäin joustava ja tehokas työkalu, se on erittäin kätevä ja nopea kirjoittaa skriptejä. Mutta voit pudota sen kanssa ansaan, ja valitettavasti me jouduimme siihen.

Kaikki alkoi yksinkertaisista komentosarjoista, jotka suoritettiin rakennuskoneillamme:

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

Mutta kuten tiedät, kaikki kehittyy ja muuttuu monimutkaisemmaksi ajan myötä - ajellaan skriptiä toisesta, siirretään sinne joitain parametreja - lopulta piti kirjoittaa funktio, joka määrittää, millä bash-pesätystasolla olemme nyt kunnossa. lisätäksesi tarvittavat lainausmerkit saadaksesi kaiken alkuun.

Voit kuvitella tällaisten skriptien kehittämisen työvoimakustannukset. Suosittelen, ettet joutuisi tähän ansaan.

Mitä voidaan korvata?

• Mikä tahansa skriptikieli. Kirjoittaa Python tai Kotlin Script helpompaa, koska se on ohjelmointia, ei komentosarjoja.
• Tai kuvaile lomakkeessa koko rakennuslogiikka Räätälöidyt luokkatyötehtävät projektillesi.

Päätimme valita toisen vaihtoehdon, ja nyt poistamme järjestelmällisesti kaikki bash-skriptit ja kirjoitamme paljon mukautettuja gradle-tehtäviä.

Vinkki 2: Tallenna infrastruktuuri koodiin.

Se on kätevää, kun Continuous Integration -asetusta ei ole tallennettu Jenkinsin tai TeamCityn jne. käyttöliittymään, vaan tekstitiedostoina suoraan projektivarastoon. Tämä antaa versioitettavuuden. Koodin palauttaminen tai rakentaminen toiselle haaralle ei ole vaikeaa.

Skriptejä voidaan tallentaa projektiin. Mitä tehdä ympäristön kanssa?

Vinkki 3: Docker voi auttaa ympäristössä.

Se auttaa varmasti Android-kehittäjiä; iOS:llä ei valitettavasti vielä ole sellaista.

Tämä on esimerkki yksinkertaisesta Docker-tiedostosta, joka sisältää 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

Kun olet kirjoittanut tämän Docker-tiedoston (kerron sinulle salaisuuden, sinun ei tarvitse kirjoittaa sitä, vaan vedä se valmiiksi GitHubista) ja kokoanut kuvan, saat virtuaalikoneen, jolle voit rakentaa sovelluksen ja suorita Junit-testejä.

Kaksi tärkeintä syytä, miksi tämä on järkevää, ovat skaalautuvuus ja toistettavuus. Dockerin avulla voit nopeasti nostaa tusinaa koontiagenttia, joilla on täsmälleen sama ympäristö kuin edellisellä. Tämä helpottaa CI-insinöörien elämää paljon. Android-sdk:n työntäminen dockeriin on melko helppoa, mutta emulaattoreiden kanssa se on hieman vaikeampaa: sinun on työskenneltävä hieman kovemmin (tai ladattava valmis GitHubista uudelleen).

Vinkki nro 4: älä unohda, että tarkastuksia ei tehdä tarkastusten vuoksi, vaan ihmisiä varten.

Nopea ja mikä tärkeintä, selkeä palaute on erittäin tärkeää kehittäjille: mikä meni rikki, mikä testi epäonnistui, mistä voin nähdä rakennuslokin.

Vinkki 5: Ole käytännöllinen kehittäessäsi jatkuvaa integraatiota.

Ymmärrä selvästi, minkä tyyppiset virheet haluat estää, kuinka paljon resursseja, aikaa ja tietokoneaikaa olet valmis käyttämään. Liian kauan kestäneet tarkastukset voidaan esimerkiksi siirtää yön yli. Ja niistä, jotka havaitsevat vähemmän tärkeitä virheitä, tulisi hylätä kokonaan.

Vinkki 6: Käytä valmiita työkaluja.

Nyt on monia yrityksiä, jotka tarjoavat pilvipalvelua.

Tämä on hyvä ratkaisu pienille ryhmille. Sinun ei tarvitse tukea mitään, maksat vain vähän rahaa, rakennat sovelluksesi ja jopa suoritat instrumentointitestejä.

Vinkki 7: Suuressa tiimissä talon sisäiset ratkaisut ovat kannattavampia.

Mutta ennemmin tai myöhemmin, kun tiimi kasvaa, talon sisäisistä ratkaisuista tulee kannattavampia. Näissä päätöksissä on yksi ongelma. Taloustieteessä vallitsee pienenevän tuoton laki: kaikissa projekteissa jokainen myöhempi parannus on yhä vaikeampaa ja vaatii yhä enemmän investointeja.

Taloustiede kuvaa koko elämäämme, mukaan lukien jatkuva integraatio. Tein työvoimakustannusaikataulun jatkuvan integraation jokaiselle kehitysvaiheelle.

On selvää, että parantaminen on yhä vaikeampaa. Tätä kaaviota katsomalla voit ymmärtää, että jatkuvaa integraatiota on kehitettävä joukkueen koon kasvun mukaisesti. Kahden hengen tiimille 50 päivän käyttäminen sisäisen emulaattorifarmin kehittämiseen on keskinkertainen idea. Mutta samaan aikaan suurelle tiimille Jatkuvan integroinnin tekemättä jättäminen on myös huono idea, koska integraatioongelmia, kommunikoinnin korjaamista jne. se vie vielä enemmän aikaa.

Aloitimme ajatuksesta, että automaatiota tarvitaan, koska ihmiset ovat kalliita, tekevät virheitä ja ovat laiskoja. Mutta ihmiset myös automatisoivat. Siksi kaikki samat ongelmat koskevat automaatiota.

• Automaatio on kallista. Muista työaikataulu.
• Mitä tulee automaatioon, ihmiset tekevät virheitä.
• Joskus on erittäin laiska automatisoida, koska kaikki toimii niin. Miksi parantaa mitään muuta, miksi tämä jatkuva integraatio?

Mutta minulla on tilastot: virheet havaitaan 20 prosentissa kokoonpanoista. Ja tämä ei johdu siitä, että kehittäjämme kirjoittavat koodia huonosti. Tämä johtuu siitä, että kehittäjät ovat varmoja siitä, että jos he tekevät virheen, se ei päädy kehittämiseen, vaan se jää automaattisten tarkistusten kiinni. Näin ollen kehittäjät voivat käyttää enemmän aikaa koodin ja mielenkiintoisten asioiden kirjoittamiseen sen sijaan, että suorittaisivat ja testasivat jotain paikallisesti.

Harjoittele jatkuvaa integraatiota. Mutta kohtuudella.

Muuten, Nikolai Nesterov ei ainoastaan ​​anna upeita raportteja itse, vaan on myös ohjelmakomitean jäsen AppsConf ja auttaa muita valmistelemaan sinulle merkityksellisiä puheita. Seuraavan konferenssiohjelman täydellisyyttä ja hyödyllisyyttä voidaan arvioida aiheittain ajoittaa. Ja lisätietoja, tule Infospaceen 22.-23.

Lähde: will.com