Vandag word die meeste sagtewareprodukte in spanne ontwikkel. Die voorwaardes vir suksesvolle spanontwikkeling kan in die vorm van 'n eenvoudige diagram voorgestel word.

Sodra jy jou kode geskryf het, moet jy seker maak dit:

1. Werk.
2. Dit breek niks nie, insluitend die kode wat jou kollegas geskryf het.

As beide voorwaardes nagekom word, dan is jy op pad na sukses. Om hierdie toestande maklik na te gaan en nie van die winsgewende pad af te wyk nie, het ons met Continuous Integration vorendag gekom.

CI is 'n werkvloei waar jy jou kode so dikwels as moontlik in die algehele produkkode integreer. En jy integreer nie net nie, maar kyk ook voortdurend dat alles werk. Aangesien u baie en gereeld moet kyk, is dit die moeite werd om aan outomatisering te dink. Jy kan alles handmatig nagaan, maar jy moet nie, en hier is hoekom.

• Liewe mense. 'n Uur se werk van enige programmeerder is duurder as 'n uur se werk van enige bediener.
• Mense maak foute. Daarom kan situasies ontstaan ​​wanneer toetse op die verkeerde tak uitgevoer is of die verkeerde commit vir toetsers saamgestel is.
• Mense is lui. Van tyd tot tyd, wanneer ek klaar is met ’n taak, kom die gedagte op: “Wat is daar om na te gaan? Ek het twee reëls geskryf – alles werk! Ek dink sommige van julle het ook soms sulke gedagtes. Maar jy moet altyd kyk.

Hoe Continuous Integration geïmplementeer en ontwikkel is in die Avito-mobiele ontwikkelingspan, hoe hulle van 0 tot 450 bouwerk per dag gegaan het, en dat boumasjiene 200 uur per dag aanmekaargesit word, sê Nikolai Nesterov (nesterov) is 'n deelnemer aan alle evolusionêre veranderinge van die CI/CD Android-toepassing.

Die storie is gebaseer op die voorbeeld van 'n Android-opdrag, maar die meeste van die benaderings is ook van toepassing op iOS.

Eens op 'n tyd het een persoon in die Avito Android-span gewerk. Per definisie het hy niks van Continuous Integration nodig gehad nie: daar was niemand om mee te integreer nie.

Maar die toepassing het gegroei, meer en meer nuwe take het verskyn, en die span het dienooreenkomstig gegroei. Op 'n stadium is dit tyd om 'n kode-integrasieproses meer formeel te vestig. Daar is besluit om Git flow te gebruik.

Die konsep van Git-vloei is welbekend: 'n projek het een gemeenskaplike ontwikkeltak, en vir elke nuwe kenmerk sny ontwikkelaars 'n aparte tak, verbind hulle daartoe, druk, en wanneer hulle hul kode in die ontwikkeltak wil saamvoeg, maak 'n trek versoek. Om kennis te deel en benaderings te bespreek, het ons kodehersiening ingestel, dit wil sê kollegas moet mekaar se kode nagaan en bevestig.

Tjeks

Om kode met jou oë te sien is gaaf, maar nie genoeg nie. Daarom word outomatiese tjeks ingestel.

• Eerstens kyk ons ARK samestelling.
• Baie Junit toetse.
• Ons oorweeg kode dekking, aangesien ons toetse uitvoer.

Om te verstaan ​​hoe hierdie kontroles uitgevoer moet word, kom ons kyk na die ontwikkelingsproses in Avito.

Dit kan skematies soos volg voorgestel word:

• 'n Ontwikkelaar skryf kode op sy skootrekenaar. U kan integrasiekontroles net hier uitvoer - óf met 'n commit-haak, óf bloot op die agtergrond.
• Nadat die ontwikkelaar die kode gedruk het, maak hy 'n trekversoek oop. Om die kode by die ontwikkeltak in te sluit, is dit nodig om deur 'n kodehersiening te gaan en die vereiste aantal bevestigings in te samel. Jy kan kontroles en bouwerk hier aktiveer: totdat alle bouwerk suksesvol is, kan die trekversoek nie saamgevoeg word nie.
• Nadat die trekversoek saamgevoeg is en die kode by ontwikkel ingesluit is, kan u 'n gerieflike tyd kies: byvoorbeeld snags, wanneer al die bedieners gratis is, en voer soveel tjeks uit as wat u wil.

Niemand het daarvan gehou om skanderings op hul skootrekenaar te laat loop nie. Wanneer 'n ontwikkelaar 'n kenmerk voltooi het, wil hy dit vinnig druk en 'n trekversoek oopmaak. As op hierdie oomblik 'n paar lang kontroles van stapel gestuur word, is dit nie net nie baie aangenaam nie, maar vertraag dit ook die ontwikkeling: terwyl die skootrekenaar iets nagaan, is dit onmoontlik om normaal daaraan te werk.

Ons het baie daarvan gehou om snags tjeks te doen, want daar is baie tyd en bedieners kan jy rondloop. Maar, ongelukkig, wanneer die kenmerkkode ontwikkel word, het die ontwikkelaar baie minder motivering om die foute wat CI gevind het, reg te stel. Ek het myself kort-kort gevang dat ek dink as ek na al die foute wat in die oggendberig gevind is kyk dat ek dit eendag later sal regmaak, want nou is daar 'n oulike nuwe taak in Jira wat ek net wil begin doen.

As tjeks 'n trekversoek blokkeer, is daar genoeg motivering, want totdat die bouwerk groen word, sal die kode nie ontwikkel nie, wat beteken dat die taak nie voltooi sal word nie.

Gevolglik het ons die volgende strategie gekies: ons voer die maksimum moontlike stel tjeks snags uit, en begin die mees kritieke daarvan en, bowenal, die vinnigstes op 'n trekversoek. Maar ons stop nie daar nie - parallel optimaliseer ons die spoed van tjeks om dit van nagmodus oor te plaas om versoektjeks te trek.

Op daardie tydstip was al ons bouwerk redelik vinnig voltooi, so ons het eenvoudig die ARK-bou, Junit-toetse en kodedekkingberekeninge ingesluit as 'n blokkering vir die trekversoek. Ons het dit aangeskakel, daaroor gedink en kodedekking laat vaar omdat ons gedink het ons het dit nie nodig nie.

Dit het ons twee dae geneem om die basiese CI volledig op te stel (hierna is die tydskatting benaderd, benodig vir skaal).

Daarna het ons verder begin dink – gaan ons selfs reg na? Laat ons die bouversoeke korrek uitvoer?

Ons het die bouwerk begin op die laaste commit van die tak waaruit die trekversoek oopgemaak is. Maar toetse van hierdie commit kan net wys dat die kode wat die ontwikkelaar geskryf het, werk. Maar hulle bewys nie dat hy niks gebreek het nie. Trouens, u moet die toestand van die ontwikkeltak nagaan nadat 'n kenmerk daarin saamgevoeg is.

Om dit te doen, het ons 'n eenvoudige bash-skrif geskryf premerge.sh:

#!/usr/bin/env bash

set -e

git fetch origin develop

git merge origin/develop

Hier word al die nuutste veranderinge van ontwikkel eenvoudig opgetrek en saamgevoeg in die huidige tak. Ons het die premerge.sh-skrip as die eerste stap in alle bouwerk bygevoeg en begin kyk presies wat ons wil hê, dit is integrasie.

Dit het drie dae geneem om die probleem te lokaliseer, 'n oplossing te vind en hierdie skrif te skryf.

Die toepassing het ontwikkel, meer en meer take het verskyn, die span het gegroei, en premerge.sh het ons soms in die steek gelaat. Develop het teenstrydige veranderinge gehad wat die bou verbreek het.

'n Voorbeeld van hoe dit gebeur:

Twee ontwikkelaars begin gelyktydig aan kenmerke A en B werk. Die ontwikkelaar van kenmerk A ontdek 'n ongebruikte kenmerk in die projek answer() en, soos 'n goeie verkenner, verwyder dit. Terselfdertyd voeg die ontwikkelaar van kenmerk B 'n nuwe oproep by hierdie funksie in sy tak.

Ontwikkelaars voltooi hul werk en maak terselfdertyd 'n trekversoek oop. Die bouwerk word geloods, premerge.sh kontroleer beide trekversoeke met betrekking tot die nuutste ontwikkelingstatus - alle tjeks is groen. Daarna word die trekversoek van kenmerk A saamgevoeg, die trekversoek van kenmerk B word saamgevoeg... Boem! Ontwikkel pouses omdat die ontwikkelkode 'n oproep na 'n nie-bestaande funksie bevat.

Wanneer dit nie gaan ontwikkel nie, is dit plaaslike ramp. Die hele span kan niks insamel en vir toetsing indien nie.

Dit het so gebeur dat ek die meeste aan infrastruktuurtake gewerk het: analise, netwerk, databasisse. Dit wil sê, dit was ek wat daardie funksies en klasse geskryf het wat ander ontwikkelaars gebruik. As gevolg hiervan het ek myself baie dikwels in soortgelyke situasies bevind. Ek het selfs hierdie prentjie vir 'n rukkie gehang.

Aangesien dit ons nie gepas het nie, het ons begin om opsies te ondersoek oor hoe om dit te voorkom.

Hoe om nie te breek ontwikkel nie

Die eerste opsie: herbou alle trekversoeke tydens die opdatering van ontwikkel. As, in ons voorbeeld, die trekversoek met kenmerk A die eerste is wat by ontwikkel ingesluit word, sal die trekversoek van kenmerk B herbou word, en dienooreenkomstig sal die tjeks misluk as gevolg van 'n samestellingsfout.

Om te verstaan ​​hoe lank dit sal neem, oorweeg 'n voorbeeld met twee PR's. Ons maak twee PR's oop: twee bouwerk, twee lopies tjeks. Nadat die eerste PR in ontwikkel is, moet die tweede een herbou word. In totaal vereis twee PR's drie lopies tjeks: 2 + 1 = 3.

In beginsel is dit goed. Maar ons het na die statistieke gekyk, en die tipiese situasie in ons span was 10 oop PR's, en dan is die aantal tjeks die som van die vordering: 10 + 9 +... + 1 = 55. Dit wil sê om 10 te aanvaar PR's, jy moet 55 keer herbou. En dit is in 'n ideale situasie, wanneer alle tjeks die eerste keer slaag, wanneer niemand 'n bykomende trekversoek oopmaak terwyl hierdie dosyn verwerk word nie.

Stel jou voor as 'n ontwikkelaar wat eerste moet wees om op die “merge”-knoppie te klik, want as 'n buurman dit doen, dan sal jy moet wag totdat al die bouwerk weer deurgaan... Nee, dit sal nie werk nie , sal dit ontwikkeling ernstig vertraag.

Tweede moontlike manier: versamel trekversoeke na kode hersiening. Dit wil sê, jy maak 'n trekversoek oop, versamel die vereiste aantal goedkeurings van kollegas, korrigeer wat nodig is en begin dan die bouwerk. As hulle suksesvol is, word die trekversoek saamgevoeg in ontwikkel. In hierdie geval is daar geen bykomende herbegins nie, maar die terugvoer word aansienlik vertraag. As 'n ontwikkelaar, wanneer ek 'n trekversoek oopmaak, wil ek dadelik sien of dit gaan werk. Byvoorbeeld, as 'n toets misluk, moet jy dit vinnig regmaak. In die geval van 'n vertraagde bou, vertraag terugvoer, en dus die hele ontwikkeling. Dit het ons ook nie gepas nie.

