Tsjintwurdich wurde de measte softwareprodukten ûntwikkele yn teams. De betingsten foar suksesfolle teamûntwikkeling kinne wurde fertsjintwurdige yn 'e foarm fan in ienfâldich diagram.

As jo ​​​​ienris jo koade skreaun hawwe, moatte jo der wis fan wêze:

1. Wurkje.
2. It brekt neat, ynklusyf de koade dy't jo kollega's skreaun hawwe.

As oan beide betingsten foldien wurdt, dan binne jo op it paad nei sukses. Om maklik te kontrolearjen dizze betingsten en net ôfwike fan it rendabel paad, wy kamen mei Continuous Integration.

CI is in workflow wêr't jo jo koade sa faak mooglik yntegrearje yn 'e totale produktkoade. En jo yntegrearje net allinich, mar kontrolearje ek konstant dat alles wurket. Om't jo in protte en faak moatte kontrolearje, is it wurdich te tinken oer automatisearring. Jo kinne kontrolearje alles mei de hân, mar do moatst net, en hjir is wêrom.

• Bêste minsken. In oere wurk fan elke programmeur is djoerder dan in oere wurk fan elke server.
• Minsken meitsje flaters. Dêrom kinne situaasjes ûntstean as tests waarden útfierd op 'e ferkearde branch of de ferkearde commit waard gearstald foar testers.
• Minsken binne lui. Sa no en dan, as ik in taak ôfmeitsje, komt de gedachte op: “Wat is der te kontrolearjen? Ik skreau twa rigels - alles wurket! Ik tink dat guon fan jim ek wolris sokke gedachten hawwe. Mar jo moatte altyd kontrolearje.

Hoe Continuous Integration waard ymplementearre en ûntwikkele yn it Avito mobile ûntwikkelingsteam, hoe't se gongen fan 0 nei 450 builds per dei, en dat bouwmasines 200 oeren deis gearstalle, seit Nikolai Nesterov (nnesterov) is in dielnimmer oan alle evolúsjonêre feroarings fan 'e CI / CD Android-applikaasje.

It ferhaal is basearre op it foarbyld fan in Android-kommando, mar de measte oanpak binne ek fan tapassing op iOS.

Eartiids wurke ien persoan yn it Avito Android-team. By definysje hie er neat nedich fan Continuous Integration: der wie gjinien om mei te yntegrearjen.

Mar de applikaasje groeide, mear en mear nije taken ferskynden, en it team groeide dêrmei. Op in stuit is it tiid om mear formeel in proses foar yntegraasje fan koade te fêstigjen. It waard besletten om Git flow te brûken.

It konsept fan Git-flow is goed bekend: in projekt hat ien mienskiplike ûntwikkeltûke, en foar elke nije funksje snije ûntwikkelders in aparte tûke, commit har oan, triuwe, en as se har koade wolle gearfoegje yn 'e ûntwikkeltûke, iepenje in pull fersyk. Om kennis te dielen en oanpak te besprekken, hawwe wy koadebeoardieling yntrodusearre, dat wol sizze dat kollega's elkoars koade moatte kontrolearje en befêstigje.

Kontrolearje

Sjoch koade mei dyn eagen is cool, mar net genôch. Dêrom wurde automatyske kontrôles ynfierd.

• Earst kontrolearje wy ARK gearstalling.
• In soad Junit tests.
• Wy beskôgje koade dekking, sûnt wy rinne tests.

Om te begripen hoe't dizze kontrôles moatte wurde útfierd, litte wy sjen nei it ûntwikkelingsproses yn Avito.

It kin skematysk werjûn wurde as dit:

