Continous Integration som praxis, inte Jenkins. Andrey Alexandrov

Låt oss diskutera varför CI-verktyg och CI är helt olika saker.

Vilken smärta är CI avsedd att lösa, varifrån kom idén, vilka senaste bevis finns det för att det fungerar, hur man förstår att man har en praktik och inte bara en installerad Jenkins.

Tanken att hålla en föreläsning om Continuous Integration kom för ett år sedan när jag var på intervjuer och sökte jobb. Jag pratade med 10-15 företag, och av dem var det bara ett som kunde förklara vad CI var och hur de insåg att de inte hade det. De andra pratade nonsens om Jenkins 🙂 'Tja, vi har Jenkins, den gör byggen, CI!' I min föreläsning kommer jag att försöka förklara vad Continuous Integration egentligen är och varför Jenkins och liknande verktyg har mycket lite att göra med det.

Så, vad kommer vanligtvis att tänka på när man hör ordet CI? För de flesta kommer ord som Jenkins, Gitlab CI, Travis osv. att dyka upp.

Även om vi googlar kommer dessa verktyg att dyka upp bland resultaten.

Om du frågar bekanta kommer de direkt efter uppräkningen av verktyg att berätta att CI är när du har en byggprocess och tester som körs på varje pull request.

Continuous Integration handlar inte om verktyg, inte om byggen med tester i en gren! Continuous Integration är en praktik av mycket frekvent integration av ny kod, och för dess tillämpning är det inte alls nödvändigt att bygga Jenkins, GitLab och så vidare.

Innan vi går igenom hur en komplett CI ser ut, låt oss först dyka ner i kontexten av de människor som kom på detta, och känna den smärta de försökte lösa.

Och den smärtan de försökte lösa var den gemensamma arbetsprocessen i teamet!

Låt oss titta på exempel på vilka svårigheter utvecklare stöter på vid lagarbete. Här har vi ett projekt, master-grenen i git och två utvecklare.

Och de började arbeta som alla länge har vant sig vid. De tog en uppgift i JIRA, skapade en feature branch och började skriva kod.

En avslutade funktionen snabbare och slog samman sin kod med master.

Den andra tog längre tid, han slog samman senare och fick en konflikt. Nu, istället för att skriva de funktionskrav som verksamheten behöver, spenderar utvecklaren tid och energi på att lösa konflikter.

Ju mer komplicerat det är att integrera din funktion med huvudgrenen, desto mer tid spenderar vi på det. Och detta är fortfarande ett ganska enkelt exempel jag har visat. Det här är ett exempel där det bara är två utvecklare. Tänk er om 10, 15 eller 100 personer i företaget skriver i ett och samma repository. Ni skulle bli galna av att lösa alla dessa konflikter.

Det finns en något annorlunda situation. Vi har en huvudgren och flera utvecklare som gör något.

De har skapat en gren vardera.

En har fört samman sin gren, allt gick bra, uppgiften är klar.

Under tiden har den andra utvecklaren slutfört sin uppgift. Låt oss säga att han har skickat den för granskning. I många företag finns det en praxis – granskning. Å ena sidan är denna praxis bra och användbar, å andra sidan bromsar den oss på många sätt. Låt oss inte gå in på det nu, men här är ett utmärkt exempel på vad en snedvriden granskning kan leda till. Du har skickat en pull request för granskning. Utvecklaren har inget mer att göra. Vad börjar han göra? Han börjar ta andra uppgifter.

Under denna tid har den andra utvecklaren även arbetat med något annat.

Den första slutförde den tredje uppgiften.

Och efter en längre tid har han fått sin granskning godkänd och försöker föra samman sina ändringar. Och vad händer? Han fångar en mängd konflikter. Varför? För medan hans pull request hängde på granskning har det skett många förändringar i koden.

Förutom historia med konflikter finns det också kommunikationsproblem. Så länge din gren hänger på granskning, så länge den väntar, så länge du arbetar länge med en funktion, slutar du att hålla koll på vad som förändras i kodbasen av din tjänst. Kanske det du försöker lösa nu redan löstes igår och att du kan återanvända en metod. Men du ser inte det, eftersom du alltid arbetar med en föråldrad gren. Denna föråldrade gren leder alltid till att du måste lösa merge-konflikter.

Det visar sig att om vi arbetar som ett team, alltså inte bara en person som arbetar i repositoryn, utan 5-10 personer, desto längre vi väntar med att lägga till vår kod i huvudgrenen, desto mer lider vi av att vi till slut måste föra ihop något. Och ju fler konflikter vi har, och ju äldre version vi arbetar med, desto fler problem får vi.

Att samarbeta är smärtsamt! Vi stör alltid varandra.