Gevolglik het slegs die derde opsie oorgebly - fiets. Al ons kode, al ons bronne word in 'n bewaarplek op die Bitbucket-bediener gestoor. Gevolglik moes ons 'n inprop vir Bitbucket ontwikkel.

Hierdie inprop ignoreer die trekversoeksamesmeltingsmeganisme. Die begin is standaard: die PR maak oop, alle samestellings word van stapel gestuur, kodehersiening is voltooi. Maar nadat die kode-hersiening voltooi is en die ontwikkelaar besluit om op "samevoeging" te klik, kontroleer die inprop teen watter ontwikkelingstoestand die kontrole uitgevoer is. As ontwikkel opgedateer is na die bou, sal die inprop nie toelaat dat so 'n trekversoek in die hooftak saamgevoeg word nie. Dit sal bloot die bouwerk van 'n relatief onlangse ontwikkeling herbegin.

In ons voorbeeld met botsende veranderinge, sal sulke bouwerk misluk as gevolg van 'n samestellingsfout. Gevolglik sal die ontwikkelaar van kenmerk B die kode moet regstel, die kontroles moet herbegin, dan sal die inprop outomaties die trekversoek toepas.

Voordat ons hierdie inprop geïmplementeer het, het ons gemiddeld 2,7 hersieningslopies per trekversoek gehad. Met die inprop was daar 3,6 bekendstellings. Dit het ons gepas.

Dit is opmerklik dat hierdie inprop 'n nadeel het: dit herbegin die bou net een keer. Dit wil sê, daar is nog 'n klein venster waardeur botsende veranderinge kan ontwikkel. Maar die waarskynlikheid hiervan is laag, en ons het hierdie afweging gemaak tussen die aantal begin en die waarskynlikheid van mislukking. In twee jaar het dit net een keer gevuur, so dit was seker nie verniet nie.

Dit het ons twee weke geneem om die eerste weergawe van die Bitbucket-inprop te skryf.

Nuwe tjeks

Intussen het ons span bly groei. Nuwe tjeks is bygevoeg.

Ons het gedink: hoekom foute maak as dit voorkom kan word? En dit is hoekom hulle geïmplementeer het statiese kode analise. Ons het begin met lint, wat by die Android SDK ingesluit is. Maar op daardie stadium het hy glad nie geweet hoe om met Kotlin-kode te werk nie, en ons het reeds 75% van die aansoek in Kotlin gehad. Daarom is ingeboude by pluis gevoeg Android Studio-tjeks.

Om dit te doen, moes ons baie pervertering doen: neem Android Studio, pak dit in Docker en laat dit op CI met 'n virtuele monitor hardloop, sodat dit dink dit werk op 'n regte skootrekenaar. Maar dit het gewerk.

Dit was ook in hierdie tyd dat ons baie begin skryf het instrumentasie toetse en geïmplementeer skermkiekie toets. Dit is wanneer 'n verwysingskermkiekie vir 'n aparte klein aansig gegenereer word, en die toets bestaan ​​uit die neem van 'n skermskoot uit die aansig en vergelyk dit met die standaard direk pixel vir pixel. As daar 'n teenstrydigheid is, beteken dit dat die uitleg iewers verkeerd geloop het of iets is verkeerd in die style.

Maar instrumentasietoetse en skermkiekietoetse moet op toestelle uitgevoer word: op emulators of op regte toestelle. As in ag geneem word dat daar baie toetse is en dit gereeld uitgevoer word, is 'n hele plaas nodig. Om jou eie plaas te begin is te arbeidsintensief, so ons het 'n klaargemaakte opsie gevind - Firebase Test Lab.

Firebase-toetslaboratorium

Dit is gekies omdat Firebase 'n Google-produk is, wat beteken dat dit betroubaar moet wees en dit is onwaarskynlik dat dit ooit sal sterf. Die pryse is redelik: $ 5 per uur van die werking van 'n regte toestel, 1 $ per uur van die werking van 'n emulator.

