Oghje, a maiò parte di i prudutti di software sò sviluppati in squadre. E cundizioni per u sviluppu di u squadra successu pò esse rapprisintatu in a forma di un schema simplice.

Una volta chì avete scrittu u vostru codice, avete bisognu di assicurà:

1. Работает.
2. Ùn rompe nunda, cumpresu u codice chì i vostri culleghi anu scrittu.

Sì i dui cundizioni sò scontri, allora site nantu à a strada di successu. Per verificà facilmente queste cundizioni è micca deviate da a strada prufittuosa, avemu ghjuntu cù Integrazione Continua.

CI hè un flussu di travagliu induve integrà u vostru codice in u codice generale di u produttu u più spessu pussibule. È ùn avete micca solu integrate, ma ancu verificate constantemente chì tuttu funziona. Siccomu avete bisognu di verificà assai è spessu, vale a pena pensà à l'automatizazione. Pudete cuntrollà tuttu manualmente, ma ùn deve micca, è eccu perchè.

• Caru populu. Una ora di travagliu di qualsiasi programatore hè più caru chì una ora di travagliu di qualsiasi servitore.
• E persone facenu sbagli. Dunque, e situazioni ponu accade quandu e teste sò state eseguite nantu à u ramu sbagliatu o l'impegnu sbagliatu hè statu compilatu per i testatori.
• A ghjente hè pigra. Di tantu in tantu, quandu finisci un compitu, nasce u pensamentu : « Chì ci hè da verificà ? Aghju scrittu duie linee - tuttu funziona! Pensu chì certi di voi ancu avè qualchì volta tali pinsamenti. Ma duvete sempre verificà.

Cumu l'Integrazione Continua hè stata implementata è sviluppata in a squadra di sviluppu mobile Avito, cumu si passanu da 0 à 450 custruzzioni per ghjornu, è chì e macchine di custruzzione assemblanu 200 ore à ghjornu, dice Nikolai Nesterov (nnesterov) hè un participante in tutti i cambiamenti evolutivi di l'applicazione Android CI/CD.

A storia hè basatu annantu à l'esempiu di un cumandamentu Android, ma a maiò parte di l'avvicinamenti sò applicabili ancu in iOS.

Una volta, una persona hà travagliatu in a squadra Avito Android. Per definizione, ùn hà micca bisognu di nunda di Integrazione Continua: ùn ci era nimu per integrà.

Ma l'applicazione hè cresciutu, più è più novi travaglii apparsu, è a squadra hè cresciutu in cunseguenza. À un certu puntu, hè ora di stabilisce più formalmente un prucessu di integrazione di codice. Hè statu decisu di utilizà Git flow.

U cuncettu di u flussu di Git hè ben cunnisciutu: un prughjettu hà un ramu di sviluppu cumunu, è per ogni nova funzione, i sviluppatori taglianu un ramu separatu, impegnà in questu, spinghje, è quandu volenu unisce u so codice in u ramu di sviluppu, apre un pull request. Per sparte a cunniscenza è discutiri l'approcciu, avemu introduttu a revisione di codice, vale à dì, i culleghi anu da verificà è cunfirmà u codice di l'altri.

Cuntrolli

Vede u codice cù i vostri ochji hè cool, ma micca abbastanza. Per quessa, i cuntrolli automatichi sò stati introdotti.

• Prima di tuttu, avemu verificatu Assemblea ARK.
• Assai Test di Junit.
• Cunsideremu a cobertura di codice, postu chì avemu eseguitu teste.

Per capisce cumu si deve esse realizatu sti cuntrolli, fighjemu u prucessu di sviluppu in Avito.

Pò esse rapprisintatu schematicamente cusì:

• Un sviluppatore scrive codice nantu à u so laptop. Pudete eseguisce cuntrolli di integrazione quì - sia cù un ganciu di cummissione, o semplicemente eseguite cuntrolli in fondo.
• Dopu chì u sviluppatore hà imbuttatu u codice, apre una dumanda di pull. Per esse u so codice per esse inclusu in u ramu di sviluppu, hè necessariu di passà per una revisione di codice è recullà u numeru necessariu di cunferma. Pudete attivà i cuntrolli è e custruzzioni quì: finu à chì tutte e custruzzioni sò successu, a dumanda di pull ùn pò micca esse unificate.
• Dopu chì a dumanda di pull hè fusionata è u codice hè inclusu in u sviluppu, pudete sceglie un tempu convenientu: per esempiu, a notte, quandu tutti i servitori sò liberi, è eseguite quant'è cuntrolli chì vulete.

Nimu hà piaciutu di scansà u so laptop. Quandu un sviluppatore hà finitu una funzione, vole à spinghja rapidamente è apre una dumanda di pull. Se in questu mumentu alcuni cuntrolli longu sò lanciati, questu ùn hè micca solu assai piacevule, ma ancu rallenta u sviluppu: mentre chì u laptop verifica qualcosa, hè impussibile di travaglià nurmale.

Ci hè piaciutu assai di eseguisce i cuntrolli di notte, perchè ci hè assai tempu è servitori, pudete vagare. Ma, sfurtunatamenti, quandu u codice di funziunalità si sviluppa, u sviluppatore hà assai menu motivazione per riparà l'errore chì CI hà trovu. Mi pigliò periodicamente à pensà quandu aghju guardatu tutti l'errori truvati in u rapportu di a matina chì l'aghju riparatu un ghjornu dopu, perchè avà ci hè un novu travagliu frescu in Jira chì vogliu solu cumincià à fà.

Se i cuntrolli bluccanu una dumanda di pull, allora ci hè abbastanza motivazione, perchè finu à chì e custruzzioni diventanu verdi, u codice ùn entrerà micca in u sviluppu, chì significa chì u compitu ùn serà micca cumpletu.

In u risultatu, avemu sceltu a seguente strategia: eseguimu u massimu di cuntrolli pussibuli di notte, è lanciamu i più critichi di elli è, più impurtante, i più veloci nantu à una dumanda di pull. Ma ùn fermamu micca quì - in parallelu, ottimisimu a velocità di i cuntrolli in modu di trasfiriri da u modu di notte per tirà cuntrolli di dumanda.

À quellu tempu, tutte e nostre custruzzioni sò state cumplette abbastanza rapidamente, cusì avemu simplicemente inclusu l'ARK build, i testi Junit è i calculi di copertura di codice cum'è un blocker per a dumanda di pull. L'avemu attivatu, pensatu à questu, è abbandunatu a cobertura di codice perchè avemu pensatu chì ùn avemu micca bisognu.