Det här problemet uppmärksammades för mer än 20 år sedan. Den första omnämnandet av praktiken Continuous Integration hittade jag inom extrem programmering.

Extrem programmering är den första agile-ramverket. Sidan skapades 1996. Tanken var att använda vissa programmerings-, planerings- och andra metoder för att utvecklingen skulle vara så flexibel som möjligt så vi snabbare skulle kunna reagera på förändringar och krav från våra kunder. För 24 år sedan mötte de problemet att om man arbetar länge i sidled, så slösar man mer tid på det, eftersom man får konflikter.

Nu kommer vi att bryta ner frasen "Continuous Integration" ord för ord. Om vi översätter bokstavligt får vi "kontinuerlig integration". Men hur kontinuerlig den är, är inte riktigt tydligt, den är faktiskt ganska intermittent. Hur mycket den är integration är inte heller helt uppenbart.

Därför ger jag er nu citat från extrem programmering. Och vi kommer att bryta ner båda orden separat.

Integration - Som jag redan nämnt strävar vi efter att varje ingenjör arbetar med den mest aktuella versionen av koden, så att de strävar efter att ofta lägga till sin kod i den gemensamma grenen, så att det handlar om små grenar. För om de är stora kan vi lätt fastna med merge-konflikter i en vecka. Särskilt om vi har en lång utvecklingscykel som vattenfall, där en utvecklare har spenderat en månad på att bygga en stor funktion. Och vid integrationssteget kan han fastna väldigt länge.

Integration – det är när vi tar vår gren och integrerar den med master, vi merge:ar den. Det finns en ultimativ variant där vi transbase developer, där vi strävar efter att vi skriver direkt till master utan några onödiga grenar.

I allmänhet är integration att ta sin kod och få den till master.

Vad menas med ordet «continuous» och vad är kontinuitet? Praktiken innebär att utvecklaren strävar efter att integrera sin kod så snabbt som möjligt. Det är hans mål när han utför en uppgift – att få sin kod in i huvudgrenen så snart som möjligt. I en perfekt värld skulle utvecklare göra detta var några timmar. Det vill säga, du tar en liten uppgift, mergar den i huvudgrenen. Allt är fantastiskt. Du strävar efter detta. Och det måste göras kontinuerligt. Så snart du har gjort något, lägger du genast in det i huvudgrenen.

Och utvecklaren som gör något är ansvarig för vad han har gjort för att det ska fungera och inte bryta något. Här dyker vanligtvis historien om tester upp. Vi vill köra några tester på vårt kommits, på vår merge, för att säkerställa att det fungerar. Och här kan Jenkins hjälpa dig.

Men när det handlar om: varför inte göra ändringarna små, och varför inte göra uppgifterna små, och varför inte göra uppgiften och försöka mergea den i huvudgrenen direkt – här hjälper inga Jenkins. För Jenkins hjälper er enbart att köra tester.

Du kan klara dig utan dem. Det stör dig inte alls. För målet med praktiken är att mergea så ofta som möjligt för att inte spendera en stor mängd tid på konflikter i framtiden.

Låt oss föreställa oss att vi har år 2020 utan internet av någon anledning. Och vi arbetar lokalt. Vi har ingen Jenkins. Det är okej. Du kan fortfarande skapa en lokal gren. Du har skrivit någon kod i den. Görde uppgiften på 3-4 timmar. Växla till huvudgrenen, kör git pull, merge din gren där. Klar. Om du gör detta ofta – grattis, du har Continuous Integration!

Vilka bevis finns det i den moderna världen för att det är värt att lägga kraft på detta? För det är i grunden svårt. Om du försöker arbeta på detta sätt, kommer du att märka att du måste planera mer, du måste ägna mer tid åt nedbrytning av uppgifter. För om du gör man..., så kommer du inte att kunna mergea snabbt och därmed hamna i knipa. Du kommer inte att ha något praktiskt.

Och det kommer att bli dyrt. Att börja arbeta med Continuous Integration från och med imorgon kommer inte att fungera. Ni kommer alla att behöva mycket tid för att vänja er vid detta, ni kommer att behöva lång tid för att vänja er vid att dela upp uppgifter, ni kommer att behöva lång tid för att justera er granskning, om ni har en sådan. För vår målsättning är att det ska slås samman idag. Om ni gör er granskning under tre dagar, då har ni problem och Continuous Integration fungerar inte.

Men vilka aktuella bevis har vi just nu som säger oss att det är meningsfullt att investera i denna praktik?

Det första som kom till mitt sinne var State of DevOps. Det är en studie som grabbarna har genomfört i 7 år. Just nu gör de det som en oberoende organisation, men under Google.

Deras studie från 2018 visade en korrelation mellan företag som strävar efter att använda kortvariga grenar, som integreras snabbt och ofta, och deras IT-prestanda är mycket bättre.