• In ûntwikkelder skriuwt koade op syn laptop. Jo kinne hjir yntegraasjekontrôles útfiere - itsij mei in commit-haak, of gewoan kontrôles op 'e eftergrûn útfiere.
• Nei't de ûntwikkelder de koade yndrukt hat, iepenet hy in pull-fersyk. Om syn koade op te nimmen yn 'e ûntwikkelingstak, is it nedich om in koadebeoardieling te gean en it fereaske oantal befêstigingen te sammeljen. Jo kinne kontrôles en builds hjir ynskeakelje: oant alle builds suksesfol binne, kin it pull-fersyk net gearfoege wurde.
• Nei't it pull-fersyk is gearfoege en de koade is opnommen yn 'e ûntwikkeling, kinne jo in handige tiid kieze: bygelyks nachts, as alle tsjinners fergees binne, en safolle kontrôles útfiere as jo wolle.

Nimmen mocht graach scans útfiere op har laptop. As in ûntwikkelder in funksje foltôge hat, wol hy it fluch triuwe en in pull-fersyk iepenje. As op dit stuit wat lange kontrôles wurde lansearre, is dit net allinich net heul noflik, mar fertraget ek de ûntwikkeling: wylst de laptop wat kontrolearret, is it ûnmooglik om der normaal oan te wurkjen.

We hiel graach rinne kontrôles nachts, want der is in protte tiid en tsjinners, kinne jo roame om. Mar, spitigernôch, as de funksje-koade yn ûntwikkeling komt, hat de ûntwikkelder folle minder motivaasje om de flaters te reparearjen dy't CI fûn. Ik haw mysels periodyk betrape mei it tinken doe't ik seach nei alle flaters fûn yn 'e moarnsrapport dat ik se letter noch reparearje soe, want no is der in koele nije taak yn Jira dy't ik gewoan begjinne wol.

As kontrôles in pull-oanfraach blokkearje, dan is d'r genôch motivaasje, want oant de builds grien wurde, sil de koade net yn ûntwikkeling komme, wat betsjut dat de taak net foltôge wurdt.

As gefolch, wy keas de folgjende strategy: wy rinne de maksimum mooglike set fan kontrôles nachts, en lansearje de meast krityske fan harren en, vooral, de fluchste op in pull fersyk. Mar wy stopje dêr net - parallel optimalisearje wy de snelheid fan kontrôles om se oer te setten fan 'e nachtmodus om fersykkontrôles te lûken.

Op dat stuit waarden al ús builds frij fluch foltôge, dus wy hawwe gewoan de ARK-build, Junit-tests en berekkeningen foar koadedekking opnommen as in blokker foar it pull-fersyk. Wy hawwe it oansetten, deroer tocht en koadedekking ferlitten, om't wy tochten dat wy it net nedich hienen.

It hat ús twa dagen duorre om de basis-CI folslein op te setten (hjirnei is de tiidskatting sawat, nedich foar skaal).

Dêrnei begûnen wy fierder te tinken - kontrolearje wy sels goed? Kinne wy ​​builds op pull-oanfragen korrekt útfiere?

Wy begûnen de bou op 'e lêste commit fan' e tûke wêrfan it pull-fersyk iepene waard. Mar testen fan dizze commit kinne allinich sjen litte dat de koade dy't de ûntwikkelder skreau wurket. Mar se bewize net dat er neat brutsen hat. Yn feite moatte jo de steat fan 'e ûntwikkeltak kontrolearje nei't in funksje dêryn is gearfoege.

Om dit te dwaan, hawwe wy in ienfâldich bash-skript skreaun premerge.sh:

#!/usr/bin/env bash

set -e

git fetch origin develop

git merge origin/develop

Hjir wurde alle lêste feroarings fan ûntwikkeling gewoan ophelle en gearfoege yn 'e hjoeddeistige branch. Wy hawwe it premerge.sh-skript tafoege as de earste stap yn alle builds en begon te kontrolearjen krekt wat wy wolle, dat is yntegraasje.

It duorre trije dagen om it probleem te lokalisearjen, in oplossing te finen en dit skript te skriuwen.

De applikaasje ûntwikkele, mear en mear taken ferskynden, it team groeide, en premerge.sh begon ús soms yn 'e steek te litten. Develop hie tsjinstridige feroaringen dy't de bou bruts.

