Idag utvecklas de flesta programvaruprodukter i team. Villkoren för framgångsrik teamutveckling kan sammanfattas i en enkel schema.

När du har skrivit koden måste du se till att den:

1. Fungerar.
2. Inte bryter något, inklusive koden som dina kollegor har skrivit.

Om båda villkoren är uppfyllda är du på väg mot framgång. För att enkelt kunna kontrollera dessa villkor och inte avvika från den lönsamma vägen, har Continuous Integration utvecklats.

CI är en arbetsprocess där du så ofta som möjligt integrerar din kod med den gemensamma koden för produkten. Och inte bara integrerar, utan också ständigt kontrollerar att allt fungerar. Eftersom det är mycket som behöver kontrolleras och ofta, är det värt att tänka på automatisering. Man kan göra allt manuellt, men det är inte att rekommendera, och här är varför.

• Människor är dyra. En timme arbete för en programmerare kostar mer än en timme arbete för en server.
• Människor gör misstag. Därför kan det uppstå situationer när tester körs på fel gren eller när fel begcommit har byggts för testarna.
• Människor är lata. Periodvis, när jag avslutar en uppgift, har jag tanken: "Vad ska jag ens kontrollera? Jag har skrivit två rader – det fungerar garanterat!" Jag tror att några av er också ibland får sådana tankar. Men man måste alltid kontrollera.

Hur Continuous Integration implementerades och utvecklades i Avitos mobila utvecklingsteam, hur man gick från 0 till 450 byggningar per dag, och vad byggmaskinerna samlar in 200 timmar per dag, berättar Nikolai Nesterov (nnesterov) – deltagare i alla evolutionära förändringar av CI/CD Android-applikationen.

Berättelsen baseras på exemplet av Android-teamet, men de flesta metoder är också tillämpliga på iOS.

En gång i tiden arbetade bara en person i Avitos Android-team. För honom behövdes ingenting från Continuous Integration, eftersom det inte fanns någon att integrera med.

Men applikationen växte, fler och fler nya uppgifter dök upp, och därmed växte teamet. Vid en viss tidpunkt kom tiden att mer formellt organisera kodintegrationsprocessen. Det beslutades att använda Git flow.

Git flow-konceptet är välkänt: i projektet finns en gemensam branch, develop, och för varje ny funktion skapar utvecklarna en separat branch, gör sina commits, pushar och när de vill föra in sin kod i develop-branchen öppnar de en pull request. För kunskapsutbyte och diskussion av metoder har vi infört code review, vilket innebär att kollegor måste granska och bekräfta varandras kod.

Kontroller

Att se på koden är bra, men otillräckligt. Därför införs automatiska kontroller.

• Först kontrollerar vi ARC-byggnaden.
• Många Junit-tester.
• Vi beräknar code coverage, eftersom vi kör tester.

För att förstå hur dessa kontroller ska köras, låt oss titta på utvecklingsprocessen på Avito.

Det kan schematiskt representeras så här:

• Utvecklaren skriver kod på sin dator. Det är möjligt att köra integrationskontroller här — antingen via commit-hook eller bara köra kontrollerna i bakgrunden.
• När utvecklaren har pushat koden öppnar han en pull request. För att hans kod ska hamna i develop-branchen måste han klara code review och få tillräckligt med bekräftelser. Kontroller och byggen kan aktiveras här: medan inte alla byggen är framgångsrika kan inte pull request slås ihop.
• När pull requesten har slagits ihop och koden har hamnat i develop kan man välja ett lämpligt tillfälle: till exempel på natten, när alla servrar är lediga, och köra kontroller hur mycket som helst.

Att köra kontroller på sin dator gillade ingen. När utvecklaren har slutfört sin funktion vill han snabbt push-a den och öppna en pull request. Om det vid den tidpunkten körs några långa kontroller är det inte bara obehagligt utan saktar också ner utvecklingen: medan datorn kontrollerar något kan han inte arbeta normalt.

Vi gillade mycket att köra kontroller på natten, eftersom det finns gott om tid och servrar, man kan verkligen ta sig tid. Men tyvärr, när funktionens kod har kommit in i develop har utvecklaren mycket mindre motivation att fixa de fel som CI har hittat. Jag fångade mig själv då och då när jag tittade på alla hittade fel i morgonrapporten och tänkte att jag skulle fixa dem senare, eftersom det just nu ligger en fantastisk ny uppgift i Jira som jag verkligen vill börja arbeta med.