Dit het ongeveer drie weke geneem om Firebase Test Lab in ons CI te implementeer.

Maar die span het aanhou groei, en Firebase het ons ongelukkig in die steek gelaat. Op daardie tydstip het hy geen SLA gehad nie. Soms het Firebase ons laat wag totdat die vereiste aantal toestelle vry was vir toetse, en nie dadelik begin uitvoer soos ons wou nie. Om in die ry te wag het tot 'n halfuur geneem, wat 'n baie lang tyd is. Instrumentasietoetse is op elke PR uitgevoer, vertragings het die ontwikkeling regtig vertraag, en toe kom die maandelikse rekening met 'n ronde som. Oor die algemeen is besluit om Firebase te laat vaar en intern te werk, aangesien die span genoeg gegroei het.

Docker + Python + bash

Ons het Docker geneem, emulators daarin gestop, 'n eenvoudige program in Python geskryf, wat op die regte oomblik die vereiste aantal emulators in die vereiste weergawe opduik en dit stop wanneer nodig. En natuurlik 'n paar bash scripts - waar sou ons sonder hulle wees?

Dit het vyf weke geneem om ons eie toetsomgewing te skep.

As gevolg hiervan was daar vir elke trekversoek 'n uitgebreide samesmeltingsblokkeringslys van tjeks:

• ARK-samestelling;
• Junit toetse;
• Lint;
• Android Studio-tjeks;
• Instrumentasietoetse;
• Skermskoottoetse.

Dit het baie moontlike ineenstortings voorkom. Tegnies het alles gewerk, maar die ontwikkelaars het gekla dat die wag vir resultate te lank was.

Hoe lank is te lank? Ons het data van Bitbucket en TeamCity in die ontledingstelsel opgelaai en dit besef gemiddelde wagtyd 45 minute. Dit wil sê, 'n ontwikkelaar wag, wanneer hy 'n trekversoek oopmaak, gemiddeld 45 minute vir die bouresultate. Na my mening is dit baie, en jy kan nie so werk nie.

Ons het natuurlik besluit om al ons bouwerk te versnel.

Kom ons versnel

Aangesien geboue dikwels in 'n tou staan, is die eerste ding wat ons doen meer hardeware gekoop — uitgebreide ontwikkeling is die eenvoudigste. Bouwerk het opgehou toustaan, maar die wagtyd het net effens afgeneem, omdat sommige tjeks self baie lank geneem het.

Verwyder tjeks wat te lank neem

Ons deurlopende integrasie kan hierdie tipe foute en probleme opvang.

• Gaan nie. CI kan 'n samestellingsfout opspoor wanneer iets nie bou nie as gevolg van botsende veranderinge. Soos ek reeds gesê het, dan kan niemand iets bymekaarmaak nie, ontwikkeling stop, en almal raak senuweeagtig.
• Fout in gedrag. Byvoorbeeld, wanneer die toepassing gebou is, maar ineenstort wanneer jy 'n knoppie druk, of die knoppie glad nie gedruk word nie. Dit is sleg, want so 'n fout kan die gebruiker bereik.
• Fout in uitleg. Byvoorbeeld, 'n knoppie word geklik, maar het 10 pixels na links geskuif.
• Toename in tegniese skuld.

Nadat ons na hierdie lys gekyk het, het ons besef dat slegs die eerste twee punte van kritieke belang is. Ons wil eers sulke probleme opvang. Foute in die uitleg word tydens die ontwerp-hersieningstadium ontdek en kan dan maklik reggestel word. Die hantering van tegniese skuld verg 'n aparte proses en beplanning, daarom het ons besluit om dit nie op 'n trekversoek te toets nie.