Vilka är dessa mätvärden? Det handlar om 4 mätvärden som de samlar in från alla företag i sina enkäter: deployment frequency, lead time for changes, time to restore service, change failure rate.

För det första finns det denna korrelation; vi vet att företag som slår samman ofta har betydligt bättre dessa mätvärden. De delar även in företag i flera kategorier: långsamma företag som producerar något långsamt, medium performer, high performer och eliten. Eliten – det är Netflix, Amazon, som är super snabba, gör allt snabbt, snyggt och av hög kvalitet.

En annan story som inträffade för bara en månad sedan. I Technology Radar publicerades en fantastisk notis om Gitflow. Gitflow skiljer sig från alla andra genom att dess grenar lever länge. Det finns release-grenar som lever länge, och feature branches som också lever länge. Denna praktik i Technology Radar har flyttats till HOLD. Varför? Eftersom folk stöter på problem med integrationen.

Om din gren lever mycket länge, börjar den fastna, den går ut på datum, och vi börjar slösa mer tid på att göra förändringar i den.

Nyligen sa författaren till Gitflow att om du strävar efter kontinuerlig integration, om du vill rulla ut förändringar så ofta som möjligt, då är Gitflow en dålig idé. I en artikel nämnde han att om ni har en backend där ni kan sträva efter detta, så är Gitflow överflödigt för er, eftersom Gitflow kommer att sakta ner er och skapa problem med integrationen.

Det betyder inte att Gitflow är dåligt och att man inte ska använda det. Det är för andra situationer. Till exempel när ni behöver underhålla flera versioner av en tjänst eller applikation, det vill säga där ni måste stödja den under en längre tid.

Men om ni pratar med personer som underhåller sådana tjänster, så kommer ni höra mycket klagomål om att versionen 3.2, som var för fyra månader sedan, inte fick med sig en fix och nu, för att få in den, måste man göra en massa förändringar. Så de sitter fast igen och kämpar i en vecka för att få in en ny funktion.

Som Alexander Kovalev korrekt påpekade i chatten, korrelation är inte detsamma som orsakssamband. Så är det. Det finns ingen direkt relation som innebär att om ni har kontinuerlig integration, så kommer alla mätvärden att vara fantastiska, nej. Men det finns en positiv korrelation, det vill säga om det ena finns, då är det troligt att det andra också finns. Det är inte ett faktum, men troligt. Det är bara en korrelation.

Det verkar som att vi redan gör något, vi mergear redan, men hur kan vi förstå att vi faktiskt har kontinuerlig integration, att vi mergear tillräckligt ofta?

Jez Humble är författare till Handbook, Accelerate, webbplatsen för Continuous Delivery och boken "Continuous Delivery". Han föreslår ett sådant test:

• Ingenjörens kod går in i master varje dag.
• Vid varje commit kör ni enhetstester.
• Bygget i master föll, men det åtgärdades på cirka 10 minuter.

Han föreslår att använda ett sådant test för att säkerställa att ni verkligen har de rätta praxis.

Det sista finner jag en aning kontroversiellt. Det vill säga, om du kan lösa det på 10 minuter, betyder det att du har Continuous Integration, vilket låter lite konstigt i mina öron, men det finns logik i det. Varför? Eftersom om du ofta slår samman, betyder det att dina förändringar är små. Om ett litet förändring orsakar att din huvudversion bryts, kan du snabbt finna exemplet eftersom förändringen är liten. Du hade en liten sammanslagning där 20–30 rader ändrades. Och du kan snabbt förstå vad som var orsaken, eftersom förändringarna är så små, vilket ger en mycket liten sökområde för problemet.

Och även om vi efter release får ett problem i produktion, så om vi har en praxis för Continuous Integration, är det mycket enklare för oss att agera, eftersom förändringarna är små. Ja, det kommer att påverka planeringen. Det kommer att vara smärtsamt. Och kanske det svåraste med denna praxis är att vänja sig vid att bryta ner uppgifter, alltså hur man kan ta något och göra det på några timmar och också klara av en granskning, om du har en. Granskning är en separat smärta.

Enhetstester är bara en hjälpare som hjälper dig att förstå – har din integration verkligen lyckats? Har ingenting gått sönder? Enligt min mening är det också inte ett helt obligatoriskt moment, eftersom syftet med praktiken inte ligger där.

Det här är en kort sammanfattning av Continuous Integration. Det är allt som finns i denna praxis. Jag är redo för frågor.

Kort sammanfattar jag bara en gång till:

• Continuous Integration är inte Jenkins, det är inte Gitlab.
• Det är inte ett verktyg, det är en praxis om att vi så ofta som möjligt slår samman vår kod i huvudversionen.
• Vi gör detta för att undvika den enorma smärta som uppstår med sammanslagningar i framtiden, det vill säga att vi upplever lite smärta nu för att inte behöva uppleva mycket mer i framtiden. Det är hela syftet.
• Åt sidan går kommunikationen genom koden, men jag ser det väldigt sällan, men det var också tänkt på det.

Frågor

Vad ska man göra med odekoflicerade uppgifter?

Dekoflicera. Vad är problemet? Kan du ge ett exempel på en uppgift som inte kan dekofliceras?

Det finns sådana uppgifter som inte kan dekofliceras överhuvudtaget, till exempel de som kräver mycket djup expertis och som verkligen kan ta en månad för att nå något rimligt resultat.

Om jag förstått dig rätt, så finns det en stor och komplex uppgift vars resultat först kommer att synas om en månad?

Ja, det stämmer. Ja, resultatet kan inte utvärderas tidigare än om en månad.

Okej. I stort sett är det inget problem. Varför? För i det här fallet, när vi pratar om grenar, pratar vi inte om en gren med en funktion. Funktioner kan vara stora och komplexa. De kan involvera många komponenter. Och det är möjligt att vi inte kan göra dem helt i en gren. Det är okej. Vi behöver bara dela upp den här historien. Om funktionen inte är helt färdig betyder det inte att delar av dess kod inte kan slås samman. Du har till exempel lagt till en migration och inom funktionen finns det några steg. Du har till exempel ett steg - att göra migrationen, lägga till en ny metod. Och dessa saker kan du redan slå samman dagligen.

Okej. Vad är då meningen med det här?

Vad är meningen med att slå samman små saker dagligen?

Ja.

Om de har brutit något ser du det genast. Du har en liten bit som brutit något, det är lättare att fixa. Meningen är att slå samman en liten bit nu är mycket enklare än att slå samman något stort om några veckor. Och den tredje meningen är att andra ingenjörer kommer att arbeta med den aktuella versionen av koden. De kommer att se att det har lagts till migrationer här och att det har dykt upp en metod här som de också kanske vill använda. Alla kommer att se vad som händer i din kod. Just för dessa tre saker utförs praktiken.

Tack, frågan är besvarad!

(Oleg Soroka) Kan jag få lägga till något? Du sa helt rätt, jag vill bara lägga till en fras.

Okej.

Vid kontinuerlig integration slås koden samman i den gemensamma grenen inte när funktionen är helt färdig, utan när bygget har slutat att krascha. Och ni kan fritt committa till master hur många gånger ni vill per dag. Den andra aspekten är att om ni av någon anledning inte kan dela upp en månadsuppgift i uppgifter på åtminstone tre dagar, jag nämner inte tre timmar, så har ni ett enormt problem. Och att ni inte har kontinuerlig integration är det minsta av dessa problem. Det betyder att ni har problem med arkitekturen och att de tekniska metoderna ligger på noll. För även om det handlar om forskning måste det i alla fall formuleras i form av hypoteser eller cykler.

Vi har pratat om 4 mätvärden som skiljer framgångsrika företag från de mindre framgångsrika. Det krävs att dessa 4 mätvärden faktiskt uppnås. Om ditt genomsnittliga uppdrag tar en månad skulle jag först fokusera på detta mätvärde. Jag skulle först få ner det till 3 dagar. Efter detta skulle jag börja tänka på Continuous.

Förstår jag dig rätt att du tycker att det i allmänhet inte är meningsfullt att investera i ingenjörsmetoder om du har en uppgift som tar en månad?

Du har Continuous Integration. Där finns det en situation där du inom 10 minuter antingen fixar en lösning eller rullar tillbaka. Tänk dig att du har släppt det. Och du har till och med continuous deployment, du har släppt det på prod och först efteråt märker du att något gick fel. Du måste rulla tillbaka, men din databas har redan migrerat. Din databas-schema har redan versionen för nästa, dessutom har det redan gjorts någon backup och där har även data skrivits in.

Och vad har du som alternativ? Om du rullar tillbaka koden kan den redan inte fungera med den uppdaterade databasen.

Databasen rör sig bara framåt, ja.

För personer med dåliga ingenjörspraktiker har de troligen inte läst den tjocka boken om ... heller. Vad gör man med backup? Om du återställer från en backup betyder det att du förlorar data som har samlats in under den tiden. Till exempel, arbetade du tre timmar med den nya versionen av databasen, där användare registrerade sig. Du går tillbaka till den gamla backupen eftersom schemat inte fungerar med den nya versionen, och därmed har du förlorat dessa användare. Och de är missnöjda, de klagar.