In foarbyld fan hoe't dit bart:

Twa ûntwikkelders begjinne tagelyk te wurkjen oan funksjes A en B. De ûntwikkelder fan funksje A ûntdekt in net brûkte funksje yn it projekt answer() en, as in goede jonge scout, ferwideret it. Tagelyk foeget de ûntwikkelder fan funksje B in nije oprop ta oan dizze funksje yn syn branch.

Untwikkelders meitsje har wurk ôf en iepenje tagelyk in pull-fersyk. De builds wurde lansearre, premerge.sh kontrolearret beide pull-oanfragen oangeande de lêste ûntwikkelingssteat - alle kontrôles binne grien. Dêrnei wurdt it pull-fersyk fan funksje A gearfoege, it pull-fersyk fan funksje B wurdt gearfoege... Boom! Untwikkelje brekten om't de ûntwikkelkoade in oprop befettet nei in net-besteande funksje.

As it net sil ûntwikkelje, is it it lokale ramp. It hiele team kin neat sammelje en yntsjinje foar testen.

It barde sa dat ik meast wurke oan ynfrastruktuertaken: analytyk, netwurk, databases. Dat is, it wie ik dy't dy funksjes en klassen skreau dy't oare ûntwikkelders brûke. Hjirtroch fûn ik mysels heul faak yn ferlykbere situaasjes. Ik hie dizze foto sels in skoft hingjen.

Om't dit ús net paste, begûnen wy opsjes te ferkennen oer hoe't jo dit kinne foarkomme.

Hoe net te brekken ûntwikkelje

De earste opsje: werbouwe alle pull-oanfragen by it bywurkjen fan ûntwikkeljen. As, yn ús foarbyld, it pull-fersyk mei funksje A de earste is dy't opnommen is yn ûntwikkeling, sil it pull-fersyk fan funksje B opnij wurde opboud, en sadwaande sille de kontrôles mislearje fanwege in kompilaasjeflater.

Om te begripen hoe lang dit sil nimme, beskôgje in foarbyld mei twa PR's. Wy iepenje twa PR's: twa builds, twa runen fan kontrôles. Nei't de earste PR is gearfoege yn ûntwikkeling, moat de twadde wer opboud wurde. Yn totaal fereaskje twa PR's trije runen fan kontrôles: 2 + 1 = 3.

Yn prinsipe is it goed. Mar wy seagen nei de statistiken, en de typyske situaasje yn ús team wie 10 iepen PR's, en dan is it oantal kontrôles de som fan 'e foarútgong: 10 + 9 +... + 1 = 55. Dat is, om 10 te akseptearjen PR's, jo moatte 55 kear opnij bouwe. En dit is yn in ideale situaasje, as alle kontrôles de earste kear passe, as gjinien in ekstra pull-oanfraach iepenet wylst dizze tsientallen wurde ferwurke.

Stel jo sels foar as in ûntwikkelder dy't de earste wêze moat dy't op de knop "fusje" klikt, want as in buorman dit docht, dan moatte jo wachtsje oant alle bouwurken wer troch binne... Nee, dat sil net wurkje , it sil de ûntwikkeling serieus fertrage.

Twadde mooglike manier: sammelje pull fersiken nei koade review. Dat is, jo iepenje in pull-fersyk, sammelje it fereaske oantal goedkarring fan kollega's, korrigearje wat nedich is, en start dan de builds. As se suksesfol binne, wurdt it pull-fersyk gearfoege yn ûntwikkeling. Yn dit gefal binne d'r gjin ekstra herstarten, mar de feedback is sterk fertrage. As ûntwikkelder, as ik in pull-oanfraach iepenje, wol ik fuortendaliks sjen oft it wurket. Bygelyks, as in test mislearret, moatte jo it fluch reparearje. Yn it gefal fan in fertrage build, feedback fertraget, en dus de hiele ûntwikkeling. Dit paste ús ek net.