Op grond van hierdie klassifikasie het ons die hele lys tjeks opgeskud. Lint deurgehaal en die bekendstelling daarvan oornag uitgestel: net sodat dit 'n verslag sou lewer oor hoeveel probleme daar in die projek was. Ons het ingestem om afsonderlik te werk met die tegniese skuld, en Android Studio-tjeks is heeltemal laat vaar. Android Studio in Docker vir die uitvoer van inspeksies klink interessant, maar veroorsaak baie probleme met ondersteuning. Enige opdatering van Android Studio-weergawes beteken 'n stryd met onverstaanbare foute. Dit was ook moeilik om skermkiekietoetse te ondersteun, want die biblioteek was nie baie stabiel nie en daar was vals positiewes. Skermskoottoetse is van die kontrolelys verwyder.

As gevolg hiervan het ons gelaat met:

• ARK-samestelling;
• Junit toetse;
• Instrumentasie toetse.

Gradle-afgeleë kas

Sonder swaar tjeks het alles beter geword. Maar daar is geen beperking op perfeksie nie!

Ons aansoek is reeds in ongeveer 150 graadmodules verdeel. Gradle-afgeleë kas werk gewoonlik goed in hierdie geval, so ons het besluit om dit te probeer.

Gradle-afgeleë kas is 'n diens wat artefakte vir individuele take in individuele modules in die kas kan bou. Gradle, in plaas daarvan om eintlik die kode saam te stel, gebruik HTTP om op die afgeleë kas te klop en te vra of iemand reeds hierdie taak uitgevoer het. Indien wel, laai dit eenvoudig die resultaat af.

Dit is maklik om Gradle-afgeleë kas te laat loop omdat Gradle 'n Docker-beeld verskaf. Ons het dit in drie uur reggekry.

Al wat u moes doen, was om Docker te begin en een reël in die projek te skryf. Maar hoewel dit vinnig van stapel gestuur kan word, sal dit nogal baie tyd neem vir alles om goed te werk.

Hieronder is die kas mis grafiek.

Heel aan die begin was die persentasie kasmislukkings ongeveer 65. Na drie weke het ons daarin geslaag om hierdie waarde tot 20% te verhoog. Dit het geblyk dat die take wat die Android-toepassing versamel, vreemde oorganklike afhanklikhede het, waardeur Gradle die kas gemis het.

Deur die kas te koppel, het ons die bou baie bespoedig. Maar benewens montering is daar ook instrumentasietoetse, en dit neem lank. Miskien hoef nie alle toetse vir elke trekversoek uitgevoer te word nie. Om uit te vind, gebruik ons ​​impakanalise.

Impakanalise

Op 'n trekversoek versamel ons git diff en vind die gewysigde Gradle-modules.

Dit maak sin om slegs instrumentasietoetse uit te voer wat die veranderde modules en alle modules wat daarvan afhanklik is, kontroleer. Daar is geen sin om toetse vir naburige modules uit te voer nie: die kode daar het nie verander nie en niks kan breek nie.

Instrumentasietoetse is nie so eenvoudig nie, want dit moet in die topvlak Toepassingsmodule geleë wees. Ons het heuristiek met greepkode-analise gebruik om te verstaan ​​aan watter module elke toets behoort.

Die opgradering van die werking van die instrumentasietoetse sodat dit slegs die betrokke modules toets, het sowat agt weke geneem.

Maatreëls om inspeksies te bespoedig het suksesvol gewerk. Vanaf 45 minute het ons opgegaan na so 15. Dit is reeds normaal om 'n kwartier te wag vir 'n bou.

Maar nou het ontwikkelaars begin kla dat hulle nie verstaan ​​watter bouwerk begin word nie, waar om die log te sien, hoekom die bou rooi is, watter toets misluk het, ens.

Probleme met terugvoer vertraag ontwikkeling, daarom het ons probeer om so duidelike en gedetailleerde inligting oor elke PR en bou as moontlik te verskaf. Ons het begin met opmerkings in Bitbucket aan die PR, wat aandui watter bouwerk misluk het en hoekom, en het geteikende boodskappe in Slack geskryf. Op die ou end het ons 'n PR-kontroleskerm vir die bladsy geskep met 'n lys van alle bouwerk wat tans aan die gang is en hul status: in die ry, loop, omgeval of voltooi. U kan op die bou klik en by die logboek kom.