För att behärska hela spektrumet av metoder som stöder Continuous Integration och Continuous Delivery räcker det inte att bara lära sig att skriva …. För det första kan de bli väldigt många, och det blir opraktiskt. Dessutom finns det en massa andra metoder, som Scientific. Det finns en metod som GitHub populariserade en gång i tiden. Det är när du har både gammal och ny kod som körs samtidigt. Det är när du gör en ofullständig funktion, men den kan returnera något: antingen som en funktion eller som ett Rest API. Du kör både ny och gammal kod och jämför skillnaden mellan dem. Och om det finns en skillnad så loggar du det händelsen. På så sätt vet du att din nya funktion är redo att rullas ut över den gamla, om det under en viss tid inte har funnits någon avvikelse mellan dessa två.

Det finns hundratals sådana metoder. Jag skulle föreslå att börja med transbase development. Den är inte 100 % på Continuous Integration, men metoderna är desamma, det ena kan inte utan det andra.

Du nämnde transbase development som exempel på var man kan se metoder, eller föreslår du att folk ska börja använda transbase development?

Titta, eftersom de inte kan använda det. För att kunna använda dem måste man läsa mycket. Och när en person frågar: "Vad ska jag göra med en funktion som tar en månad?" betyder det att han inte har läst om transbase development. Jag skulle inte rekommendera det ännu. Jag skulle råda att fokusera enbart på hur man korrekt arkitektoniskt delar stora uppgifter i mindre. Det är själva syftet med dekomposition.

Dekomposition är ett av verktygen för arkitekten. Först gör vi en analys, sedan dekomposition, sedan syntes, och slutligen integration. På så sätt faller allt på plats. Och för att nå Continuous Integration måste man först växa genom dekomposition. Frågor uppstår i det första steget, men vi pratar redan om det fjärde steget, det vill säga ju oftare man gör integration, desto bättre. Det är fortfarande för tidigt att göra det, det skulle vara bra att först dela upp sin monolit.

Det behövs några pilar och kvadrater ritade på någon slags schema. Du kan inte säga att nu ska jag visa arkitektschemat för den nya applikationen och bara visa en kvadrat, inne i vilken det finns en grön knapp för applikationen. I vilket fall som helst kommer det att finnas fler kvadrater och pilar. På vilket schema jag än har sett, har de alltid varit fler än en. Och dekomposition görs redan på grafisk representationsnivå. Därför kan kvadraterna göras oberoende. Om inte, så har jag stora frågor till arkitekten.

Det finns en fråga från chatten: "Om en granskning är obligatorisk och pågår länge, någon dag eller mer?".

Ni har problem med praktiken. En granskning ska inte ta en dag eller mer. Det är samma historia som den föregående frågan, bara lite mjukare. Om en granskning tar en dag, betyder det förmodligen att det handlar om en väldigt stor förändring. Då borde man göra den mindre. I transbase development, som Oleg rekommenderade, finns det en grej som kallas continuous review. Idén är att vi medvetet gör så små pull requests som möjligt, eftersom vi strävar efter att mergen konstant och i små mängder. Därför förändrar en pull request en abstraktion eller 10 rader. Tack vare detta tar granskningen bara några minuter.

Om en granskning tar en dag eller mer, då är något fel. För det första kan det finnas problem med arkitekturen. Antingen är det en stor kodbit, på exempelvis 1 000 rader. Eller så har ni en så komplex arkitektur att en person inte kan förstå den. Det är ett problem, men det måste också lösas. Kanske behövs det överhuvudtaget ingen granskning. Det är något man också behöver fundera på. Granskning är det som bromsar er. Den ger sina fördelar i allmänhet, men ni behöver förstå varför ni gör detta. Är det ett sätt för er att snabbt överföra information, är det ett sätt att etablera vissa standarder internt eller vad? Varför behöver ni detta? För granskning måste antingen vara väldigt snabb, eller så ska den helt avbrytas. Det är som transbase development – en mycket vacker historia, men bara för mogna personer.

Angående de fyra metrikorna skulle jag rekommendera att ni faktiskt tar bort dem för att förstå vad det leder till. Titta på siffrorna, titta på bilden, hur dåligt allt ser ut.

(Dmitrij) Jag är redo att delta i diskussionen om detta med dig. Siffror och mätningar är allt bra, praktiken är bra. Men vi måste förstå – är detta nödvändigt för affären? Det finns företag som inte behöver en sådan snabba förändringar. Jag känner till företag där man inte kan göra ändringar var 15:e minut. Och inte för att de är dåliga. Det är en sådan livscykel. Och för att göra funktioner som branches, toggle-funktioner, krävs djupa kunskaper.

Det är svårt. Om du vill läsa mer om historien kring toggle-funktioner, rekommenderar jag verkligen detta. https://trunkbaseddevelopment.com/. Och det finns en fantastisk artikel av Martin Fowler om toggle-funktioner: om vilka typer som finns, livscykler, osv. Toggle-funktionen är komplex.