As resultaat bleau allinich de tredde opsje oer - fytse. Al ús koade, al ús boarnen wurde opslein yn in repository op de Bitbucket-tsjinner. Dêrtroch moasten wy in plugin ûntwikkelje foar Bitbucket.

Dizze plugin oerskriuwt it gearfoegjenmeganisme fan pull-fersyk. It begjin is standert: de PR iepenet, alle gearkomsten wurde lansearre, koadebeoardieling is foltôge. Mar nei't de koadebeoardieling foltôge is en de ûntwikkelder beslút te klikken op "fusearje", kontrolearret de plugin tsjin hokker ûntwikkelingssteat de kontrôles waarden útfierd. As ûntwikkeling is bywurke nei de builds, sil de plugin net tastean dat sa'n pull-oanfraach wurdt gearfoege yn 'e haadtûke. It sil gewoan de builds fan in relatyf resinte ûntwikkeling opnij starte.

Yn ús foarbyld mei tsjinstridige feroarings sille sokke builds mislearje fanwege in kompilaasjeflater. Dêrtroch sil de ûntwikkelder fan funksje B de koade moatte korrigearje, de kontrôles opnij starte, dan sil de plugin automatysk it pull-fersyk tapasse.

Foardat wy dizze plugin ymplementearje, hawwe wy gemiddeld 2,7 beoardielingsrinnen per pull-oanfraach. Mei de plugin wiene d'r 3,6 lansearringen. Dit paste ús.

It is de muoite wurdich op te merken dat dizze plugin in nadeel hat: it begjint de bou mar ien kear op 'e nij. Dat is, d'r bliuwt noch in lyts finster troch dêr't tsjinstridige feroarings trochhinne komme kinne. Mar de kâns hjirfan is leech, en wy makken dizze ôfwikseling tusken it oantal starts en de kâns op mislearring. Yn twa jier foel it mar ien kear, dus it wie nei alle gedachten net om 'e nocht.

It hat ús twa wiken duorre om de earste ferzje fan it Bitbucket-plugin te skriuwen.

Nije sjeks

Underwilens bleau ús team groeie. Nije sjeks binne tafoege.

Wy tochten: wêrom flaters meitsje as se foarkommen wurde kinne? En dat is wêrom se útfierd statyske koade analyze. Wy binne begûn mei lint, dat is opnaam yn 'e Android SDK. Mar op dat stuit hy wist net hoe te wurkjen mei Kotlin koade hielendal, en wy hiene al 75% fan de applikaasje skreaun yn Kotlin. Dêrom waarden ynboude oan lint tafoege Android Studio kontrolearret.

Om dit te dwaan, moasten wy in protte pervertearje: nim Android Studio, pak it yn Docker en rinne it op CI mei in firtuele monitor, sadat it tinkt dat it rint op in echte laptop. Mar it wurke.

It wie ek yn dizze tiid dat wy in protte begûnen te skriuwen ynstrumintaasje tests en útfierd screenshot testen. Dit is as in ferwizing skermprint wurdt oanmakke foar in aparte lytse werjefte, en de test bestiet út in nimme in skermprint út de werjefte en ferlykje it mei de standert direkt piksel foar piksel. As der in diskrepânsje is, betsjut dit dat de yndieling earne ferkeard gien is of dat der wat mis is yn 'e stilen.

Mar ynstrumintaasjetests en screenshottests moatte wurde útfierd op apparaten: op emulators as op echte apparaten. Yn betinken nommen dat der in soad proeven binne en dy wurde faak útfierd, is in hiele pleats nedich. Jo eigen pleats begjinne is te arbeidsintensyf, dus wy fûnen in klearmakke opsje - Firebase Test Lab.

Firebase Test Lab

It waard keazen om't Firebase in Google-produkt is, wat betsjuttet dat it betrouber wêze moat en net wierskynlik oait stjerre sil. De prizen binne ridlik: $ 5 per oere fan wurking fan in echte apparaat, 1 $ per oere fan operaasje fan in emulator.