Ses weke is aan gedetailleerde terugvoer bestee.

Planne

Kom ons gaan aan na onlangse geskiedenis. Nadat ons die terugvoerkwessie opgelos het, het ons 'n nuwe vlak bereik - ons het besluit om ons eie emulatorplaas te bou. As daar baie toetse en emulators is, is dit moeilik om te bestuur. Gevolglik het al ons emulators na die k8s-kluster met buigsame hulpbronbestuur verskuif.

Daarbenewens is daar ander planne.

• Keer Lint terug (en ander statiese analise). Ons werk reeds in hierdie rigting.
• Begin alles op 'n PR-blokker end-tot-end toetse op alle SDK-weergawes.

Dus, ons het die geskiedenis van die ontwikkeling van deurlopende integrasie in Avito opgespoor. Nou wil ek bietjie raad gee vanuit 'n ervare oogpunt.

Советы

As ek net een raad kan gee, sal dit die volgende wees:

Wees asseblief versigtig met dopskrifte!

Bash is 'n baie buigsame en kragtige instrument, dit is baie gerieflik en vinnig om skrifte te skryf. Maar jy kan daarmee in 'n strik trap, en ons het ongelukkig daarin getrap.

Dit het alles begin met eenvoudige skrifte wat op ons boumasjiene uitgevoer is:

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

Maar, soos jy weet, ontwikkel alles en word mettertyd meer ingewikkeld - kom ons laat een skrif van 'n ander af loop, kom ons gee 'n paar parameters daar deur - op die ou end moes ons 'n funksie skryf wat bepaal op watter vlak van bash nes ons nou in orde is om die nodige aanhalings in te voeg, om alles aan die gang te kry.

Jy kan jou die arbeidskoste vir die ontwikkeling van sulke skrifte voorstel. Ek raai jou aan om nie in hierdie strik te trap nie.

Wat kan vervang word?

• Enige skriftaal. Skryf na Python of Kotlin Script geriefliker omdat dit programmering is, nie skrifte nie.
• Of beskryf al die boulogika in die vorm Pasgemaakte graadtake vir jou projek.

Ons het besluit om die tweede opsie te kies, en nou vee ons stelselmatig alle bash-skrifte uit en skryf baie pasgemaakte graadtake.

Wenk #2: Stoor infrastruktuur in kode.

Dit is gerieflik wanneer die Continuous Integration-instelling nie in die UI-koppelvlak van Jenkins of TeamCity, ens. gestoor word nie, maar in die vorm van tekslêers direk in die projekbewaarplek. Dit gee weergawebaarheid. Dit sal nie moeilik wees om terug te draai of die kode op 'n ander tak te bou nie.

Skripte kan in 'n projek gestoor word. Wat om met die omgewing te doen?

Wenk #3: Docker kan help met die omgewing.

Dit sal beslis Android-ontwikkelaars help; iOS het ongelukkig nog nie een nie.

Dit is 'n voorbeeld van 'n eenvoudige docker-lêer wat jdk en android-sdk bevat:

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