Och du svarade ändå inte på frågan: "Behövs Jenkins eller inte?"

Jenkins behövs egentligen inte i något fall. Om jag ska vara ärlig, så ger verktyg som Jenkins, Gitlab dig bekvämlighet. Du kommer att se om bygget lyckades eller inte. De kan hjälpa dig, men de ger dig inte praktiken. De kan bara ge dig en indikator – Okej, inte okej. Och såvida du skriver tester, för annars är det nästan meningslöst. Så det behövs, för att – det är bekvämare, men i stort sett kan man klara sig utan det, man förlorar inte mycket.

Det vill säga, om du har praxis, så behövs det inte?

Helt korrekt. Jag rekommenderar testet av Jez Humble. Jag har en blandad känsla angående den sista punkten. Men generellt, om du har tre saker; du slår samman konstant, du kör tester på commits i master, och fixar bygget snabbt i master, då kanske du inte behöver något mer.

Medan vi väntar på frågor från deltagarna, har jag en fråga. Vi har nu pratat om produktkod. Har du använt det för infrastrukturkod? Är det samma slags kod, med samma principer och livscykel, eller finns det andra livscykler och principer? Vanligtvis när alla pratar om Continuous Integration och Development, glömmer man att det också finns infrastrukturkod. Och på senaste tiden har det ökat mer och mer. Bör vi föra in alla dessa regler där?

Det handlar inte bara om att det bör göras, det skulle vara fantastiskt, eftersom det verkligen skulle förenkla livet. Så fort vi arbetar med kod, inte med bash-skript, utan vi har normal kod.

Stopp-stop, bash-skript är också kod. Rör inte min gamla kärlek.

Bra, jag ska inte trampa på dina minnen. Jag har en personlig aversion mot bash. Det kraschar på ett fult och skrämmande sätt hela tiden. Och det kraschar ofta oförutsägbart, så jag gillar det inte. Men okej, låt oss säga att du har kod i bash. Kanske har jag verkligen ingen aning, och det finns bra testframeworks där. Jag är bara inte insatt. Och vi får samma fördelar.

När vi väl hanterar infrastruktur som kod får vi alla samma problem som utvecklare. För några månader sedan stötte jag på en situation där en kollega skickade en pull request på 1 000 rader bash. Och du fastnar på granskningen i 4 timmar. Problemen är desamma. Det är fortfarande kod. Och fortfarande samarbete. Vi fastnar med pull requests och vi fastnar med att reda ut samma sammanslagningskonflikter i bash, till exempel.

Just nu tittar jag väldigt aktivt på allt detta med att programmera infrastrukturen på det mest eleganta sättet. Jag har just integrerat Pulumi i infrastrukturen. Det är ren programmering. Där är det ännu mer tilltalande, eftersom jag har alla språkets möjligheter, dvs. jag gjorde snygga toggles med samma if-satser mitt på plan. Så mitt förändring finns redan i master. Alla kan se det. Andra ingenjörer är medvetna om det. Det har redan påverkat något. Men det har inte aktiverats för alla infrastrukturer. Det har aktiverats för mina testmiljöer, till exempel. Så för att svara på din fråga igen, det behövs. Det förenklar verkligen livet för oss ingenjörer som arbetar med kod.

Är det några fler frågor?

Jag har en fråga. Jag vill fortsätta diskussionen med Oleg. Generellt sett tycker jag att du har rätt; om en uppgift tar en månad att göra, så har du problem med arkitekturen, du har problem med analys, dekonstruktion, planering, osv. Men jag har en känsla av att om du börjar försöka leva efter Continuous Integration, så kommer du att börja åtgärda smärtorna med planeringen, för du kan inte undkomma det.

(Oleg) Ja, så är det. Denna praktik är jämförbar i arbetsinsats med andra allvarliga metoder som förändrar kulturen. Det svåraste att övervinna är vanor, särskilt dåliga vanor. Och om det krävs en betydande förändring av vanorna hos de runt omkring: utvecklare, ledning, produktionschef, då kan ni förvänta er överraskningar.

Vilka överraskningar kan det vara? Låt oss säga att du bestämmer att du ska göra integration oftare. Och under integrationen är det anslutna saker, till exempel artefakter. I ditt företag finns det en policy att varje artefakt måste registreras på något sätt i ett system för lagring av artefakter. Och det tar en viss tid. En person måste checka av att han, som release manager, har testat denna artefakt för att den är redo för produktion. Om det tar 5-10-15 minuter, men du gör utrullningar en gång i veckan, då innebär det att du en gång i veckan spenderar en halvtimme – en liten skatt.