Om kontroller blockerar pull requesten, finns det motivation nog, eftersom medan byggena inte är gröna, kommer koden inte in i develop, vilket innebär att uppgiften inte kommer att bli slutförd.

Till slut valde vi en strategi där vi kör en maximal uppsättning tester på natten, och de mest kritiska och framför allt snabba testerna kör vi vid pull request. Men vi stannar inte där — samtidigt optimerar vi hastigheten på testerna så att vi kan flytta dem från nattläge till pull request-tester.

Vid den tiden gick alla våra byggen tillräckligt snabbt, så vi aktiverade bara blockeraren för pull request-bygget av ARC, Junit-tester och beräkning av kodtäckning. Vi aktiverade det, funderade — och beslutade oss för att avstå från kodtäckning, eftersom vi ansåg att det inte var nödvändigt.

Det tog oss två dagar att konfigurera grundläggande CI (denna tidsuppskattning är ungefärlig och behövs för perspektivet).

Efter det började vi tänka vidare — testerar vi överhuvudtaget korrekt? Kör vi byggen vid pull request på rätt sätt?

Vi körde bygget på den senaste commit av grenen från vilken pull requesten öppnades. Men testerna av denna commit kan bara visa att den kod som utvecklaren skrivit fungerar. De bevisar inte att han eller hon inte bröt något. Egentligen måste vi kontrollera tillståndet på utvecklingsgrenen efter att funktionen har blivit integrerad.

För detta skrev vi ett enkelt bash-skript. premerge.sh:

#!/usr/bin/env bash

set -e

git fetch origin develop

git merge origin/develop

Här dras helt enkelt de senaste ändringarna från utvecklingsgrenen och slås samman med den aktuella grenen. Vi lade till skriptet premerge.sh som det första steget av alla byggen och började kontrollera just det vi vill, det vill säga integrationen.

Det tog tre dagar att lokalisera problemen, hitta lösningen och skriva detta skript.

Applikationen utvecklades, uppgifterna blev fler, teamet växte, och ibland började premerge.sh att svika oss. Konfliktande ändringar trängde in i utvecklingsgrenen och bröt bygget.

Ett exempel på hur detta sker:

Två utvecklare börjar samtidigt arbeta med funktionerna A och B. Utvecklaren av funktion A upptäcker en oanvänd funktion i projektet, answer() och, som en bra scout, tar bort den. Samtidigt lägger utvecklaren av funktion B till ett nytt anrop av denna funktion i sin gren.

Utvecklarna avslutar sitt arbete och öppnar samtidigt en pull request. Byggen startar, premerge.sh kontrollerar båda pull requesterna mot det aktuella tillståndet på utvecklingsgrenen — alla tester är gröna. Efter det merges pull request A, pull request B... Boom! Utvecklingsgrenen kraschade, eftersom det finns ett anrop av en icke-existerande funktion i koden.

När utvecklingsgrenen inte går att bygga, lokal katastrof. Hela teamet kan inte samla något och ge det för testning.

Så blev det att jag oftast ägnade mig åt infrastrukturuppgifter: analys, nätverk, databaser. Det var jag som skrev de funktioner och klasser som andra utvecklare använder. Därför hamnade jag ofta i liknande situationer. Jag hade till och med en tid bild på det här.

Eftersom detta inte passade oss började vi arbeta på alternativ för hur vi kunde förhindra det.

Hur man inte bryter develop

Första alternativet: återkompilera alla pull requests vid uppdatering av develop. Om i vårt exempel pull request med funktion A först går in i develop, kommer pull request för funktion B att återkompileras, och därmed kommer kontrollerna att misslyckas på grund av kompilationsfel.

För att förstå hur mycket tid detta kommer att ta, låt oss titta på ett exempel med två PR. Vi öppnar två PR: två byggen, två körningar av kontroller. Efter att den första PR har slagits samman med develop måste den andra återkompileras. Totalt tar det tre körningar av kontroller för två PR: 2 + 1 = 3.

I princip okej. Men vi tittade på statistiken, och en typisk situation i vårt team var 10 öppna PR, då blir antalet kontroller summan av progressionen: 10 + 9 + … + 1 = 55. Det vill säga för att godkänna 10 PR måste man återkompilera 55 gånger. Och det är i en ideal situation, där alla kontroller går igenom på första försöket, där ingen öppnar någon ytterligare pull request medan denna tio stycken bearbetas.