It duorre sawat trije wiken om Firebase Test Lab yn ús CI te ymplementearjen.

Mar it team bleau te groeien, en Firebase, spitigernôch, begon ús te litten. Op dat stuit hie hy gjin SLA. Soms liet Firebase ús wachtsje oant it fereaske oantal apparaten fergees wie foar testen, en begon se net fuortendaliks út te fieren, lykas wy woene. It wachtsjen yn de rige duorre oant in healoere, dat is in hiel lange tiid. Ynstrumintaasjetests waarden útfierd op elke PR, fertragingen fertrage de ûntwikkeling echt, en doe kaam de moanlikse rekken mei in rûne som. Yn 't algemien waard besletten om Firebase te ferlitten en yn eigen hûs te wurkjen, om't it team genôch groeid wie.

Docker + Python + bash

Wy namen Docker, stuffed emulators deryn, skreau in ienfâldich programma yn Python, dat op it krekte momint bringt it fereaske oantal emulators yn de fereaske ferzje en stopet se as it nedich is. En, fansels, in pear bash-skripts - wêr soene wy ​​sûnder har wêze?

It duorre fiif wiken om ús eigen testomjouwing te meitsjen.

As resultaat wie d'r foar elk pull-oanfraach in wiidweidige list mei kontrôles foar fúzje-blokkearjen:

• ARK gearstalling;
• junit tests;
• Lint;
• Android Studio kontrolearret;
• ynstrumintaasje tests;
• Skermprint tests.

Dit foarkaam in protte mooglike flaters. Technysk wurke alles, mar de ûntwikkelders klagen dat it wachtsjen op resultaten te lang wie.

Hoe lang is te lang? Wy uploaden gegevens fan Bitbucket en TeamCity yn it analysesysteem en realisearre dat gemiddelde wachttiid 45 minuten. Dat is, in ûntwikkelder, by it iepenjen fan in pull-fersyk, wachtet gemiddeld 45 minuten op de bouresultaten. Yn myn miening, dit is in protte, en do kinst net wurkje sa.

Fansels hawwe wy besletten om al ús builds te fersnellen.

Lit ús flugger meitsje

Om te sjen dat gebouwen faak yn in wachtrige steane, is it earste wat wy dogge kocht mear hardware - wiidweidige ûntwikkeling is it ienfâldichste. Bouwen hâlde op mei de wachtrige, mar de wachttiid fermindere mar in bytsje, omdat guon kontrôles sels hiel lang duorre.

It fuortheljen fan kontrôles dy't te lang duorje

Us trochgeande yntegraasje koe dizze soarten flaters en problemen fange.

• Net gean. CI kin in kompilaasjeflater fange as iets net bouwt fanwegen tsjinstridige feroarings. Sa't ik al sei, dan kin gjinien alles gearstalle, de ûntwikkeling stopt, en elkenien wurdt senuweftich.
• Bug yn gedrach. Bygelyks, as de applikaasje is boud, mar crashes as jo op in knop, of de knop wurdt net yndrukt hielendal. Dit is slim omdat sa'n brek de brûker berikke kin.
• Bug yn opmaak. Bygelyks, in knop wurdt oanklikt, mar is ferpleatst 10 piksels nei lofts.
• Ferheging fan technyske skulden.

Nei it besjen fan dizze list, realisearre wy dat allinich de earste twa punten kritysk binne. Sokke problemen wolle wy earst fange. Bugs yn 'e opmaak wurde ûntdutsen yn' e ûntwerp-beoardieling en kinne dan maklik korrizjearre wurde. Omgean mei technyske skuld fereasket in apart proses en planning, dus wy besletten net te testen it op in pull fersyk.