Om du gör Continuous Integration 10 gånger om dagen, så behöver du multiplicera 10 gånger med 30 minuter. Och det överskrider arbetsvolymen för denna release manager. Han blir helt enkelt trött på det. Det finns ständiga kostnader för vissa metoder. Och så är det.

Och du måste antingen avskaffa denna regel så att du inte sysslar med sådant nonsens, dvs. att du inte manuellt bedömer överensstämmelse mellan något och något. Du litar helt och hållet på en automatiserad uppsättning tester för beredskap.

Och om du behöver en bekräftelse från någon, så att chefen godkänner, och du inte rör vid produktionen utan att Vasja säger att det är okej, o.s.v. – allt detta står i vägen för metoder. För om det finns relaterade aktiviteter som en sorts skatt, så ökar allt hundrafaldigt. Därför kommer förändringen ofta inte att välkomnas av alla. Eftersom det är svårt att ändra människors vanor.

När en person utför sitt vanliga arbete gör han det nästan utan att tänka. Den kognitiva belastningen är nära noll. Han strävar framåt med det som redan är färdigt, han har en checklista i huvudet, han har gjort det tusen gånger. Och så fort du kommer och säger till honom: "Låt oss avskaffa denna praktik och införa en ny från måndag" blir det en betydande kognitiv belastning för honom. Den inträffar dessutom för alla på en gång.

Därför är det enklaste, även om denna lyx inte alla har råd med, något jag alltid gör. Det är följande: När ett nytt projekt startar, trycks ofta alla oprövade metoder in i det projektet. Så länge projektet är ungt riskerar vi inte mycket. Det finns ingen produktion än, det går inte att förstöra något. Därför kan det användas som träning. Denna metod fungerar. Men inte alla företag har möjlighet att ofta starta sådana projekt. Även om det är lite konstigt, eftersom det pågår en digital transformation överallt, alla borde experimentera för att hänga med konkurrenterna.

Här stöter du på det faktum att du måste ha en förståelse för vad du behöver göra från början. Världen är inte perfekt, och produktionen är inte perfekt heller.

Ja, dessa saker är kopplade till varandra.

Företag har inte alltid en förståelse för att de måste gå just dit.

Det finns situationer där inga förändringar är möjliga överhuvudtaget. Det är en situation där större press läggs på teamet. Teamet är redan ganska utbränt. Det har ingen tid kvar för några experiment. De jobbar hela dagen med funktioner. Och ledningen är alltid otillfredsställd med funktionerna. Det krävs mer och mer. I en sådan situation är inga förändringar möjliga. Teamet kan endast få veta att imorgon ska vi göra som vi gjorde igår, bara att vi behöver leverera lite fler funktioner. Inga övergångar till några metoder är därför möjliga. Det är en klassisk situation där det inte finns tid att slipa en yxa, man måste hugga ner träd, så man hugger med en trubbig yxa. Här finns det inga enkla råd.

(Dmitrij) Jag läser upp en klargörande kommentar från chatten: "Men det behövs ett stort testtäcke på olika nivåer. Hur mycket tid ägnas åt tester? Det verkar ganska dyrt, det tar mycket tid."

(Oleg) Det här är en klassisk missuppfattning. Det borde finnas tillräckligt med tester så att ni själva har förtroende. Continuous Integration är inte en sådan sak där 100 % av testerna körs först och sedan börjar ni använda denna praxis. Continuous Integration minskar den kognitiva belastningen genom att varje förändring ni ser med blotta ögat är så uppenbar att ni förstår – om den bryter något eller inte, även utan tester. Ni kan snabbt testa detta i huvudet, eftersom förändringarna är små. Även om ni endast har manuella testare är det enklare för dem också. Ni släpper en uppdatering och säger: "Kolla, har något gått sönder?". De kontrollerar och säger: "Nej, inget har gått sönder". Eftersom testaren vet var de ska titta. Ni har en commit kopplad till ett specifikt kodstycke. Och det exponerar ett konkret beteende.

Här har du, förstås, överdrivit.

(Dmitry) Här håller jag inte med. Det finns en praxis – testdriven utveckling som faktiskt kommer att rädda oss från detta.

(Oleg) Ja, jag har inte kommit så långt än. Den första illusionen är att man måste skriva 100 % tester eller inte alls syssla med Continuous Integration. Det är en lögn. Det här är två parallella praktiker. Och de är inte direkt beroende av varandra. Ert testtäcke bör vara optimalt. Optimalt betyder att ni själva är säkra på att den kvalitet av huvudkoden som kvarstår efter er commit tillåter er att trycka på knappen "Deploy" på fredag kväll, även om ni är berusade. Hur uppnår ni detta? Genom granskningar, genom täckning, genom bra övervakning.