Föreställ dig att du är en utvecklare som måste hinna trycka på knappen "merge" först, för om det görs av grannen så får man vänta på att alla byggen ska genomföras igen... Nej, så här kan vi inte ha det, det kommer allvarligt att fördröja utvecklingen.

Andra möjliga sättet: kompilera pull request efter code review. Det vill säga du öppnar en pull request, samlar in det nödvändiga antalet godkännanden från kollegor, åtgärdar vad som behövs, och först då kör du byggen. Om de är framgångsrika, slås pull request ihop med develop. I detta fall finns det inga ytterligare omstarter, men feedbacken blir betydligt långsammare. Jag, som utvecklare, vill direkt se om min pull request kan byggas. Till exempel, om ett test misslyckas, behöver jag snabbt fixa det. I händelse av försenad kompilering sänks feedbacken, vilket också sänker hela utvecklingen. Det passade oss inte heller.

Till slut kvarstod bara det tredje alternativet - att cykla. All vår kod, alla våra källkoder lagras i ett repository på Bitbucket-servern. Därför var vi tvungna att utveckla en plugin för Bitbucket.

Denna plugin överskrider sammanslagningsmetoden för pull requestar. Den standardmässiga processen inleds: en PR öppnas, alla byggen körs och en kodgranskning utförs. Men efter att kodgranskningen har slutförts och utvecklaren bestämmer sig för att klicka på 'merge', kontrollerar pluginen vilket tillstånd develop som testerna kördes mot. Om develop har uppdaterats efter byggena tillåter pluginen inte att sådana pull requestar slås samman med huvudgrenen. Den startar helt enkelt om byggena mot det nya develop.

I vårt exempel med konfliktfyllda ändringar kommer sådana byggen inte att passera på grund av kompilatorfel. Därför måste utvecklaren av funktion B rätta koden och starta om testerna, så tillämpas pull requesten automatiskt av pluginen.

Innan vi implementerade denna plugin hade vi i genomsnitt 2,7 tester som kördes per pull request. Med pluginen blev det 3,6 tester. Det var vi nöjda med.

Det är värt att notera att denna plugin har en nackdel: den startar om bygget endast en gång. Det finns alltså fortfarande en liten möjlighet för konfliktfyllda ändringar att komma in i develop. Men sannolikheten för detta är låg, och vi accepterade denna kompromiss mellan antalet körningar och risken för problem. Under två år inträffade det bara en gång, så kanske var det inte förgäves.

Det tog oss två veckor att skriva den första versionen av pluggen för Bitbucket.

Nya tester

Under tiden fortsatte vårt team att växa. Nya tester lades till.

Vi tänkte: varför åtgärda fel när vi kan förhindra dem? Och därför implementerade vi statisk kodanalys. Vi började med lint, som ingår i Android SDK. Men då kunde den helt och hållet inte arbeta med Kotlin-kod, och vi hade redan 75% av applikationen skriven i Kotlin. Därför lades inbyggda till Android Studio checks.

För detta behövde vi verkligen vrida och vända: ta Android Studio, paketera den i Docker och köra den på CI med en virtuell skärm, så att den trodde att den kördes på en riktig bärbar dator. Men det fungerade.

Samtidigt började vi också skriva många instrumentation-tester och implementerade screenshot-testning.Det här är när en referensskärmdump genereras för en separat liten vy, och testet går ut på att ta en skärmdump från vyn och jämföra den pixel för pixel med referensen. Om det finns avvikelser betyder det att layouten har blivit fel eller att något inte stämmer med stilarna.

Men instrumentationstester och skärmdumpstester måste köras på enheter: på emulatorer eller på verkliga enheter. Med tanke på att det finns många tester som körs ofta behövs en hel farm. Att upprätta sin egen farm är för arbetskrävande, så vi hittade ett färdigt alternativ — Firebase Test Lab.

Firebase Test Lab

Valdes eftersom Firebase är en produkt från Google, vilket innebär att den bör vara pålitlig och knappast kommer att dö ut. Priserna är överkomliga: 5 $ per timme för en verklig enhet, 1 $ per timme för en emulator.

Implementeringen av Firebase Test Lab i vår CI tog ungefär tre veckor.