Ci hà pigliatu dui ghjorni per stallà cumplettamente u CI di basa (in seguitu l'estimazione di u tempu hè apprussimativa, necessaria per a scala).

Dopu quì, avemu cuminciatu à pensà più - avemu ancu cuntrollà bè? Eseguimu e custruzzioni nantu à e richieste di pull correttamente?

Avemu principiatu a custruzzione nantu à l'ultimu impegnu di u ramu da quale a dumanda di pull hè stata aperta. Ma i testi di questu impegnu ponu solu dimustrà chì u codice chì u sviluppatore hà scrittu travaglia. Ma ùn prova micca ch'ellu ùn hà micca rumpitu nunda. In fatti, avete bisognu di verificà u statu di u ramu di sviluppu dopu chì una funzione hè fusionata in questu.

Per fà questu, avemu scrittu un script bash simplice premerge.sh:

#!/usr/bin/env bash

set -e

git fetch origin develop

git merge origin/develop

Quì tutti l'ultimi cambiamenti da u sviluppu sò simpliciamente tirati è fusionati in u ramu attuale. Avemu aghjustatu u script premerge.sh cum'è u primu passu in tutte e custruzzioni è hà cuminciatu à verificà esattamente ciò chì vulemu, vale à dì. integrazione.

Pigliò trè ghjorni per localizà u prublema, truvà una suluzione, è scrive stu script.

L'applicazione sviluppata, più è più travaglii apparsu, a squadra hè cresciuta, è premerge.sh à volte cuminciò à lascià. Sviluppu hà avutu cambiamenti cunflitti chì anu rottu a custruzione.

Un esempiu di cumu succede questu:

Dui sviluppatori simultaneamente cumincianu à travaglià nantu à e funzioni A è B. U sviluppatore di a funzione A scopre una funzione inutilizata in u prugettu answer() è, cum'è un bonu boy scout, sguassate. À u listessu tempu, u sviluppatore di a funzione B aghjunghje una nova chjama à sta funzione in u so ramu.

I sviluppatori finiscinu u so travagliu è apre una dumanda di pull à u stessu tempu. E custruzzioni sò lanciate, premerge.sh verifica e duie richieste di pull in quantu à l'ultimu statu di sviluppu - tutti i cuntrolli sò verdi. Dopu quì, a dumanda di pull di a funzione A hè fusionata, a dumanda di pull di a funzione B hè fusionata... Boom! Sviluppà pause perchè u codice di sviluppu cuntene una chjama à una funzione inesistente.

Quandu ùn hà micca da sviluppà, hè disastru lucale. L'intera squadra ùn pò micca recullà nunda è sottumette per a prova.

Hè accadutu chì u più spessu travagliatu nantu à i travaglii di l'infrastruttura: analitiche, rete, basa di dati. Vale à dì, era eiu chì hà scrittu quelle funzioni è classi chì l'altri sviluppatori utilizanu. Per via di questu, aghju trovu in situazioni simili assai spessu. Aghju ancu avutu sta stampa appesa per un tempu.

Siccomu questu ùn ci cunvene micca, avemu cuminciatu à scopre l'opzioni nantu à cumu per prevene questu.

Cumu ùn rompe micca u sviluppu

A prima opzione: ricustruisce tutte e richieste di pull quandu l'aghjurnamentu sviluppa. Se, in u nostru esempiu, a dumanda di pull cù a funzione A hè a prima inclusa in u sviluppu, a dumanda di pull di a funzione B serà ricustruita, è, per quessa, i cuntrolli fallenu per un errore di compilazione.

Per capisce quantu durarà questu, cunzidira un esempiu cù dui PR. Apermu dui PR: duie custruzzioni, duie corse di cuntrolli. Dopu chì u primu PR hè unitu in u sviluppu, u sicondu deve esse ricustruitu. In totale, dui PR necessanu trè corse di cuntrolli: 2 + 1 = 3.

In principiu, hè bè. Ma avemu vistu l'statìstiche, è a situazione tipica in a nostra squadra era 10 PR aperti, è dopu u numeru di cuntrolli hè a summa di a prugressu: 10 + 9 +... + 1 = 55. Hè, per accettà 10. PRs, avete bisognu di ricustruisce 55 volte. È questu hè in una situazione ideale, quandu tutti i cuntrolli passanu a prima volta, quandu nimu ùn apre una dumanda di pull supplementu mentre sti decine sò processati.

Immaginatevi cum'è un sviluppatore chì deve esse u primu à cliccà nantu à u buttone "fusione", perchè se un vicinu face questu, allora vi tuccherà à aspittà finu à chì tutte e custruzzioni passanu di novu ... No, ùn funziona micca. , rallentarà seriamente u sviluppu.

Seconda manera pussibule: raccoglie e richieste di pull dopu a revisione di codice. Vale à dì, apre una dumanda di pull, raccoglie u numeru necessariu di appruvazioni da i culleghi, corregge ciò chì hè necessariu, è poi lanciate e custruzzioni. Se sò riesciuti, a dumanda di pull hè fusionata in u sviluppu. In questu casu, ùn ci sò micca riavvii supplementari, ma u feedback hè assai rallentatu. Cum'è sviluppatore, quandu aghju apertu una dumanda di pull, vogliu immediatamente vede s'ellu hà da travaglià. Per esempiu, se una prova falla, avete bisognu di riparà rapidamente. In u casu di una custruzione ritardata, u feedback rallenta, è dunque tuttu u sviluppu. Questu ùn ci cunvene ancu.

In u risultatu, solu a terza opzione restava - ciclismu. Tuttu u nostru codice, tutte e nostre fonti sò guardati in un repository in u servitore Bitbucket. Per quessa, avemu avutu à sviluppà un plugin per Bitbucket.

Stu plugin annulla u mecanismu di fusione di richieste di pull. U principiu hè standard: u PR apre, tutte l'assemblee sò lanciate, a revisione di u codice hè finita. Ma dopu chì a revisione di u codice hè finita è u sviluppatore decide di cliccà nantu à "fusione", i cuntrolli di plugin contr'à quale u statu di sviluppu sò stati eseguiti. Se u sviluppu hè statu aghjurnatu dopu à e custruzzioni, u plugin ùn permetterà micca una tale dumanda di pull per esse unificate in u ramu principale. Simpliciamente riavviarà e custruzzioni di un sviluppu relativamente recente.

In u nostru esempiu cù cambiamenti cunflitti, tali custruzzioni fallaranu per un errore di compilazione. In cunsiquenza, u sviluppatore di a funzione B duverà correggerà u codice, riavvia i cuntrolli, allora u plugin applicà automaticamente a dumanda di pull.

Prima di implementà stu plugin, avemu fattu una media di 2,7 runs di rivisione per pull request. Cù u plugin ci era 3,6 lanciari. Questu hè adattatu per noi.

Hè da nutà chì stu plugin hà un inconveniente: riavvia a custruzione solu una volta. Vale à dì, ci hè sempre una piccula finestra attraversu quale i cambiamenti cunflitti ponu esse sviluppati. Ma a probabilità di questu hè bassu, è avemu fattu questu scambiu trà u numeru di principii è a probabilità di fallimentu. In dui anni, hà sparatu solu una volta, per quessa ùn era micca in vain.

Ci hà pigliatu duie simane per scrive a prima versione di u plugin Bitbucket.

Cuntrolli novi

Intantu, a nostra squadra hà cuntinuatu à cresce. Sò stati aghjunti novi cuntrolli.

Avemu pensatu: perchè fà sbagli si ponu esse impediti? È hè per quessa chì anu implementatu analisi di codice staticu. Avemu cuminciatu cù lint, chì hè inclusu in u SDK Android. Ma à quellu tempu ùn sapia micca cumu travaglià cù u codice Kotlin in tuttu, è avemu digià avutu 75% di l'applicazione scritta in Kotlin. Per quessa, i integrati sò stati aghjuntu à u lint Android Studio verifica.

Per fà questu, avemu avutu pervertà assai: pigliate Android Studio, imballate in Docker è eseguite nantu à CI cun un monitor virtuale, perchè pensa chì hè in esecuzione nantu à un veru laptop. Ma hà travagliatu.

Era ancu in questu tempu chì avemu principiatu à scrive assai prove di strumentazione è implementatu prova di screenshot. Questu hè quandu una screenshot di riferimentu hè generata per una vista chjuca separata, è a prova cunsiste di piglià una screenshot da a vista è paragunà cù u standard direttamente pixel per pixel. Se ci hè una discrepanza, significa chì u layout hè sbagliatu in un locu o qualcosa hè sbagliatu in i stili.

Ma i testi di strumentazione è e teste di screenshot anu da esse realizatu nantu à i dispositi: in emulatori o in i dispositi reali. Cunsiderendu chì ci sò assai teste è sò eseguiti spessu, hè necessariu una splutazioni sana. L'iniziu di a vostra propria splutazioni hè troppu intensivu di travagliu, cusì avemu trovu una opzione pronta - Firebase Test Lab.

laboratoriu di prova firebase

Hè statu sceltu perchè Firebase hè un pruduttu di Google, vale à dì chì deve esse affidabile è improbabile di mori mai. I prezzi sò ragiunate: $ 5 per ora di funziunamentu di un veru dispusitivu, 1 $ per ora di funziunamentu di un emulatore.

Ci hà pigliatu circa trè settimane per implementà Firebase Test Lab in u nostru CI.

Ma a squadra hà cuntinuatu à cresce, è Firebase, sfurtunatamenti, hà cuminciatu à lascià. À quellu tempu, ùn avia micca SLA. Calchì volta Firebase ci hà fattu aspittà finu à chì u numeru necessariu di dispusitivi era liberu per e teste, è ùn hà micca cuminciatu à eseguisce immediatamente, cum'è vulemu. L'aspittà in fila hà pigliatu finu à una meza ora, chì hè un tempu assai longu. I testi di strumentazione sò stati eseguiti annantu à ogni PR, i ritardi rallentavanu veramente u sviluppu, è dopu a fattura mensuale hè stata cun una somma tonda. In generale, hè statu decisu di abbandunà Firebase è di travaglià in casa, postu chì a squadra era abbastanza cresciutu.

Docker + Python + bash

Avemu pigliatu Docker, emulatori imbottiti in questu, hà scrittu un prugramma simplice in Python, chì à u mumentu propiu porta u numeru necessariu di emulatori in a versione necessaria è li ferma quandu hè necessariu. E, sicuru, un paru di scripts bash - induve seremu senza elli?

Ci hà pigliatu cinque settimane per creà u nostru propiu ambiente di prova.

In u risultatu, per ogni dumanda di pull ci era una larga lista di cuntrolli di bloccu di fusione:

• assemblea ARK;
• testi Junit;
• Lint;
• cuntrolli Android Studio;
• teste di strumentazione;
• Test di screenshot.

Questu hà impeditu parechje guasi pussibuli. Tecnicamente tuttu hà travagliatu, ma i sviluppatori si lagnavanu chì l'aspittà di i risultati era troppu longa.

Quantu hè troppu longu? Avemu caricatu dati da Bitbucket è TeamCity in u sistema di analisi è capitu chì tempu d'attesa mediu 45 minuti. Vale à dì, un sviluppatore, quandu apre una dumanda di pull, aspetta in media 45 minuti per i risultati di custruzzione. In my opinion, questu hè assai, è ùn pudete micca travaglià cusì.

Di sicuru, avemu decisu di accelerà tutte e nostre custruzzioni.

Acceleremu

Videndu chì e custruzzioni sò spessu in una fila, a prima cosa chì facemu hè compru più hardware - u sviluppu estensivu hè u più simplice. I Builds anu cessatu di fila, ma u tempu d'attesa hè diminuitu solu ligeramente, perchè certi cuntrolli stessi anu pigliatu assai tempu.

Eliminà i cuntrolli chì piglianu troppu longu

A nostra Integrazione Continua puderia catturà questi tipi d'errori è prublemi.

• Ùn andemu micca. CI pò catturà un errore di compilazione quandu qualcosa ùn hè micca custruitu per via di cambiamenti cunflitti. Cum'è l'aghju digià dettu, allora nimu pò assemblà nunda, u sviluppu si ferma, è tutti diventanu nervosi.
• Bug in u cumpurtamentu. Per esempiu, quandu l 'applicazzioni hè custruitu, ma crashes quandu vi appughjà un buttone, o u buttone ùn hè pressatu à tutti. Questu hè male perchè un tali bug pò ghjunghje à l'utilizatore.
• Bug in layout. Per esempiu, un buttone hè clicatu, ma hà spustatu 10 pixel à a manca.
• Aumentu di u debitu tecnicu.

Dopu avè vistu sta lista, avemu capitu chì solu i primi dui punti sò critichi. Vulemu catturà tali prublemi prima. Bugs in u layout sò scuperti in u stadiu di u disignu-revisione è ponu esse facilmente corretti allora. Trattamentu di u debitu tecnicu richiede un prucessu è una pianificazione separata, cusì avemu decisu di ùn pruvà micca nantu à una dumanda di pull.

Basatu nantu à sta classificazione, avemu scuzzulatu tutta a lista di cuntrolli. Lint barratu è rinviatu u so lanciamentu per a notte: solu per fà un rapportu nantu à quanti prublemi ci era in u prugettu. Avemu accunsentutu à travaglià separatamente cù u debitu tecnicu, è I cuntrolli di Android Studio sò stati completamente abbandunati. Android Studio in Docker per eseguisce l'ispezioni pare interessante, ma causa assai prublemi in supportu. Ogni aghjurnamentu di e versioni di Android Studio significa una lotta cù bug incomprensibili. Era ancu difficiule di sustene e teste di screenshot, perchè a biblioteca ùn era micca assai stabile è ci sò falsi pusitivi. I testi di screenshot sò stati eliminati da a lista di cuntrollu.

In u risultatu, ci sò stati lasciati cù:

• assemblea ARK;
• testi Junit;
• Test di strumentazione.

Gradle cache remota

Senza cuntrolli pesanti, tuttu hè diventatu megliu. Ma ùn ci hè micca limite à a perfezione!

A nostra applicazione era digià divisa in circa 150 moduli gradle. A cache remota Gradle di solitu funziona bè in questu casu, cusì avemu decisu di pruvà.

A cache remota Gradle hè un serviziu chì pò cache custruisce artefatti per compiti individuali in moduli individuali. Gradle, invece di cumpilà veramente u codice, usa HTTP per chjappà in a cache remota è dumandate s'ellu qualchissia hà digià realizatu stu compitu. Se sì, si scarica solu u risultatu.

Eseguisce a cache remota di Gradle hè faciule perchè Gradle furnisce una maghjina Docker. Avemu riesciutu à fà questu in trè ore.

Tuttu ciò chì duvete fà era lancià Docker è scrive una linea in u prugettu. Ma ancu s'ellu pò esse lanciatu rapidamente, ci hà da piglià assai tempu per tuttu per travaglià bè.

Sottu hè u graficu di cache miss.

À u principiu, u percentuale di cache miss era di circa 65. Dopu à trè simani, avemu sappiutu aumentà stu valore à 20%. Risultava chì i travaglii chì l'applicazioni Android recullanu anu stranu dependenzi transitivi, per via di quale Gradle hà mancatu u cache.

Cunnettendu u cache, avemu acceleratu assai a custruzione. Ma in più di l'assemblea, ci sò ancu teste di strumentazione, è piglianu assai tempu. Forse micca tutte e teste deve esse eseguite per ogni dumanda di pull. Per sapè, usemu l'analisi di l'impattu.

Analisi di l'impattu

In una dumanda di pull, cullemu git diff è truvamu i moduli Gradle mudificati.

Hè sensu di eseguisce solu teste di strumentazione chì verificanu i moduli cambiati è tutti i moduli chì dependenu di elli. Ùn ci hè nunda di fà e teste per i moduli vicini: u codice ùn hè micca cambiatu è nunda pò rompe.

Cù teste di strumentazione, micca tuttu hè cusì simplice, perchè deve esse situatu in u modulu di l'Applicazione di u livellu superiore. Avemu usatu heuristiche cù l'analisi di bytecode per capiscenu à quale modulu appartene ogni prova.

L'aghjurnamentu di u funziunamentu di e teste di l'instrumentazione per ch'elli sò solu à pruvà i moduli implicati hà pigliatu circa ottu settimane.

E misure per accelerà l'ispezioni anu travagliatu cù successu. Da 45 minuti avemu cullatu à circa 15. Hè digià normale aspittà un quartu d'ora per una custruzzione.

Ma avà i sviluppatori anu cuminciatu à lagnà chì ùn capiscenu micca chì e custruzzioni sò lanciate, induve vede u logu, perchè a custruzione hè rossa, quale prova hà fallutu, etc.

I prublemi cù u feedback rallentanu u sviluppu, cusì avemu pruvatu à furnisce infurmazioni cum'è chjaru è detallatu nantu à ogni PR è custruisce quantu pussibule. Avemu cuminciatu cù cumenti in Bitbucket à u PR, indicà quale custruzzione hà fiascatu è perchè, è hà scrittu messagi mirati in Slack. À a fine, avemu creatu un dashboard PR per a pagina cù una lista di tutte e custruzzioni chì sò attualmente in esecuzione è u so statutu: in fila, in esecuzione, crashed o finita. Pudete cliccà nantu à a custruzione è ghjunghje à u so log.

Sei settimane sò state spese in feedback detallati.

Piani

Passemu à a storia recente. Dopu avè risoltu u prublema di feedback, avemu righjuntu un novu livellu - avemu decisu di custruisce a nostra propria splutazioni emulatori. Quandu ci sò parechje teste è emulatori, sò difficiuli di gestisce. In u risultatu, tutti i nostri emulatori si sò spustati in u cluster k8s cù una gestione di risorse flexible.

Inoltre, ci sò altri piani.

• Ritorna Lint (è altre analisi statica). Avemu digià travagliatu in questa direzzione.
• Eseguite tuttu nantu à un blocker PR teste end-to-end su tutte le versioni di SDK.

Cusì, avemu tracciatu a storia di u sviluppu di l'Integrazione Continua in Avito. Avà vogliu dà qualchì cunsigliu da un puntu di vista espertu.

Советы

Se pudessi dà solu un cunsigliu, seria questu:

Per piacè fate attenzione cù i script di shell!

Bash hè un strumentu assai flexible è putente, hè assai còmuda è veloce per scrive script. Ma pudete cascà in una trappula cun ellu, è, sfurtunatamenti, avemu cascatu in questu.

Tuttu hà cuminciatu cù script simplici chì currianu nantu à e nostre macchine di custruzzione:

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

Ma, cum'è sapete, tuttu si sviluppa è diventa più cumplicatu cù u tempu - eseguimu un script da un altru, passemu alcuni parametri quì - à a fine avemu avutu à scrive una funzione chì determina à quale livellu di bash nesting simu avà in ordine. per inserisce e virgulette necessarie, per avè tuttu principiatu.

Pudete imagine i costi di u travagliu per u sviluppu di tali scripts. Vi cunsigliu micca di cascà in sta trappula.

Chì pò esse rimpiazzatu?

• Qualchese lingua di scrittura. Scrivite à Python o Kotlin Script più cunvene perchè hè prugrammazione, micca script.
• O descrive tutta a logica di custruzzione in a forma I travaglii di gradle persunalizati per u vostru prughjettu.

Avemu decisu di sceglie a seconda opzione, è avà sguassate sistematicamente tutti i scripts bash è scrivemu assai compiti di gradle persunalizati.

Tip # 2: Store l'infrastruttura in codice.

Hè cunvenutu quandu u paràmetru di Integrazione Continua hè guardatu micca in l'interfaccia UI di Jenkins o TeamCity, etc., ma in forma di schedarii di testu direttamente in u repositoriu di u prugettu. Questu dà a versione. Ùn serà micca difficiule di rollback o di custruisce u codice in un altru ramu.

I scripts ponu esse guardati in un prughjettu. Chì fà cù l'ambiente ?

Tip #3: Docker pò aiutà cù l'ambiente.

Di sicuru, aiuterà i sviluppatori di Android iOS ùn hà micca ancu, sfurtunatamenti.

Questu hè un esempiu di un schedariu docker simplice chì cuntene jdk è 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

Dopu avè scrittu stu schedariu Docker (vi dicu un sicretu, ùn avete micca da scrive, ma basta tirallu prontu da GitHub) è assemblatu l'imaghjini, uttene una macchina virtuale nantu à quale pudete custruisce l'applicazione. è eseguite i testi Junit.

I dui mutivi principali per quessa hè sensu sò scalabilità è ripetibilità. Utilizendu docker, pudete suscitarà rapidamente una decina di agenti di custruzzione chì avarà esattamente u listessu ambiente cum'è u precedente. Questu rende a vita di l'ingegneri CI assai più faciule. Hè abbastanza faciule per spinghje l'android-sdk in docker, ma cù emulatori hè un pocu più difficiule: duverete travaglià un pocu più (o scaricate u finitu da GitHub di novu).

Cunsigliu n ° 4: ùn vi scurdate chì l'ispezioni ùn sò micca fatti per l'ispezioni, ma per e persone.

Rapidu è, più impurtante, un feedback chjaru hè assai impurtante per i sviluppatori: ciò chì hà rottu, quale prova hà fallutu, induve possu vede u buildlog.

Tip # 5: Siate pragmaticu quandu u sviluppu di l'Integrazione Continua.

Capisce chjaramente chì tipi d'errori vulete prevene, quantu risorse, tempu è tempu di l'urdinatore chì site dispostu à passà. I cuntrolli chì piglianu troppu longu ponu, per esempiu, esse posposti di notte. È quelli di elli chì catturanu errori micca assai impurtanti deve esse completamente abbandunati.

Tip #6: Aduprate strumenti pronti.

Ci sò parechje cumpagnie avà chì furniscenu cloud CI.

Questa hè una bona suluzione per i picculi squadre. Ùn avete bisognu di sustene nunda, basta pagà un pocu di soldi, custruisce a vostra applicazione è ancu eseguite teste di strumentazione.

Tip # 7: In una grande squadra, e soluzioni in-house sò più prufittuali.

Ma prima o dopu, cum'è a squadra cresce, e soluzioni in-house diventeranu più prufittuali. Ci hè un prublema cù queste decisioni. Ci hè una lege di diminuzione di i ritorni in l'ecunumia: in ogni prughjettu, ogni migliuramentu sussegwente hè di più è più difficiule è esige più è più investimentu.

L'ecunumia descrive a nostra vita sana, cumpresa a Integrazione Continua. Aghju custruitu un calendariu di i costi di u travagliu per ogni tappa di sviluppu di a nostra Integrazione Continua.

Hè chjaru chì ogni migliuramentu hè diventatu sempre più difficiule. Fighjendu stu graficu, pudete capisce chì a Integrazione Continua deve esse sviluppata in cunfurmità cù a crescita di a dimensione di a squadra. Per una squadra di duie persone, passà 50 ghjorni à sviluppà una splutazioni di emulatore internu hè una idea mediocre. Ma à u stessu tempu, per una grande squadra, ùn fà micca Integrazione Continua in tuttu hè ancu una mala idea, perchè i prublemi di integrazione, risolve a cumunicazione, etc. ci sarà ancu più tempu.

Avemu cuminciatu cù l'idea chì l'automatizazione hè necessaria perchè e persone sò caru, sbaglianu è sò pigri. Ma a ghjente ancu automatizà. Dunque, tutti i stessi prublemi s'applicanu à l'automatizazione.

• L'automatizazione hè caru. Ricurdativi di u calendariu di u travagliu.
• Quandu si tratta di l'automatizazione, e persone facenu sbagli.
• Calchì volta hè assai pigra per automatizà, perchè tuttu funziona cusì. Perchè migliurà qualcosa altru, perchè tuttu questu Integrazione Continua?

Ma aghju statistiche: l'errori sò catturati in 20% di l'assemblee. È questu ùn hè micca perchè i nostri sviluppatori scrivenu u codice male. Questu hè chì i sviluppatori sò cunfidenti chì, s'ellu si sbaglianu, ùn finisce micca in u sviluppu, serà pigliatu da cuntrolli automatizati. In cunsiquenza, i sviluppatori ponu passà più tempu à scrive codice è cose interessanti, piuttostu chè di correre è di pruvà qualcosa in u locu.

Praticà Integrazione Continua. Ma in moderazione.

In modu, Nikolai Nesterov ùn solu dà grandi rapporti stessu, ma hè ancu un membru di u cumitatu di u prugramma. AppsConf è aiuta à l'altri à preparà discorsi significati per voi. A completezza è l'utilità di u prossimu prugramma di cunferenza pò esse valutata per temi in pianificazione. È per i dettagli, venite à Infospace u 22-23 d'aprile.

Source: www.habr.com