Bra övervakning är inte skillnad från tester. Om ni kör tester en gång på pre-prod, så kontrollerar de era användarscenarier en gång och så enkelt är det. Men om ni kör dem i en oändlig slinga, då är det ert utbyggda övervakningssystem som testar allt oändligt – om det har kraschat eller inte. I detta fall är skillnaden bara i engångs- eller flergångskörning. En mycket bra uppsättning tester..., som körs oändligt, är övervakning. Och korrekt övervakning bör vara så.

Och därför, hur ni exakt ska nå detta tillstånd där ni kan deploya på fredag kväll och gå hem är en annan fråga. Kanske är ni helt enkelt en modig idiot.

Låt oss gå tillbaka lite till Continuous Integration. Vi har avvikit något till en annan komplex praktik.

Och den andra illusionen är att MVP sägs vara något man måste göra snabbt, så tester behövs överhuvudtaget inte. Det är inte riktigt så. Faktum är att när du skriver en user story i MVP, så kan du utveckla den antingen helt på måfå, dvs. du hör att det finns en viss user story och springer direkt för att koda den, eller arbeta enligt TDD. Och enligt TDD, som erfarenheten visar, tar det inte längre tid, dvs. tester är en bieffekt. TDD-praktiken handlar inte om att testa. Trots namnet Test Driven Development handlar det överhuvudtaget inte om tester. Det är mer en arkitekturmetod. Det handlar om att skriva det som verkligen behövs och inte skriva det som inte behövs. Denna praktik fokuserar på nästa iteration av dina tankar när det gäller att skapa applikationens arkitektur.

Så det är inte så enkelt att bli av med dessa illusioner. MVP och tester motsäger inte varandra. Snarare tvärtom, om du gör MVP enligt TDD-praktiken, kommer du att göra det bättre och snabbare än om du gör det helt utan praktik och på måfå.

Det är en väldigt otydlig och komplex tanke. När du hör att nu ska jag skriva ytterligare tester och samtidigt kommer jag att göra något snabbare, låter det helt orealistiskt.

(Dmitrij) Många när de pratar om MVP, det är bara för att folk är för lata för att skriva något bra. Och det är verkligen två olika saker. Man bör inte förvandla MVP till något dåligt som inte fungerar.

Ja, du har rätt.

Och plötsligt är MVP i produktion.

För alltid.

Och TDD låter väldigt ovanligt när man hör att du skriver tester och verkar göra mer arbete. Det låter väldigt konstigt, men faktiskt gör det att det går snabbare och ser bättre ut. När du skriver ett test tänker du redan mycket på vilken kod och hur den kommer att kallas, samt vilket beteende vi förväntar oss av den. Du säger inte bara att jag har skrivit en funktion och den gör något. Du tänker först på att den har vissa villkor, den kommer att kallas på ett visst sätt. Du täcker det med tester och från det förstår du hur dina gränssnitt i din kod kommer att se ut. Det påverkar verkligen arkitekturen. Din kod blir automatiskt mer modulär, eftersom du först försöker förstå hur du kommer att testa den, och först därefter skriver du den.

Jag hade det så med TDD att jag vid ett tillfälle anlitade en mentor i Ruby när jag fortfarande var Ruby-programmerare. Och han sa: "Låt oss göra det med TDD." Jag tänkte: "Åh nej, jag måste skriva något extra nu." Vi kom överens om att jag skulle skriva all fungerande kod på Python med TDD under två veckor. Efter två veckor insåg jag att jag aldrig ville gå tillbaka. Genom att försöka tillämpa det överallt under två veckor förstod jag hur mycket enklare det blev att tänka. Men det är inte uppenbart, så jag rekommenderar till alla att om ni känner att TDD är svårt, långsamt och överflödigt, försök att hålla på med det i två veckor. För mig räckte det med två.

(Dmitrij) Vi kan utveckla den här tanken utifrån infrastrukturen. Innan vi sätter igång något nytt gör vi en övervakning och därefter sätter vi igång. I det här fallet blir övervakningen ett normalt test. Och det finns utveckling genom övervakning. Men nästan alla säger att det tar lång tid, jag orkar inte, jag gjorde ett provisoriskt utkast. Om vi gör övervakningen ordentligt, förstår vi tillståndet för CI-systemet. I CI-systemet finns mycket övervakning. Vi förstår systemets tillstånd, vi vet vad som finns inuti. Under utvecklingen bygger vi just systemet så att det når det önskade tillståndet.

Dessa metoder har länge varit kända. Vi diskuterade dem för fyra år sedan. Men över fyra år har nästan ingenting förändrats.

Men på denna not vill jag avsluta den officiella diskussionen.

Video (infogad som medieelement, men av någon anledning fungerar det inte):

https://youtu.be/zZ3qXVN3Oic

Källa: habr.com