Men teamet fortsatte att växa, och tyvärr började Firebase svika oss. Vid den tidpunkten hade den inga SLA:er. Ibland tvingade Firebase oss att vänta på att rätt antal enheter skulle bli tillgängliga för tester, istället för att köra dem direkt som vi ville. Väntetiden i kön kunde ta upp till en halvtimme, vilket är mycket länge. Instrumentationstester kördes på varje PR, och fördröjningarna bromsade ner utvecklingen, och sedan fick vi en månadsräkning som var ganska hög. Sammanfattningsvis beslutades det att avstå från Firebase och utveckla in-house, eftersom teamet hade blivit tillräckligt stort.

Docker + Python + bash

Vi tog docker, stoppade in emulatorerna i den, och skrev ett enkelt program i Python som när det behövdes startar ett visst antal emulatorer i rätt version och när vi behöver stoppar dem. Och såklart, några bash-skript — hur skulle vi klara oss utan dem?

Det tog fem veckor att skapa vår egen testmiljö.

Som resultat hade varje pull request en omfattande, blockerande lista med kontroller:

• Bygg av APK;
• Junit-tester;
• Lint;
• Android Studio-kontroller;
• Instrumentationstester;
• Skärmdumpstester.

Detta förhindrade många möjliga fel. Tekniskt sett fungerade allt, men utvecklarna klagade på att det tog för lång tid att få resultat.

För lång tid — hur lång tid är det? Vi extraherade data från Bitbucket och TeamCity till ett analysystem och insåg att den genomsnittliga väntetiden var 45 minuter. Det betyder att en utvecklare i genomsnitt väntar 45 minuter på byggresultaten när de öppnar en pull request. Enligt min mening är det alldeles för mycket och så kan vi inte arbeta.

Självklart bestämde vi oss för att snabba upp alla våra byggprocesser.

Vi accelererar

När vi såg att byggen ofta stod i kö, började vi först och främst köpa mer hårdvara — extensiv utveckling är det enklaste. Byggen slutade stå i kö, men väntetiden minskade bara lite, eftersom vissa kontroller själva tog väldigt lång tid.

Vi tar bort alltför långa kontroller

Vår Continuous Integration kunde fånga sådana typer av fel och problem.

• Kan inte byggas. CI kan fånga ett kompilationsfel när inget kan byggas på grund av konflikterande förändringar. Som jag redan nämnt kan ingen bygga något, utvecklingen stannar av, och alla är nervösa.
• Fel i beteende. Till exempel när applikationen byggs, men den kraschar när man trycker på en knapp, eller knappen går överhuvudtaget inte att trycka på. Det är dåligt, eftersom sådana fel kan nå användaren.
• Fel i layout. Till exempel när knappen går att trycka på, men den har förflyttats 10 pixlar åt vänster.
• Ökning av teknisk skuld.

Genom att titta på denna lista insåg vi att endast de första två punkterna är kritiska. Dessa problem vill vi fånga först och främst. Layoutfel upptäcktes under design-granskningen och kan lätt rättas till då. Arbetet med teknisk skuld kräver en separat process och planering, därför bestämde vi oss för att inte kontrollera det på pull request.

Utifrån denna klassificering gick vi igenom hela listan med kontroller. Vi strök Lint och flyttade dess körning till natten: bara för att den skulle ge rapporten om hur många problem som finns i projektet. Med teknisk skuld kom vi överens om att arbeta separat, och vi avstod från Android Studio-kontroller helt. Android Studio i Docker för att köra inspektioner låter intressant, men ger många problem med underhållet. Varje uppdatering av versioner av Android Studio innebär en kamp med oförklarliga fel. Det var också svårt att stödja skärmbildstester, eftersom biblioteket fungerade inte särskilt stabilt, det förekom falska positiva. Vi tog bort skärmbildstester från kontrollistan.

Till slut har vi kvar:

• Bygg av APK;
• Junit-tester;
• Instrumentation tests.

Gradle remote cache

Utan tunga kontroller har allt blivit bättre. Men det finns ingen gräns för perfektion!

Vår applikation var redan uppdelad i cirka 150 gradle-moduler. Vanligtvis fungerar Gradle remote cache bra i sådana fall, och vi bestämde oss för att prova det.

Gradle remote cache är en tjänst som kan cachelager byggartefakter för enskilda uppgifter i specifika moduler. Gradle kontrollerar istället för att faktiskt kompilera koden, via HTTP, i remote cache om någon redan har kört den här uppgiften. Om så är fallet, laddar den helt enkelt ner resultatet.

Att starta Gradle remote cache är enkelt, eftersom Gradle tillhandahåller en Docker-bild. Vi lyckades göra detta på tre timmar.

