Lad os diskutere, hvorfor CI-værktøjer og CI er helt forskellige ting.
Hvilken smerte er CI beregnet til at løse, hvor kom ideen fra, hvad er de seneste bekræftelser på, at det virker, hvordan forstår man, at man har en praksis og ikke kun installeret Jenkins.
Ideen om at lave en reportage om Kontinuerlig Integration dukkede op for et år siden, da jeg skulle til samtaler og søge job. Jeg talte med 10-15 virksomheder, kun én af dem var i stand til klart at svare på, hvad CI er og forklare, hvordan de indså, at de ikke havde det. Resten snakkede uforståeligt sludder om Jenkins :) Nå, vi har Jenkins, den bygger, CI! I løbet af rapporten vil jeg forsøge at forklare, hvad Continuous Integration egentlig er, og hvorfor Jenkins og lignende værktøjer har et meget svagt forhold til dette.
Så hvad kommer der normalt til at tænke på, når du hører ordet CI? De fleste vil tænke på Jenkins, Gitlab CI, Travis osv.
Selvom vi googler det, vil det give os disse værktøjer.
Hvis du er bekendt med at spørge, vil de umiddelbart efter at have listet værktøjerne fortælle dig, at CI er, når du bygger og kører test i en Pull Request for en commit.
Kontinuerlig Integration handler ikke om værktøjer, ikke om samlinger med test i en branche! Kontinuerlig integration er praksis med meget hyppig integration af ny kode, og for at bruge den er det slet ikke nødvendigt at indhegne Jenkins, GitLab osv.
Før vi finder ud af, hvordan en fuldgyldig CI ser ud, lad os først dykke ned i konteksten for de mennesker, der fandt på det, og mærke den smerte, de forsøgte at løse.
Og de løste smerten ved at arbejde sammen som et team!
Lad os se på eksempler på de vanskeligheder, udviklere står over for, når de udvikler i teams. Her har vi et projekt, en mastergren i git og to udviklere.
Og de gik på arbejde, som alle længe havde været vant til. Vi tog en opgave i den store sammenhæng, oprettede en feature-gren og skrev koden.
Man færdiggjorde funktionen hurtigere og flettede den ind i masteren.
Den anden havde brug for mere tid, den smeltede senere sammen og endte med en konflikt. Nu, i stedet for at skrive de funktioner, virksomheden har brug for, bruger udvikleren sin tid og energi på at løse konflikter.
Jo sværere det er at kombinere dit indslag med en fælles mester, jo mere tid bruger vi på det. Og det viste jeg med et ret simpelt eksempel. Dette er et eksempel, hvor der kun er 2 udviklere. Forestil dig, hvis 10 eller 15 eller 100 personer i en virksomhed skriver til et lager. Du vil gå amok for at løse alle disse konflikter.
Der er en lidt anden sag. Vi har en mester og nogle udviklere, der gør noget.
De skabte en kvist.
En døde, alt var i orden, han klarede opgaven.
Den anden udvikler afleverede i mellemtiden sin opgave. Lad os sige, at han sendte den til gennemgang. Mange virksomheder har en praksis kaldet review. På den ene side er denne praksis god og brugbar, på den anden side bremser den os på mange måder. Det går vi ikke ind på, men her er et godt eksempel på, hvad en dårlig anmeldelseshistorie kan føre til. Du har indsendt en pull-anmodning til gennemgang. Der er ikke mere for udvikleren at gøre. Hvad begynder han at lave? Han begynder at påtage sig andre opgaver.
I løbet af denne tid gjorde den anden udvikler noget andet.
Den første fuldførte den tredje opgave.
Og efter noget lang tid blev hans anmeldelse testet, og han forsøger at komme overens. Så hvad sker der? Det fanger et stort antal konflikter. Hvorfor? For mens hans pull-anmodning hang i anmeldelsen, var mange ting allerede ændret i koden.
Ud over historien med konflikter er der en historie med kommunikation. Mens din tråd hænger på gennemgang, mens den venter på noget, mens du arbejder på en funktion i lang tid, holder du op med at spore, hvad der ellers ændrer sig i kodebasen for din tjeneste. Måske var det, du forsøger at løse nu, allerede løst i går, og du kan tage en metode og genbruge den. Men du vil ikke se dette, fordi du altid arbejder med en forældet filial. Og denne forældede gren resulterer altid i, at du skal løse en fusionskonflikt.
Det viser sig, at hvis vi arbejder som et team, det vil sige, at der ikke er én person, der roder rundt i depotet, men 5-10 personer, så jo længere vi ikke føjer vores kode til masteren, jo mere lider vi, fordi vi i sidste ende har brug for noget så flette det sammen. Og jo flere konflikter vi har, og jo ældre version vi arbejder med, jo flere problemer har vi.
At lave noget sammen er smertefuldt! Vi går altid i vejen for hinanden.
Dette problem blev bemærket for mere end 20 år siden. Jeg fandt den første omtale af praksis med kontinuerlig integration i ekstrem programmering.
Extreme Programming er det første agile framework. Siden dukkede op i 96. Og tanken var at bruge en eller anden form for programmeringspraksis, planlægning og andet, så udviklingen blev så fleksibel som muligt, så vi hurtigt kunne reagere på eventuelle ændringer eller krav fra vores kunder. Og de begyndte at se det i øjnene for 24 år siden, at hvis man laver noget i meget lang tid og på sidelinjen, så bruger man mere tid på det, fordi man har konflikter.
Nu vil vi analysere udtrykket "Kontinuerlig Integration" individuelt. Hvis vi oversætter det direkte, får vi kontinuerlig integration. Men hvor kontinuerlig det er, er ikke særlig klart; det er meget diskontinuerligt. Men hvor meget integration den har, er heller ikke særlig indlysende.
Og det er derfor, jeg giver dig citater fra Extreme Programming nu. Og vi vil analysere begge ord separat.
Integration - Som jeg allerede har sagt, stræber vi efter at sikre, at enhver ingeniør arbejder med den nyeste version af koden, så han bestræber sig på at tilføje sin kode så ofte som muligt til en fælles gren, så det er små grene. For hvis de er store, så kan vi sagtens hænge fast med fusionskonflikter i en uge. Dette gælder især, hvis vi har en lang udviklingscyklus såsom vandfald, hvor udvikleren gik væk i en måned for at skære en kæmpe funktion. Og han vil sidde fast på integrationsstadiet i meget lang tid.
Integration er, når vi tager vores gren og integrerer den med mesteren, så slår vi den sammen. Der er en ultimativ mulighed, når vi er en transbase-udvikler, hvor vi bestræber os på at sikre, at vi straks skriver til masteren uden ekstra forgreninger.
Generelt betyder integration at tage din kode og trække den ind i masteren.
Hvad menes her med ordet "kontinuerlig", hvad kaldes kontinuitet? Praksis indebærer, at udvikleren stræber efter at integrere sin kode så hurtigt som muligt. Dette er hans mål, når han udfører enhver opgave - at få sin kode i master så hurtigt som muligt. I en ideel verden ville udviklere gøre dette med få timers mellemrum. Det vil sige, at du tager et lille problem og flettes ind i masteren. Alt er fantastisk. Det er det, du stræber efter. Og det skal gøres løbende. Så snart du gør noget, sætter du det straks ind i masteren.
Og udvikleren, der laver noget, er ansvarlig for, hvad han gjorde for at få det til at fungere og ikke ødelægge noget. Det er her, testhistorien normalt kommer frem. Vi ønsker at køre nogle test af vores commit, på vores sammensmeltning, for at sikre, at det virker. Og det er her, Jenkins kan hjælpe dig.
Men med historier: lad os gøre ændringerne små, lad os lade opgaverne være små, lad os lave et problem og straks prøve på en eller anden måde at integrere det i masteren - ingen Jenkins vil hjælpe her. Fordi Jenkins kun hjælper dig med at køre tests.
Du kan undvære dem. Dette vil overhovedet ikke skade dig. Fordi målet med praksis er at fusionere så ofte som muligt, for ikke at spilde en enorm mængde tid på eventuelle konflikter i fremtiden.
Lad os forestille os, at vi af en eller anden grund er i 2020 uden internettet. Og vi arbejder lokalt. Vi har ikke Jenkins. Det er fint. Du kan stadig gå videre og oprette en lokal afdeling. Du skrev noget kode i den. Vi klarede opgaven på 3-4 timer. Vi skiftede til master, lavede et git pull og slog vores gren sammen der. Parat. Hvis du gør dette ofte, tillykke, har du Kontinuerlig Integration!
Hvilke beviser i den moderne verden er der på, at det er værd at bruge energi på? For generelt er det svært. Hvis du forsøger at arbejde sådan, vil du forstå, at noget planlægning nu vil blive påvirket, du bliver nødt til at bruge mere tid på at nedbryde opgaver. For hvis du gør det mand..., så vil du ikke være i stand til at komme overens hurtigt og vil følgelig komme i problemer. Du vil ikke længere have praksis.
Og det bliver dyrt. Det vil ikke være muligt at arbejde med det samme fra i morgen med Kontinuerlig Integration. Det vil tage jer alle meget lang tid at vænne jer til det, det vil tage jer meget lang tid at vænne jer til at nedbryde opgaver, det vil tage meget lang tid at vænne jer til at lave revisionspraksisen om, hvis I har en . For vores mål er, at det skal smelte i dag. Og hvis du laver en anmeldelse inden for tre dage, så har du problemer, og Kontinuerlig Integration virker ikke for dig.
Men har vi noget relevant bevis lige nu, der fortæller os, at det giver mening at investere i denne praksis?
Det første, der faldt mig ind, var State of DevOps. Dette er en undersøgelse, som fyrene har udført i 7 år. Nu gør de det som en selvstændig organisation, men under Google.
Og deres 2018-undersøgelse viste en sammenhæng mellem virksomheder, der forsøger at bruge kortlivede filialer, der integrerer hurtigt, integrerer ofte og har bedre it-præstationsindikatorer.
Hvad er disse indikatorer? Det er 4 målinger, som de tager fra alle virksomheder i deres spørgeskemaer: implementeringshyppighed, gennemløbstid for ændringer, tid til at genoprette service, ændringsfejlfrekvens.
Og for det første er der denne sammenhæng, vi ved, at virksomheder, der måler ofte, har meget bedre målinger. Og de har en opdeling af virksomheder i flere kategorier: Det er langsomme virksomheder, der producerer noget langsomt, medium performer, high performer og elite. Eliten er Netflix, Amazon, som er superhurtige, gør alt hurtigt, smukt og effektivt.
Den anden historie, der skete for blot en måned siden. Technology Radar har en fantastisk artikel om Gitflow. Gitflow er forskellig fra alle andre ved, at dens grene er langlivede. Der er udgivelsesgrene, der lever i lang tid, og trækgrene, der også lever i lang tid. Denne praksis på Technology Radar er flyttet til HOLD. Hvorfor? Fordi mennesker står over for smerten ved integration.
Hvis din gren lever i meget lang tid, sætter den sig fast, bliver rådden, og vi begynder at bruge mere tid på at forsøge at lave en form for ændring af den.
Og for nylig sagde forfatteren af Gitflow, at hvis dit mål er Kontinuerlig Integration, hvis dit mål er, at du vil rulle så ofte som muligt, så er Gitflow en dårlig idé. Han tilføjede separat til artiklen, at hvis du har en backend, hvor du kan stræbe efter dette, så er Gitflow overflødigt for dig, for Gitflow vil bremse dig, Gitflow vil skabe problemer for dig med integration.
Dette betyder ikke, at Gitflow er dårligt og ikke bør bruges. Det er til andre lejligheder. For eksempel når du skal understøtte flere versioner af en tjeneste eller applikation, altså hvor du har brug for support i en længere periode.
Men hvis du taler med folk, der understøtter sådanne tjenester, vil du høre en masse smerte om, at denne version var 3.2, hvilket var 4 måneder siden, men denne rettelse var ikke inkluderet i det, og nu, for at gøre det, du skal lave en masse ændringer. Og nu sidder de fast igen, og nu har de rodet rundt i en uge for at prøve at implementere en ny funktion.
Som Alexander Kovalev korrekt bemærkede i chatten, er korrelation ikke det samme som årsagssammenhæng. Det er rigtigt. Det vil sige, at der ikke er nogen direkte sammenhæng med, at hvis du har Continuous Integration, så vil alle målinger være gode. Men der er en positiv sammenhæng, at hvis den ene er den ene, så er den anden højst sandsynlig det også. Ikke et faktum, men højst sandsynligt. Det er bare en sammenhæng.
Det ser ud til, at vi allerede gør noget, det ser ud til, at vi allerede fusionerer, men hvordan kan vi forstå, at vi stadig har Kontinuerlig Integration, at vi fusionerer ret ofte?
Jez Humble er forfatter til Handbook, Accelerate, Continuous Delivery-webstedet og bogen Continuous Delivery. Han tilbyder denne test:
- Ingeniørens kode kommer til mesteren hver dag.
- For hver commit kører du enhedstests.
- Bygningen i masteren faldt, den blev rettet på cirka 10 minutter.
Han foreslår at bruge en test som denne for at sikre, at du har nok øvelse.
Jeg finder det sidste lidt kontroversielt. Det vil sige, hvis du kan ordne det på 10 minutter, så har du Continuous Integration, det lyder lidt mærkeligt, efter min mening, men det giver mening. Hvorfor? For hvis du fryser ofte, betyder det, at dine ændringer er små. Hvis en lille ændring betyder, at din master build er brudt, så kan du hurtigt finde et eksempel, fordi ændringen er lille. Her havde man en lille fletning, 20-30 linjer i den ændrede sig. Og derfor kan du hurtigt forstå, hvad årsagen var, fordi ændringerne er små, du har et meget lille område til at søge efter problemet.
Og selvom vores prod falder fra hinanden efter udgivelsen, så hvis vi har praksis med Kontinuerlig Integration, er det meget lettere for os at handle, fordi ændringerne er små. Ja, det vil påvirke planlægningen. Dette vil gøre ondt. Og nok, det sværeste i denne praksis er at vænne sig til at nedbryde opgaver, det vil sige hvordan man gør det, så man kan tage noget og gøre det på et par timer og samtidig bestå en anmeldelse, hvis du har en. Anmeldelse er en separat smerte.
Enhedstests er blot en assistent, der hjælper dig med at forstå, om din integration var vellykket, og om intet var brudt. Det er efter min mening heller ikke helt obligatorisk, for det er ikke meningen med praksis.
Dette er en kort introduktion til kontinuerlig integration. Det er alt, der er til denne praksis. Jeg er klar til spørgsmål.
Jeg vil lige opsummere kort igen:
- Kontinuerlig integration er ikke Jenkins, det er ikke Gitlab.
- Dette er ikke et værktøj, det er en praksis, at vi flette vores kode ind i masteren så ofte som muligt.
- Det gør vi for at undgå den enorme smerte, der opstår ved sammensmeltninger i fremtiden, det vil sige, at vi oplever lidt smerte nu for ikke at opleve mere i fremtiden. Det er hele pointen.
- På siden er der kommunikation gennem kode, men det ser jeg meget sjældent, men det er også det, det er designet til.
R'RѕRїSЂRѕSЃS <
Hvad skal man gøre med ikke-nedbrudte opgaver?
Nedbrydes. Hvad er problemet? Kan du give et eksempel på, at der er en opgave, og den ikke er nedbrudt?
Der er opgaver, der ikke kan nedbrydes fra ordet "helt", for eksempel dem, der kræver meget dyb ekspertise, og som faktisk kan løses i løbet af en måned for at opnå et eller andet fordøjeligt resultat.
Hvis jeg forstår dig rigtigt, så er der en stor og kompleks opgave, hvis resultat først vil være synlig om en måned?
Ja det er rigtigt. Ja, det vil være muligt at evaluere resultatet tidligst om en måned.
Bøde. Generelt er dette ikke et problem. Hvorfor? For i dette tilfælde, når vi taler om kviste, taler vi ikke om en kvist med et træk. Funktioner kan være store og komplekse. De kan påvirke et stort antal komponenter. Og måske kan vi ikke gøre dem helt i én gren. Det er fint. Vi skal bare bryde denne historie ned. Hvis en funktion ikke er helt klar, betyder det ikke, at nogle stykker af dens kode ikke kan flettes. Du tilføjede f.eks. migrering, og der er nogle stadier inde i funktionen. Lad os sige, at du har en fase - lav en migrering, tilføj en ny metode. Og du kan allerede måle disse ting hver dag.
Bøde. Hvad er meningen så?
Hvad er meningen med at slå små ting ihjel hver dag?
Ja.
Hvis de knækker noget, ser du det med det samme. Du har et lille stykke, der har ødelagt noget, det er nemmere for dig at reparere det. Pointen er, at det er meget nemmere at fusionere et lille stykke nu end at fusionere noget stort på et par uger. Og det tredje punkt er, at andre ingeniører vil arbejde med den aktuelle version af koden. De vil se, at der er tilføjet nogle migrationer her, og så er der dukket en eller anden metode op, som de måske også vil bruge. Alle vil se, hvad der sker i din kode. Det er for disse tre ting, der øves.
Tak, problemet er lukket!
(Oleg Soroka) Må jeg tilføje? Du sagde alt rigtigt, jeg vil bare tilføje en sætning.
So.
Med Continuous Integration flettes koden sammen til en fælles gren, ikke når funktionen er helt klar, men når build holder op med at gå i stykker. Og du kan roligt forpligte dig til at mestre så mange gange om dagen, som du vil. Det andet aspekt er, at hvis du af en eller anden grund ikke kan dele den månedlige opgave op i opgaver i mindst tre dage, jeg er tavs omkring tre timer, så har du et kæmpe problem. Og det faktum, at du ikke har Kontinuerlig Integration, er det mindste af disse problemer. Det betyder, at du har problemer med arkitektur og nul ingeniørpraksis. For selvom der er tale om forskning, så skal det under alle omstændigheder formuleres i form af hypoteser eller en cyklus.
Vi talte om 4 målinger, der adskiller succesrige virksomheder fra dem, der halter. Vi skal stadig leve for at se disse 4 målinger. Hvis din gennemsnitlige opgave tager en måned at fuldføre, så vil jeg først fokusere på denne metric. Jeg ville sænke det til 3 dage først. Og efter det begyndte jeg at tænke på Continuous.
Forstod jeg dig rigtigt, at du mener, at det generelt ikke nytter noget at investere i ingeniørpraksis, hvis en opgave tager en måned at udføre?
Du har Kontinuerlig Integration. Og der er sådan et emne, at du på 10 minutter enten kan ordne et fix eller rulle det tilbage. Forestil dig, at du rullede det ud. Desuden har du endda kontinuerlig implementering, du rullede det ud til prod og bemærkede først da, at noget gik galt. Og du skal rulle den tilbage, men du har allerede migreret din database. Du har allerede databaseskemaet for den næste version, desuden havde du også en form for backup, og dataene blev også skrevet der.
Og hvilket alternativ har du? Hvis du ruller koden tilbage, så kan den ikke længere fungere med denne opdaterede database.
Basen bevæger sig kun fremad, ja.
Folk, der har dårlig ingeniørpraksis, har højst sandsynligt heller ikke læst den tykke bog om .... Hvad skal man gøre med sikkerhedskopien? Hvis du gendanner fra en sikkerhedskopi, betyder det, at du mister de data, du har akkumuleret i det øjeblik. For eksempel arbejdede vi i tre timer med den nye version af databasen, brugere registrerede sig der. Du nægter den gamle backup, fordi ordningen ikke virker med den nye version, så du har mistet disse brugere. Og de er utilfredse, bander de.
For at mestre hele rækken af praksis, der understøtter Kontinuerlig Integration og Kontinuerlig Levering, er det ikke nok bare at lære at skrive.... For det første kan der være mange af dem, det vil være upraktisk. Plus der er en masse andre praksisser som Scientific. Der er sådan en praksis, GitHub populariserede den på én gang. Dette er, når du har både gammel kode og ny kode kørende på samme tid. Det er, når du laver en ufærdig funktion, men den kan returnere en vis værdi: enten som en funktion eller som en Rest API. Du udfører både den nye kode og den gamle kode og sammenligner forskellen mellem dem. Og hvis der er en forskel, så logger du denne begivenhed. På denne måde ved du, at du har en ny funktion klar til at rulle ud oven på den gamle, hvis du ikke har haft en uoverensstemmelse mellem de to i et vist tidsrum.
Der er hundredvis af sådanne praksisser. Jeg vil foreslå at starte med transbase udvikling. Hun er ikke 100% på Kontinuerlig Integration, men praksisserne er de samme, det ene kan ikke leve godt uden det andet.
Har du givet transbase udvikling som et eksempel, hvor du kan se praksis, eller foreslår du, at folk begynder at bruge transbase debelopment?
Tag et kig, for de vil ikke kunne bruge det. For at bruge dem skal du læse meget. Og når en person spørger: "Hvad skal man gøre med en funktion, der tager en måned, betyder det, at han ikke har læst om transbaseudvikling." Jeg vil ikke anbefale det endnu. Jeg vil råde til udelukkende at fokusere på emnet, hvordan man korrekt arkitektonisk opdeler store opgaver i mindre. Dette er essensen af nedbrydning.
Nedbrydning er et af arkitektens redskaber. Vi laver først analyse, derefter nedbrydning, derefter syntese og derefter integration. Og sådan fungerer alt for os. Og vi mangler stadig at vokse til kontinuerlig integration gennem nedbrydning. Spørgsmål opstår i den første fase, og vi taler allerede om den fjerde fase, det vil sige jo oftere vi laver integration, jo bedre. Det er stadig for tidligt at gøre dette; det ville være rart at skære ned på din monolit først.
Du skal tegne et antal pile og firkanter på et eller andet diagram. Du kan ikke sige, at nu vil jeg vise det arkitektoniske diagram af en ny applikation og vise en firkant, hvori der er en grøn knap til applikationen. Under alle omstændigheder vil der være flere firkanter og pile. Hvert diagram, jeg så, havde mere end ét. Og nedbrydning, selv på niveauet for grafisk repræsentation, finder allerede sted. Derfor kan firkanterne gøres selvstændige. Hvis ikke, så har jeg store spørgsmål til arkitekten.
Der er et spørgsmål fra chatten: "Hvis en anmeldelse er obligatorisk og tager lang tid, måske en dag eller mere?"
Du har problemer med praksis. Gennemgangen bør ikke vare en dag eller mere. Dette er den samme historie til det forrige spørgsmål, kun lidt blødere. Hvis en anmeldelse fortsætter i en dag, vil denne anmeldelse højst sandsynligt undergå en meget stor forandring. Det betyder, at den skal gøres mindre. I transbase-udvikling, som Oleg anbefalede, er der en historie kaldet kontinuerlig gennemgang. Hendes idé er, at vi laver sådan en lille pull-anmodning med vilje, fordi vi stræber efter at fusionere konstant og lidt ad gangen. Så pull-anmodningen ændrer en abstraktion eller 10 linjer. Takket være denne anmeldelse tager det os et par minutter.
Hvis gennemgangen tager en dag eller mere, er der noget galt. For det første kan du have nogle problemer med arkitekturen. Eller det er et stort stykke kode, f.eks. 1 linjer. Eller din arkitektur er så kompleks, at en person ikke kan forstå den. Dette er et lidt sideværts problem, men det skal også løses. Måske er der slet ikke behov for en anmeldelse. Det skal vi også tænke over. Anmeldelse er det, der bremser dig. Det har sine fordele generelt, men du skal forstå, hvorfor du gør det. Er det en måde, hvorpå du hurtigt kan formidle information, er det en måde, hvorpå du kan sætte nogle standarder internt eller hvad? Hvorfor har du brug for dette? Fordi gennemgangen skal foretages enten meget hurtigt eller helt annulleres. Det er ligesom transbase udvikling - historien er meget smuk, men kun for modne fyre.
Med hensyn til de 4 målinger, vil jeg stadig anbefale at fjerne dem for at forstå, hvad dette fører til. Se på tallene, se på billedet, hvor slemt alting er.
(Dmitry) Jeg er klar til at gå ind i en diskussion om dette med dig. Tal og metrics er alle gode, praksis er fantastisk. Men du skal forstå, om virksomheden har brug for det. Der er virksomheder, der ikke har brug for den slags forandringshastighed. Jeg kender virksomheder, hvor der ikke kan foretages ændringer hvert 15. minut. Og ikke fordi de er så dårlige. Det er sådan en livscyklus. Og for at få grenene til at fungere, skifte-funktionen, har du brug for dyb viden.
Det er kompliceret. Hvis du vil læse historien om skiftefunktionen mere detaljeret, kan jeg varmt anbefale den . Og der er en vidunderlig artikel af Martin Fowler om skiftefunktioner: hvilke typer der er, livscyklusser osv. Skiftefunktionen er kompliceret.
Og du har stadig ikke svaret på spørgsmålet: "Er Jenkins nødvendig eller ej?"
Jenkins er ikke nødvendig under alle omstændigheder. Men seriøst, værktøjerne: Jenkins, Gitlab vil give dig bekvemmelighed. Du vil se, at samlingen er samlet eller ikke samlet. De kan hjælpe dig, men de vil ikke give dig øvelse. De kan kun give dig en cirkel - Ok, ikke Ok. Og så, hvis du også skriver test, for hvis der ikke er nogen test, så er det næsten meningsløst. Derfor er det nødvendigt, fordi det er mere bekvemt, men generelt kan du leve uden det, du vil ikke miste meget.
Det vil sige, hvis du har praksis, betyder det, at du ikke har brug for det?
Det er rigtigt. Jeg anbefaler Jez Humble-testen. Der har jeg en ambivalent holdning til det sidste punkt. Men generelt, hvis du har tre ting, fusionerer du konstant, du kører test på commits i masteren, du fikser hurtigt bygningen i masteren, så behøver du måske ikke andet.
Mens vi venter på spørgsmål fra deltagere, har jeg et spørgsmål. Vi talte bare om produktkoden. Har du brugt det til infrastrukturkode? Er det den samme kode, har den de samme principper og den samme livscyklus, eller er der forskellige livscyklusser og principper? Normalt, når alle taler om kontinuerlig integration og udvikling, glemmer alle, at der også er infrastrukturkode. Og på det seneste er der blevet mere og mere af det. Og skal alle disse regler bringes dertil?
Ikke engang at det burde være, det ville være fantastisk, fordi det ville gøre livet lettere på samme måde. Så snart vi arbejder med kode, ikke med bash-scripts, men vi har normal kode.
Stop, stop, et bash-script er også kode. Rør ikke ved min gamle kærlighed.
Okay, jeg vil ikke trampe på dine minder. Jeg har en personlig modvilje mod bash. Det knækker grimt og skræmmende hele tiden. Og det går ofte uforudsigeligt i stykker, hvorfor jeg ikke kan lide det. Men okay, lad os sige, at du har bash-kode. Måske forstår jeg det virkelig ikke, og der er normale testrammer derude. Jeg ved det bare ikke. Og vi får de samme fordele.
Så snart vi arbejder med infrastruktur som kode, får vi alle de samme problemer som udviklere. For et par måneder siden stødte jeg på en situation, hvor en kollega sendte mig en pull-anmodning på 1 linjer i bash. Og du hænger ud ved anmeldelsen i 000 timer. De samme problemer opstår. Det er stadig kode. Og det er stadig et samarbejde. Vi går i stå med pull-anmodningen, og vi går i stå med, at vi for eksempel løser de samme fusionskonflikter i samme bash.
Jeg kigger nu meget aktivt på det hele på den smukkeste infra-programmering. Jeg har nu bragt Pulumi ind i infrastrukturen. Dette er programmering i sin reneste form. Der er det endnu pænere, fordi jeg har alle mulighederne i et programmeringssprog, dvs. jeg lavede smuk skifte ud af det blå med de samme hvis, og alt er fint. Det vil sige, at min forandring allerede er i masteren. Alle kan allerede se ham. Andre ingeniører kender til det. Det har allerede påvirket noget der. Det var dog ikke aktiveret for alle infrastrukturer. Det tændte for eksempel for mine testbænke. Derfor er det nødvendigt at besvare dit spørgsmål igen. Det gør livet lettere for os, som ingeniører, der arbejder med kode, på samme måde.
Hvis andre har spørgsmål?
Jeg har et spørgsmål. Jeg vil gerne fortsætte diskussionen med Oleg. Generelt tror jeg, at du har ret i, at hvis en opgave tager en måned at udføre, så har man et problem med arkitektur, man har et problem med analyse, nedbrydning, planlægning osv. Men jeg har en fornemmelse af, at hvis man starter forsøger at leve efter Kontinuerlig Integration, så vil du begynde at rette op på smerten med planlægning, fordi du ikke kommer væk fra den andre steder.
(Oleg) Ja, det er rigtigt. Denne praksis kan sammenlignes med enhver anden seriøs kulturforandrende praksis. Det sværeste at overvinde er vaner, især dårlige vaner. Og hvis der for at implementere denne praksis kræves en alvorlig ændring i vanerne hos dem omkring dig: udviklere, ledelse, produktionsleder, så venter overraskelser på dig.
Hvilke overraskelser kan der være? Lad os sige, at du beslutter dig for, at du vil integrere oftere. Og du har nogle andre ting knyttet til integration, for eksempel artefakter. Og i din virksomhed, for eksempel, er der en politik om, at hver artefakt skal redegøres for på en eller anden måde i en form for artefaktlagringssystem. Og det tager noget tid. En person skal markere afkrydsningsfeltet, at han som release manager har testet denne artefakt for at sikre, at den er klar til udgivelse i produktionen. Hvis det tager 5-10-15 minutter, men du laver layoutet en gang om ugen, så er det en lille skat at bruge en halv time en gang om ugen.
Hvis du laver Continuous Integration 10 gange om dagen, skal 10 gange ganges med 30 minutter. Og dette overstiger mængden af arbejdstid for denne release manager. Han bliver bare træt af at gøre det. Der er faste omkostninger til nogle praksisser. Det er alt.
Og du skal enten annullere denne regel, så du ikke længere laver sådan noget skrald, dvs. du tildeler ikke manuelt en grad, der svarer til noget. Du er helt afhængig af nogle automatiske sæt af beredskabstests.
Og hvis du har brug for bevis fra nogen, så chefen underskriver det, og du ikke kommer i produktion uden at Vasya siger, at han tillader det osv. - alt dette nonsens kommer i vejen for udøveren. For hvis der er nogle aktiviteter forbundet med en skat, så stiger alt 100 gange. Derfor vil skiftet ofte ikke blive mødt med glæde af alle. Fordi folks vaner er svære at ændre.
Når en person udfører sit sædvanlige arbejde, gør han det næsten uden at tænke. Hendes kognitive belastning er nul. Han leger bare med det, han har allerede en tjekliste i hovedet, han har gjort det tusind gange. Og så snart du kommer og fortæller ham: "Lad os annullere denne praksis og introducere en ny fra mandag," for ham bliver det en stærk kognitiv belastning. Og det kommer til alle på én gang.
Derfor er den enkleste ting, selvom ikke alle har råd til denne luksus, men det er hvad jeg altid gør, dette er følgende. Hvis et nyt projekt starter, bliver al uafprøvet praksis som regel umiddelbart proppet ind i dette projekt. Selvom projektet er ungt, risikerer vi ikke rigtig noget. Der er ingen Prod endnu, der er intet at ødelægge. Derfor kan det bruges som træning. Denne tilgang virker. Men ikke alle virksomheder har mulighed for at starte sådanne projekter ofte. Selvom det også er lidt mærkeligt, for nu er der en komplet digital transformation, alle skal igangsætte eksperimenter for at følge med konkurrenterne.
Her kommer du frem til, at du først skal have en forståelse for, hvad du skal gøre. Verden er ikke ideel, og prod er heller ikke ideel.
Ja, disse ting hænger sammen.
Virksomheder forstår heller ikke altid, at de skal gå denne vej.
Der er en situation, hvor ingen ændringer overhovedet er mulige. Det er en situation, hvor der er mere pres på holdet. Holdet er allerede ret udbrændt. Hun har ikke tid til at eksperimentere. De arbejder på funktioner fra morgen til aften. Og ledelsen har færre og færre funktioner. Der kræves mere og mere. I en sådan situation er ingen ændringer overhovedet mulige. Holdet kan kun få at vide, at i morgen gør vi det samme som i går, vi skal bare lave lidt flere funktioner. I denne forstand er ingen overgange til nogen praksis mulige. Dette er en klassisk situation, hvor der ikke er tid til at slibe øksen, træer skal fældes, så de klipper den med en kedelig økse. Der er ingen enkle tips her.
(Dmitry) Jeg vil læse en præcisering op fra chatten: "Men vi har brug for en masse testdækning på forskellige niveauer. Hvor meget tid er der afsat til prøver? Det er lidt dyrt og tager meget tid."
(Oleg) Dette er en klassisk misforståelse. Der bør være nok test til, at du kan være sikker. Kontinuerlig integration er ikke en ting, hvor 100% af testene udføres først, og først derefter begynder du at anvende denne praksis. Kontinuerlig integration reducerer din kognitive belastning på grund af det faktum, at hver af de ændringer, du ser med dine øjne, er så tydelige, at du forstår, om det vil bryde noget eller ej, selv uden test. Du kan hurtigt teste dette i dit hoved, fordi ændringerne er små. Selvom du kun har manuelle testere, er det også nemmere for dem. Du rullede ud og sagde: "Se, er der noget i stykker?" De tjekkede og sagde: "Nej, intet er gået i stykker." Fordi testeren ved, hvor han skal lede. Du har én commit tilknyttet ét stykke kode. Og dette udnyttes af specifik adfærd.
Her pyntede du selvfølgelig.
(Dmitry) Jeg er ikke enig her. Der er en praksis - testdrevet udvikling, som vil redde dig fra dette.
(Oleg) Nå, jeg er ikke nået dertil endnu. Den første illusion er, at du skal skrive 100% af testene, ellers behøver du slet ikke lave kontinuerlig integration. Det er ikke sandt. Det er to parallelle praksisser. Og de er ikke direkte afhængige. Din testdækning skal være optimal. Optimal - dette betyder, at du selv er sikker på, at kvaliteten af den mester, som din mester forblev i efter forpligtelsen, giver dig mulighed for trygt at trykke på knappen "Deploy" på en beruset fredag aften. Hvordan opnår du dette? Gennem gennemgang, gennem dækning, gennem god overvågning.
God overvågning kan ikke skelnes fra tests. Hvis du kører test én gang på pre-prod, så tjekker de alle dine brugerscripts én gang, og det er det. Og hvis du kører dem i en endeløs løkke, så er dette dit installerede overvågningssystem, som uendeligt tester alt - uanset om det styrtede ned eller ej. I dette tilfælde er den eneste forskel, om det gøres en eller to gange. Et meget godt sæt af tests... kører uendeligt, dette er overvågning. Og korrekt overvågning bør være sådan.
Og derfor, hvordan du præcis vil opnå denne tilstand, når du gør dig klar fredag aften og går hjem, er et andet spørgsmål. Måske er du bare en fed svindel.
Lad os gå lidt tilbage til Kontinuerlig Integration. Vi løb væk ind i en lidt anderledes kompleks praksis.
Og den anden illusion er, at MVP, siger de, skal gøres hurtigt, så der er slet ikke behov for tests der. Ikke sikkert på den måde. Faktum er, at når du skriver en brugerhistorie i en MVP, kan du enten udvikle den på bolden, det vil sige, at du hørte, at der var en form for brugerhistorie og straks løb for at kode den, eller du kan arbejde med TDD. Og ifølge TDD, som praksis viser, tager det ikke længere tid, dvs. test er en bivirkning. Udøvelsen af TDD handler ikke om at teste. På trods af det, man kalder Test Driven Development, handler det slet ikke om tests. Dette er også snarere en arkitektonisk tilgang. Dette er en tilgang til at skrive præcis, hvad der er nødvendigt og ikke at skrive, hvad der ikke er nødvendigt. Dette er en praksis med at fokusere på den næste iteration af din tænkning med hensyn til at skabe en applikationsarkitektur.
Derfor er det ikke så nemt at slippe af med disse illusioner. MVP og test modsiger ikke hinanden. Selv, snarere tværtimod, hvis du laver MVP ved hjælp af TDD praksis, så vil du gøre det bedre og hurtigere, end hvis du gør det uden træning overhovedet, men på en bold.
Dette er en meget ikke-oplagt og kompleks idé. Når du hører, at nu vil jeg skrive flere tests og samtidig gøre noget hurtigere, så lyder det absolut utilstrækkeligt.
(Dmitry) Mange mennesker her, når de ringer til MVP, er folk for dovne til at skrive noget normalt. Og det er stadig forskellige ting. Der er ingen grund til at gøre MVP til en dårlig ting, der ikke virker.
Ja, ja, du har ret.
Og så pludselig MVP i prod.
For evigt og altid.
Og TDD lyder meget usædvanligt, når du hører, at du skriver test og ser ud til at gøre mere arbejde. Det lyder meget mærkeligt, men faktisk bliver det hurtigere og smukkere på denne måde. Når du skriver en test, tænker du allerede meget i hovedet på, hvad kode skal hedde og hvordan, samt hvilken adfærd vi forventer af den. Du siger ikke bare, at jeg har skrevet en funktion, og den gør noget. Først troede du, at hun havde sådan og sådan betingelser, hun ville blive tilkaldt på sådan og sådan måde. Du dækker dette med test og ud fra dette forstår du hvordan dine grænseflader vil se ud inde i din kode. Dette har en enorm indflydelse på arkitekturen. Din kode bliver automatisk mere modulær, fordi du først forsøger at forstå, hvordan du vil teste den, og først derefter skriver den.
Det, der skete med mig med TDD, var, at jeg på et tidspunkt hyrede en Ruby-mentor, da jeg stadig var Ruby-programmør. Og han siger: "Lad os gøre det ifølge TDD." Jeg tænkte: "For pokker, nu skal jeg skrive noget ekstra." Og vi blev enige om, at jeg inden for to uger ville skrive al arbejdskoden i Python ved hjælp af TDD. Efter to uger indså jeg, at jeg ikke ville tilbage. Efter to ugers forsøg på at anvende dette overalt, indser du, hvor meget nemmere det er blevet for dig selv bare at tænke. Men dette er ikke indlysende, så jeg anbefaler alle, at hvis du har fornemmelsen af, at TDD er svært, tidskrævende og unødvendigt, så prøv at holde fast i det i blot to uger. To var nok for mig.
(Dmitry) Vi kan udvide denne idé fra synspunktet om infrastrukturdrift. Før vi lancerer noget nyt, foretager vi overvågning og lancerer derefter. I dette tilfælde bliver overvågning normal test for os. Og der sker udvikling gennem overvågning. Men næsten alle siger, at det er langt, jeg er doven, jeg lavede et midlertidigt udkast. Hvis vi har udført normal overvågning, forstår vi CI-systemets tilstand. Og CI-systemet har meget overvågning. Vi forstår systemets tilstand, vi forstår, hvad der er inde i det. Og under udviklingen laver vi bare systemet, så det når den ønskede tilstand.
Denne praksis har været kendt i lang tid. Vi diskuterede det for omkring 4 år siden. Men på 4 år har praktisk talt intet ændret sig.
Men på denne baggrund foreslår jeg at afslutte den officielle diskussion.
Video (indsat som et medieelement, men virker af en eller anden grund ikke):
Kilde: www.habr.com