Op grûn fan dizze klassifikaasje skodden wy de folsleine list fan kontrôles. Lint trochstutsen en stelde de lansearring fan 'e nacht út: gewoan om in rapport te meitsjen oer hoefolle problemen d'r wiene yn it projekt. Wy ôfpraat om te wurkjen apart mei de technyske skuld, en Android Studio-kontrôles waarden folslein ferlitten. Android Studio yn Docker foar it útfieren fan ynspeksjes klinkt ynteressant, mar soarget foar in protte problemen by stipe. Elke update nei Android Studio-ferzjes betsjut in striid mei ûnbegryplike bugs. It wie ek lestich om screenshottests te stypjen, om't de bibleteek net heul stabyl wie en d'r falske positiven wiene. Skermprinttests binne fuortsmiten fan 'e kontrôlelist.

As gefolch hawwe wy oerbleaun mei:

• ARK gearstalling;
• junit tests;
• Ynstrumintaasje tests.

Gradle remote cache

Sûnder swiere kontrôles waard alles better. Mar d'r is gjin limyt foar folsleinens!

Us applikaasje wie al opdield yn sawat 150 gradle-modules. Gradle remote cache wurket normaal goed yn dit gefal, dus wy besletten it te besykjen.

Gradle remote cache is in tsjinst dy't artefakten yn cache kin bouwe foar yndividuele taken yn yndividuele modules. Gradle, ynstee fan feitlik de koade te kompilearjen, brûkt HTTP om op 'e ôfstân-cache te klopjen en te freegjen oft immen dizze taak al hat útfierd. As ja, downloadt it gewoan it resultaat.

Gradle-cache op ôfstân útfiere is maklik om't Gradle in Docker-ôfbylding leveret. Wy hawwe dit yn trije oeren slagge.

Alles wat jo hoege te dwaan wie Docker starte en ien rigel yn it projekt skriuwe. Mar hoewol it fluch kin wurde lansearre, sil it nochal in protte tiid duorje foar alles om goed te wurkjen.

Hjirûnder is de cache mist grafyk.

Oan it begjin wie it persintaazje cache-missings sa'n 65. Nei trije wiken slagge it ús om dizze wearde te ferheegjen nei 20%. It die bliken dat de taken dy't de Android-applikaasje sammelet, frjemde transitive ôfhinklikens hawwe, wêrtroch Gradle de cache miste.

Troch de cache te ferbinen, hawwe wy de bou sterk fersnelle. Mar neist gearkomste binne der ek ynstrumintaasje tests, en se nimme in lange tiid. Miskien moatte net alle testen útfierd wurde foar elke pull-oanfraach. Om út te finen, brûke wy ynfloedanalyse.

Impact analyze

Op in pull-fersyk sammelje wy git diff en fine de wizige Gradle-modules.

It makket sin om allinich ynstrumintaasjetests út te fieren dy't de feroare modules kontrolearje en alle modules dy't derfan ôfhinklik binne. D'r hat gjin punt om testen foar oanbuorjende modules út te fieren: de koade is dêr net feroare en neat kin brekke.

Instrumentaasjetests binne net sa ienfâldich, om't se moatte lizze yn 'e applikaasjemodule op it boppeste nivo. Wy brûkten heuristyk mei bytecode-analyse om te begripen hokker module elke test heart ta.

It opwurdearjen fan 'e wurking fan' e ynstrumintaasjetests sadat se allinich de belutsen modules testen duorre sawat acht wiken.

Maatregels om ynspeksjes te fersnellen hawwe suksesfol wurke. Fan 45 minuten gongen we omheech nei sa'n 15. It is al normaal om in kertier te wachtsjen op in bou.

Mar no binne ûntwikkelders begon te klagen dat se net begripe hokker builds wurde lansearre, wêr't it log te sjen is, wêrom't de build read is, hokker test mislearre, ensfh.

Problemen mei feedback fertrage ûntwikkeling, dus wy besochten sa dúdlik en detaillearre ynformaasje te jaan oer elke PR en bouwe mooglik. Wy begûnen mei opmerkingen yn Bitbucket oan 'e PR, oan te jaan hokker build mislearre wie en wêrom, en skreaune rjochte berjochten yn Slack. Oan 'e ein hawwe wy in PR-dashboard foar de side makke mei in list fan alle builds dy't op it stuit rinne en har status: wachtrige, rinnende, ferûngelokke of foltôge. Jo kinne op 'e bou klikke en nei it logboek komme.