Det behövdes bara att starta Docker och skriva en rad i projektet. Men även om det går snabbt att starta, krävs det ganska mycket tid för att allt ska fungera bra.

Nedan finns en graf över cache misses.

I början var andelen cache misses cirka 65%. Efter tre veckor lyckades vi sänka detta värde till 20%. Det visade sig att uppgifterna som Android-applikationen bygger hade konstiga transitiva beroenden, vilket gjorde att Gradle missade cachen.

Genom att ansluta cachen lyckades vi avsevärt påskynda bygget. Men förutom bygget körs också instrumentation tester, och de tar lång tid att köra. Kanske behöver vi inte köra alla tester på varje pull request. För att ta reda på detta använder vi påverkananalys.

Påverkananalys

På pull request samlar vi git diff och hittar de ändrade Gradle-modulerna.

Det är meningsfullt att bara köra de instrumentation tester som kontrollerar de ändrade modulerna och alla moduler som beror på dem. Att köra tester för angränsande moduler är inte meningsfullt: där har inget kod ändrats, och ingenting kan gå sönder.

Med instrumentation tester är det inte så enkelt, eftersom de måste befinna sig i den översta applikationsmodulen. Vi använde en heuristik baserad på bytekodanalys för att förstå vilken modul varje test tillhör.

Modernisering av arbetet med instrumentation tester, för att de endast ska kontrollera involverade moduler, tog ungefär åtta veckor.

Åtgärderna för att påskynda kontrollerna fungerade framgångsrikt. Vi gick från 45 minuter ner till cirka 15. Att vänta en kvarts timme på bygget är redan acceptabelt.

Men nu har utvecklarna börjat klaga på att de inte förstår vilka byggen som körs, var de kan se loggar, varför bygget är rött, vilket test som misslyckades etc.

Problem med återkoppling fördröjer utvecklingen, därför har vi strävat efter att tillhandahålla så tydlig och detaljerad information som möjligt om varje PR och build. Vi började med kommentarer i Bitbucket för PR där vi angav vilken build som misslyckades och varför, samt skickade riktade meddelanden i Slack. Till slut skapade vi en PR-dashboard som visar en lista över alla builds som för närvarande körs och deras status: i kö, körs, misslyckad eller avslutad. Man kan klicka på en build och komma till dess logg.

Det har tagit sex veckor att få detaljerad återkoppling.

Planer

Vi går vidare till den senaste historien. Efter att ha löst frågan om återkoppling, har vi nått en ny nivå - vi har beslutat att bygga vår egen emulatorfarm. När det finns många tester och emulatorer blir det svårt att hantera dem. Resultatet blev att alla våra emulatorer flyttade till en k8s-kluster med flexibel resursförvaltning.

Dessutom finns det andra planer.

• Återställ Lint (och annan statisk analys). Vi arbetar redan på detta.
• Kör alla end-to-end tester på alla versioner av SDK.

Så, vi har spårat utvecklingen av Continuous Integration på Avito. Nu vill jag ge några råd från en erfaren.

Tips

Om jag bara kunde ge ett råd, skulle det vara detta:

Var snäll och var försiktig med shell-skript!

Bash är ett mycket flexibelt och kraftfullt verktyg, det är mycket bekvämt och snabbt att skriva skript på. Men man kan falla i fällan, och tyvärr har vi gjort det.

Det började med enkla skript som kördes på våra byggmaskiner:

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

Men, som bekant, utvecklas allt med tiden och blir mer komplext - låt oss köra ett skript från ett annat, låt oss vidarebefordra några parametrar - i slutändan var vi tvungna att skriva en funktion som bestämmer vilken nivå av inbäddning vi befinner oss på, så att vi kan sätta in rätt citattecken så att allt kan starta.

Kan du föreställa dig arbetsinsatsen för att utveckla sådana skript? Jag rekommenderar att undvika den här fällan.

Vad kan man ersätta det med?

• Vilket skriptspråk som helst. Det är bekvämare att skriva på Python eller Kotlin Script eftersom det är programmering, inte skript.
• Eller beskriva all logik i byggen i form av Custom gradle tasks för ditt projekt.

Vi valde den andra varianten och nu tar vi systematiskt bort alla bash-skript och skriver många anpassade gradle-tasks.

Råd nr 2: Spara infrastrukturen i kod.