Nadat jy hierdie Docker-lêer geskryf het (ek sal jou 'n geheim vertel, jy hoef dit nie te skryf nie, maar trek dit net klaar gemaak vanaf GitHub) en die prent saamgestel het, kry jy 'n virtuele masjien waarop jy die toepassing kan bou en voer Junit-toetse uit.

Die twee hoofredes waarom dit sin maak, is skaalbaarheid en herhaalbaarheid. Deur Docker te gebruik, kan jy vinnig 'n dosyn bou-agente insamel wat presies dieselfde omgewing as die vorige een sal hê. Dit maak die lewe van CI-ingenieurs baie makliker. Dit is redelik maklik om die Android-sdk in docker te druk, maar met emulators is dit 'n bietjie moeiliker: jy sal 'n bietjie harder moet werk (of die voltooide een weer van GitHub aflaai).

Wenk nr 4: moenie vergeet dat inspeksies nie ter wille van inspeksies gedoen word nie, maar vir mense.

Vinnige en, bowenal, duidelike terugvoer is baie belangrik vir ontwikkelaars: wat het gebreek, watter toets het misluk, waar kan ek die buildlog sien.

Wenk #5: Wees pragmaties wanneer jy deurlopende integrasie ontwikkel.

Verstaan ​​duidelik watter tipe foute jy wil voorkom, hoeveel hulpbronne, tyd en rekenaartyd jy bereid is om te spandeer. Tjeks wat te lank neem, kan byvoorbeeld oornag uitgestel word. En dié van hulle wat nie baie belangrike foute opvang nie, moet heeltemal laat vaar word.

Wenk #6: Gebruik gereedgemaakte gereedskap.

Daar is nou baie maatskappye wat wolk CI verskaf.

Dit is 'n goeie oplossing vir klein spanne. Jy hoef niks te ondersteun nie, betaal net 'n bietjie geld, bou jou toepassing en voer selfs instrumentasietoetse uit.

Wenk #7: In 'n groot span is interne oplossings meer winsgewend.

Maar vroeër of later, soos die span groei, sal interne oplossings meer winsgewend word. Daar is een probleem met hierdie besluite. Daar is 'n wet van dalende opbrengste in ekonomie: in enige projek is elke daaropvolgende verbetering al hoe moeiliker en verg meer en meer belegging.

Ekonomie beskryf ons hele lewe, insluitend deurlopende integrasie. Ek het 'n skedule van arbeidskoste vir elke stadium van ontwikkeling van ons Deurlopende Integrasie opgestel.

Dit is duidelik dat enige verbetering al hoe moeiliker word. As u na hierdie grafiek kyk, kan u verstaan ​​dat deurlopende integrasie ontwikkel moet word in ooreenstemming met die groei van die spangrootte. Vir 'n span van twee mense is dit 'n middelmatige idee om 50 dae te spandeer om 'n interne emulatorplaas te ontwikkel. Maar terselfdertyd, vir 'n groot span, is dit glad nie om deurlopende integrasie te doen ook 'n slegte idee nie, want integrasieprobleme, regstelling van kommunikasie, ens. dit sal nog meer tyd neem.

Ons het begin met die idee dat outomatisering nodig is omdat mense duur is, hulle maak foute en is lui. Maar mense outomatiseer ook. Daarom geld al dieselfde probleme vir outomatisering.

• Outomatisering is duur. Onthou die kraamskedule.
• As dit by outomatisering kom, maak mense foute.
• Soms is dit baie lui om te outomatiseer, want alles werk so. Waarom enigiets anders verbeter, hoekom al hierdie deurlopende integrasie?

Maar ek het statistieke: foute word in 20% van samestellings opgespoor. En dit is nie omdat ons ontwikkelaars kode swak skryf nie. Dit is omdat ontwikkelaars vol vertroue is dat as hulle een of ander fout maak, dit nie in ontwikkeling sal eindig nie, dit sal deur outomatiese kontrole gevang word. Gevolglik kan ontwikkelaars meer tyd spandeer om kode en interessante dinge te skryf, eerder as om iets plaaslik te hardloop en te toets.

Oefen deurlopende integrasie. Maar in moderering.

Terloops, Nikolai Nesterov gee nie net self goeie verslae nie, maar is ook 'n lid van die programkomitee AppsConf en help ander om betekenisvolle toesprake vir jou voor te berei. Die volledigheid en bruikbaarheid van die volgende konferensieprogram kan geassesseer word deur onderwerpe in skedule. En vir besonderhede, kom na Infospace op 22-23 April.

Bron: will.com