Seis wiken waarden bestege oan detaillearre feedback.

Plannen

Litte wy nei de resinte skiednis gean. Nei it oplossen fan it feedbackprobleem, berikten wy in nij nivo - wy besletten om ús eigen emulatorfarm te bouwen. As d'r in protte tests en emulators binne, binne se lestich te behearjen. As gefolch, al ús emulators ferhuze nei de k8s kluster mei fleksibele boarne behear.

Dêrneist binne der oare plannen.

• Lint werom (en oare statyske analyze). Wy wurkje al yn dizze rjochting.
• Run alles op in PR blocker end-to-end tests op alle SDK ferzjes.

Dat, wy hawwe de skiednis fan 'e ûntwikkeling fan Continuous Integration yn Avito opspoard. No wol ik wat advys jaan út in betûfte eachpunt.

Tips

As ik mar ien advys koe jaan soe it dit wêze:

Wês asjebleaft foarsichtich mei shell-skripts!

Bash is in heul fleksibel en krêftich ark, it is heul handich en fluch om skripts te skriuwen. Mar jo kinne dermei yn in val falle, en spitigernôch foelen wy der yn.

It begon allegear mei ienfâldige skripts dy't rûnen op ús buildmasines:

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

Mar, lykas jo witte, ûntwikkelet alles en wurdt yn 'e rin fan' e tiid komplisearre - litte wy it iene skript fan it oare útfiere, litte wy dêr wat parameters trochjaan - op it lêst moasten wy in funksje skriuwe dy't bepaalt op hokker nivo fan bash nêst wy no yn oarder binne om de nedige sitaten yn te foegjen, om it allegear te begjinnen.

Jo kinne de arbeidskosten foarstelle foar de ûntwikkeling fan sokke skripts. Ik advisearje jo net yn dizze fal te fallen.

Wat kin wurde ferfongen?

• Elke skripttaal. Skriuw nei Python of Kotlin Script handiger omdat it programmearring is, gjin skripts.
• Of beskriuw alle boulogika yn 'e foarm Oanpaste gradle taken foar jo projekt.

Wy besletten om de twadde opsje te kiezen, en no wiskje wy systematysk alle bash-skripts en skriuwe in protte oanpaste gradle-taken.

Tip #2: Bewarje ynfrastruktuer yn koade.

It is handich as de ynstelling foar trochgeande yntegraasje net yn 'e UI-ynterface fan Jenkins of TeamCity, ensfh. Dit jout ferzjeability. It sil net dreech wêze om de koade werom te rôljen of te bouwen op in oare tûke.

Skripten kinne wurde opslein yn in projekt. Wat te dwaan mei it miljeu?

Tip #3: Docker kin helpe mei it miljeu.

It sil perfoarst Android-ûntwikkelders helpe; iOS hat spitigernôch noch gjin ien.

Dit is in foarbyld fan in ienfâldich docker-bestân dat jdk en android-sdk befettet:

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

Nei't jo dit Docker-bestân skreaun hawwe (ik sil jo in geheim fertelle, jo hoege it net te skriuwen, mar lûk it gewoan klear makke fan GitHub) en it byld gearstald, krije jo in firtuele masine wêrop jo de applikaasje kinne bouwe en rinne Junit tests.

De twa wichtichste redenen wêrom't dit sin makket, binne skalberens en werhelling. Mei help fan docker kinne jo fluch in tsiental bouwagenten ferheegje dy't krekt deselde omjouwing sille hawwe as de foarige. Dit makket it libben fan CI-yngenieurs in stik makliker. It is frij maklik om de android-sdk yn docker te triuwen, mar mei emulators is it in bytsje dreger: jo moatte wat hurder wurkje (of de fertige fan GitHub opnij downloade).