Det är praktiskt när inställningen för Continuous Integration inte lagras i UI-gränssnittet i Jenkins, TeamCity och liknande, utan som textfiler direkt i projektets repository. Detta ger versionshantering. Det blir inte svårt att återgå eller bygga koden på en annan gren.

Skript kan lagras i projektet. Men vad gör man med miljön?

Tips #3: Docker kan hjälpa med miljön.

Det kommer definitivt att hjälpa Android-utvecklare, tyvärr inte iOS.

Detta är ett exempel på en enkel dockerfil som innehåller jdk och 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

# Ladda ner 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

# Installera Android Build Tool och bibliotek
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

Genom att skriva denna dockerfil (jag säger i hemlighet att man kan hoppa över den och ladda ner en färdig från GitHub) och bygga en bild får du en virtuell maskin där du kan bygga applikationen och köra Junit-tester.

De två huvudargumenten till varför detta är meningsfullt är skalbarhet och repetitivitet. Med docker kan man snabbt sätta upp ett dussin byggagenter som har precis samma miljö som den tidigare. Detta underlättar verkligen livet för CI-ingenjörer. Att packa android-sdk i docker är ganska enkelt, men med emulatorer är det lite mer komplicerat: man får jobba lite mer (eller återigen ladda ner en färdig från GitHub).

Tips #4: Glöm inte att tester görs inte för testernas skull, utan för människorna.

Utvecklare värdesätter snabb och, framför allt, tydlig återkoppling: vad som har gått fel, vilket test som misslyckades, var de kan se byggloggen.

Tips #5: Var pragmatisk i utvecklingen av Continuous Integration.

Ha en klar förståelse för vilken typ av fel du vill förebygga, hur mycket resurser, tid och maskintid du är beredd att investera. För långvariga tester kan man till exempel schemalägga dem på natten. Och de tester som fångar mindre viktiga fel kan helt enkelt tas bort.

Tips #6: Använd färdiga verktyg.

Det finns nu många företag som erbjuder molnbaserad CI.

För små team är detta en bra lösning. Du behöver inte underhålla något, bara betala lite pengar, bygga din applikation och till och med köra instrumenteringstester.

Tips 7: i ett stort team är in-house-lösningar mer lönsamma.

Men förr eller senare, med teamets tillväxt, blir in-house-lösningar mer fördelaktiga. Det finns en aspekt med dessa lösningar. Inom ekonomin finns en lag om avtagande avkastning: i vilket projekt som helst blir varje efterföljande förbättring allt svårare och kräver allt mer investeringar.

Ekonomin beskriver hela vårt liv, inklusive Continuous Integration. Jag har byggt en graf över arbetsinsatsen för varje steg i utvecklingen av vår Continuous Integration.

Det är tydligt att varje förbättring blir allt svårare. Genom att titta på denna graf kan man förstå att utvecklingen av Continuous Integration måste ske i takt med att teamets storlek växer. För ett team på två personer är det inte så bra idé att spendera 50 dagar på att utveckla en intern emulatorfarm. Men samtidigt är det också en dålig idé för ett stort team att helt lämna Continuous Integration åt sidan, eftersom mer tid kommer att gå åt till integrationsproblem, att fixa kommunikation etc.

Vi började med att automation är nödvändig eftersom människor är dyra, de gör misstag och är lata. Men de som automatiserar är också människor. Därför gäller samma problem även för automation.

• Att automatisera är dyrt. Tänk på grafen över arbetsinsatsen.
• Vid automation gör människor misstag.
• Att automatisera är ibland väldigt tråkigt, eftersom allt redan fungerar. Varför förbättra något, varför all denna Continuous Integration?

Men jag har statistik: 20% av byggen fångar buggar. Och detta händer inte för att våra utvecklare skriver dålig kod. Det beror på att utvecklarna är säkra på att om de gör något misstag, kommer det inte att hamna i utvecklingsgrenen, det kommer att upptäckas av automatiserade tester. Därför kan utvecklarna lägga mer tid på att skriva kod och intressanta saker, istället för att köra och kontrollera något lokalt.

Syssla med Continuous Integration. Men i måttliga mängder.

För övrigt gör Nikolay Nesterov inte bara fantastiska föredrag själv, utan ingår också i programkommittén AppsConf och hjälper andra att förbereda meningsfulla presentationer för er. Hela programmet för nästa konferens kan bedömas utifrån ämnena i schemat. För mer information, kom till Infoprime den 22-23 april.

Källa: habr.com