Tip nr 4: ferjit net dat ynspeksjes net dien wurde om de ynspeksjes, mar foar minsken.

Fluch en, wichtichste, dúdlike feedback is heul wichtich foar ûntwikkelders: wat bruts, hokker test mislearre, wêr kin ik it buildlog sjen.

Tip #5: Wês pragmatysk by it ûntwikkeljen fan trochgeande yntegraasje.

Begryp dúdlik hokker soarten flaters jo wolle foarkomme, hoefolle boarnen, tiid en kompjûtertiid jo ree binne te besteegjen. Kontroles dy't te lang duorje kinne bygelyks fan 'e nacht útsteld wurde. En dejingen dy't net heul wichtige flaters fange, moatte folslein ferlitten wurde.

Tip #6: Brûk klearmakke ark.

D'r binne no in protte bedriuwen dy't wolk CI leverje.

Dit is in goede oplossing foar lytse teams. Jo hoege neat te stypjen, gewoan in bytsje jild betelje, jo applikaasje bouwe en sels ynstrumintaasjetests útfiere.

Tip #7: Yn in grut team binne oplossingen yn eigen hûs rendabeler.

Mar ier of let, as it team groeit, sille eigen oplossingen rendabeler wurde. D'r is ien probleem mei dizze besluten. D'r is in wet fan ôfnimmend rendemint yn ekonomy: yn elk projekt is elke folgjende ferbettering hieltyd dreger en fereasket mear en mear ynvestearring.

Ekonomy beskriuwt ús hiele libben, ynklusyf trochgeande yntegraasje. Ik boude in skema fan arbeidskosten foar elke faze fan ûntwikkeling fan ús Continuous Integration.

It is dúdlik dat elke ferbettering hieltyd dreger wurdt. As jo ​​​​nei dizze grafyk sjogge, kinne jo begripe dat trochgeande yntegraasje moat wurde ûntwikkele yn oerienstimming mei de groei fan 'e teamgrutte. Foar in team fan twa minsken, besteegje 50 dagen oan it ûntwikkeljen fan in ynterne emulator pleats is in midsmjittich idee. Mar tagelyk, foar in grut team, is it hielendal net dwaan fan Continuous Integration ek in min idee, om't yntegraasjeproblemen, kommunikaasje reparearje, ensfh. it sil noch mear tiid nimme.

Wy begûnen mei it idee dat automatisearring nedich is om't minsken djoer binne, se meitsje flaters en lui binne. Mar minsken automatisearje ek. Dêrom jilde alle deselde problemen foar automatisearring.

• Automatisearring is djoer. Unthâld it wurkskema.
• As it giet om automatisearring, meitsje minsken flaters.
• Soms is it hiel loai om te automatisearjen, want alles wurket sa. Wêrom wat oars ferbetterje, wêrom al dizze trochgeande yntegraasje?

Mar ik haw statistiken: flaters wurde fongen yn 20% fan gearkomsten. En dit is net om't ús ûntwikkelders koade min skriuwe. Dit is om't ûntwikkelders der wis fan binne dat as se wat flater meitsje, it net sil einigje yn ûntwikkeling, it sil wurde fongen troch automatisearre kontrôles. Dêrtroch kinne ûntwikkelders mear tiid besteegje oan it skriuwen fan koade en nijsgjirrige dingen, ynstee fan lokaal wat te rinnen en te testen.

Oefenje trochgeande yntegraasje. Mar mei mate.

Troch de wei, Nikolai Nesterov net allinnich jout grutte rapporten sels, mar is ek lid fan it programma kommisje AppsConf en helpt oaren tariede betsjuttingsfolle taspraken foar dy. De folsleinens en brûkberens fan it folgjende konferinsjeprogramma kinne wurde beoardiele troch ûnderwerpen yn skema. En foar details, kom nei Infospace op 22-23 april.

Boarne: www.habr.com