Hajde da raspravimo zašto su CI alati i CI potpuno različite stvari.
Koju bol CI treba da reši, odakle ideja, koje su najnovije potvrde da radi, kako shvatiti da imate praksu, a ne samo instalirate Jenkinsa.
Ideja da napravim izvještaj o Kontinuiranoj integraciji pojavila se prije godinu dana, kada sam išao na razgovore i tražio posao. Razgovarao sam sa 10-15 kompanija, samo jedna je mogla jasno da odgovori šta je CI i objasni kako su shvatili da ga nemaju. Ostali su pričali nerazumljive gluposti o Dženkinsu :) Pa, imamo Jenkinsa, on gradi, CI! Tokom izvještaja pokušat ću objasniti šta je zapravo kontinuirana integracija i zašto Jenkins i slični alati imaju vrlo slab odnos s tim.
Dakle, šta vam obično pada na pamet kada čujete riječ CI? Većina ljudi će pomisliti na Jenkinsa, Gitlab CI, Travisa, itd.
Čak i ako ga proguglamo, to će nam dati ove alate.
Ako ste upoznati sa pitanjem, onda će vam odmah nakon navođenja alata reći da je CI kada gradite i izvodite testove u zahtjevu za povlačenjem za urezivanje.
Kontinuirana integracija se ne odnosi na alate, ne na sklopove sa testovima u grani! Kontinuirana integracija je praksa vrlo česte integracije novog koda i za njeno korištenje uopće nije potrebno ograđivati Jenkinsa, GitLaba itd.
Prije nego što shvatimo kako izgleda potpuni CI, hajde da prvo zaronimo u kontekst ljudi koji su ga smislili i osjetimo bol koji su pokušavali riješiti.
I riješili su bol zajedničkog rada kao tim!
Pogledajmo primjere poteškoća s kojima se susreću programeri kada razvijaju timove. Ovdje imamo projekat, master granu u git-u i dva programera.
I krenuli su na posao kako su svi odavno navikli. Uzeli smo zadatak u velikoj shemi stvari, kreirali granu karakteristika i napisali kod.
Jedan je brže završio funkciju i spojio je u master.
Za drugu je trebalo više vremena, kasnije se spojila i završila sukobom. Sada, umjesto da piše karakteristike koje su potrebne za poslovanje, programer troši svoje vrijeme i energiju na rješavanje sukoba.
Što je teže kombinovati vašu osobinu sa zajedničkim majstorom, više vremena trošimo na to. I to sam pokazao na prilično jednostavnom primjeru. Ovo je primjer gdje postoje samo 2 programera Zamislite da 10 ili 15 ili 100 ljudi u kompaniji piše u jedno spremište. Poludjet ćete da riješite sve ove sukobe.
Postoji malo drugačiji slučaj. Imamo majstora i neke programere koji nešto rade.
Stvorili su grančicu.
Jedan je poginuo, sve je bilo u redu, prošao je zadatak.
Drugi programer je u međuvremenu predao svoj zadatak. Recimo da ga je poslao na pregled. Mnoge kompanije imaju praksu koja se zove pregled. S jedne strane, ova praksa je dobra i korisna, s druge strane nas na mnogo načina usporava. Nećemo ulaziti u to, ali evo sjajnog primjera do čega može dovesti loša priča o recenzijama. Podnijeli ste zahtjev za povlačenje na pregled. Programer ne može više ništa da uradi. Šta počinje da radi? Počinje preuzimati druge zadatke.
Za to vrijeme, drugi programer je radio nešto drugo.
Prvi je završio treći zadatak.
I nakon dužeg vremena, njegova recenzija je testirana, i on pokušava da se pomiri. Pa šta se dešava? Zahvaća ogroman broj sukoba. Zašto? Jer dok je njegov zahtjev za povlačenjem visio u recenziji, mnoge stvari su se već promijenile u kodu.
Pored priče o sukobima, tu je i priča sa komunikacijama. Dok vaša nit visi na pregledu, dok čeka nešto, dok dugo radite na nekoj funkciji, prestajete pratiti šta se još mijenja u bazi koda vašeg servisa. Možda je ono što sada pokušavate riješiti jučer već riješeno i možete uzeti neki metod i ponovo ga koristiti. Ali ovo nećete vidjeti jer uvijek radite sa zastarjelom granom. A ova zastarjela grana uvijek rezultira time da morate riješiti sukob spajanja.
Ispada da ako radimo kao tim, tj. ne čačka po spremištu jedna osoba, već 5-10 ljudi, onda što duže ne dodajemo svoj kod u master, to više patimo jer nam na kraju treba nešto onda spoji. I što više sukoba imamo, i sa starijom verzijom radimo, imamo više problema.
Raditi nešto zajedno je bolno! Uvek stanemo jedno drugom na put.
Ovaj problem je uočen prije više od 20 godina. Prvi spomen prakse kontinuirane integracije pronašao sam u ekstremnom programiranju.
Ekstremno programiranje je prvi agilni okvir. Stranica se pojavila 96. A ideja je bila da koristimo nekakvu programsku praksu, planiranje i druge stvari, kako bi razvoj bio što fleksibilniji, kako bismo brzo odgovorili na sve promjene ili zahtjeve naših klijenata. I oni su se počeli suočavati s tim prije 24 godine, da ako nešto radiš jako dugo i po strani, onda više vremena trošiš na to jer imaš sukobe.
Sada ćemo pojedinačno analizirati frazu „Kontinuirana integracija“. Ako ga prevedemo direktno, dobijamo kontinuiranu integraciju. Ali koliko je to kontinuirano, nije baš jasno; vrlo je diskontinuirano. Ali kolika je integracija, takođe nije baš očigledno.
I zato vam sada dajem citate iz Ekstremnog programiranja. I analiziraćemo obe reči odvojeno.
Integracija - Kao što sam već rekao, trudimo se da svaki inženjer radi sa najnovijom verzijom koda, tako da nastoji da svoj kod dodaje što češće u zajedničku granu, tako da to budu male grane. Jer ako su veliki, onda se lako možemo zaglaviti sa sukobima spajanja na nedelju dana. Ovo je posebno tačno ako imamo dug razvojni ciklus kao što je vodopad, gde je programer otišao na mesec dana da bi isekao neku ogromnu funkciju. I on će zaglaviti u fazi integracije jako dugo.
Integracija je kada uzmemo našu granu i integrišemo je sa masterom, mi je spojimo. Postoji krajnja opcija kada smo programeri transbaze, gdje nastojimo osigurati da odmah pišemo masteru bez ikakvih dodatnih grana.
Općenito, integracija znači uzimanje vašeg koda i prevlačenje u master.
Šta se ovdje podrazumijeva pod riječju „kontinuirano“, što se naziva kontinuitetom? Praksa podrazumeva da programer nastoji da integriše svoj kod što je brže moguće. To je njegov cilj kada obavlja bilo koji zadatak - da se njegov kod pojavi u masteru što je prije moguće. U idealnom svijetu, programeri bi to radili svakih nekoliko sati. To jest, uzimate mali problem i spajate ga u master. Sve je super. Ovo je ono čemu težite. I to se mora raditi kontinuirano. Čim nešto uradiš, odmah to staviš u majstora.
A programer koji nešto napravi je odgovoran za ono što je uradio da to radi i da ništa ne pokvari. Tu obično izlazi priča o testu. Želimo da pokrenemo neke testove na našem urezivanju, na našem spajanju, da bismo bili sigurni da radi. I ovdje vam Dženkins može pomoći.
Ali sa pričama: neka promjene budu male, neka zadaci budu mali, napravimo problem i odmah pokušamo to nekako ugraditi u master - nikakav Dženkins tu neće pomoći. Jer će vam Dženkins samo pomoći da pokrenete testove.
Možete i bez njih. Ovo ti uopšte neće naškoditi. Jer je cilj prakse mjeriti što češće, kako ne bi gubili ogromnu količinu vremena na bilo kakve sukobe u budućnosti.
Zamislimo da smo iz nekog razloga 2020. godine bez interneta. I radimo lokalno. Nemamo Dženkinsa. Ovo je u redu. Još uvijek možete nastaviti i napraviti lokalnu podružnicu. Napisali ste neki kod u njemu. Zadatak smo završili za 3-4 sata. Prešli smo na master, izvršili git pull i tamo spojili našu granu. Spreman. Ako ovo radite često, čestitamo, imate kontinuiranu integraciju!
Koji dokazi u savremenom svijetu postoje da se isplati trošiti energiju? Jer generalno je teško. Ako pokušate ovako raditi, shvatit ćete da će neko planiranje sada biti pogođeno, morat ćete posvetiti više vremena dekomponiranju zadataka. Jer ako uradiš čovječe..., onda se nećeš moći brzo pomiriti i, shodno tome, upasti ćeš u nevolje. Više nećete imati praksu.
I to će biti skupo. Neće biti moguće raditi odmah od sutra koristeći kontinuiranu integraciju. Svima će vam trebati jako puno vremena da se naviknete na to, trebat će vam jako dugo da se naviknete na razlaganje zadataka, trebat će vam jako dugo da se naviknete na ponavljanje prakse pregleda, ako je imate . Jer naš cilj je da se danas otopi. A ako obavite pregled u roku od tri dana, onda imate problema i Kontinuirana integracija vam ne radi.
Ali imamo li trenutno relevantne dokaze koji nam govore da ulaganje u ovu praksu ima smisla?
Prva stvar koja mi je pala na pamet je stanje DevOps-a. Ovo je studija koju momci sprovode već 7 godina. Sada to rade kao nezavisna organizacija, ali pod Google-om.
A njihova studija iz 2018. pokazala je korelaciju između kompanija koje pokušavaju koristiti kratkotrajne grane koje se brzo integriraju, integriraju se često i imaju bolje pokazatelje IT učinka.
Koji su ovi pokazatelji? Ovo su 4 metrike koje uzimaju od svih kompanija u svojim upitnicima: učestalost implementacije, vrijeme za promjene, vrijeme za obnavljanje usluge, stopa neuspjeha promjene.
I, prvo, postoji ova korelacija, znamo da kompanije koje mjere često imaju mnogo bolje metrike. I oni imaju podjelu kompanija u nekoliko kategorija: to su spore kompanije koje proizvode nešto sporo, srednje uspješne, visoke i elitne. Elita su Netflix, Amazon, koji su super brzi, sve rade brzo, lijepo i efikasno.
Druga priča, koja se dogodila prije samo mjesec dana. Technology Radar ima sjajan članak o Gitflowu. Gitflow se razlikuje od svih ostalih po tome što su njegove grane dugovječne. Postoje grane izdanja koje žive dugo vremena i grane koje također žive dugo vremena. Ova praksa u Technology Radar-u je prešla na HOLD. Zašto? Zato što se ljudi suočavaju sa bolom integracije.
Ako vaša grana živi jako dugo, zaglavi se, pokvari se i počinjemo provoditi više vremena pokušavajući da je promijenimo.
A nedavno je autor Gitflowa rekao da ako je vaš cilj Kontinuirana integracija, ako je vaš cilj da želite da se bavite što češće, onda je Gitflow loša ideja. Zasebno je dodao u članak da ako imate backend gdje možete težiti tome, onda vam je Gitflow suvišan, jer će vas Gitflow usporiti, Gitflow će vam stvarati probleme s integracijom.
To ne znači da je Gitflow loš i da ga ne treba koristiti. Za druge prilike. Na primjer, kada trebate podržati nekoliko verzija usluge ili aplikacije, odnosno kada vam je potrebna podrška tokom dužeg vremenskog perioda.
Ali ako razgovarate sa ljudima koji podržavaju takve servise, čućete dosta bola zbog činjenice da je ova verzija bila 3.2, što je bilo pre 4 meseca, ali ovaj ispravak nije bio uključen u nju i sada, da bi je napravio, morate napraviti gomilu promjena. I sada su ponovo zapeli, i sada su petljali okolo nedelju dana pokušavajući da implementiraju neku novu funkciju.
Kao što je Aleksandar Kovaljov tačno primetio u razgovoru, korelacija nije isto što i uzročna veza. Istina je. Odnosno, nema direktne veze da ako imate kontinuiranu integraciju, onda će sve metrike biti odlične. Ali postoji pozitivna korelacija da ako je jedno jedno, onda je najvjerovatnije i drugo. Nije činjenica, ali najvjerovatnije. To je samo korelacija.
Čini se da već radimo nešto, čini se da se već spajamo, ali kako da shvatimo da još uvijek imamo kontinuiranu integraciju, da se spajamo prilično često?
Jez Humble je autor Handbook, Accelerate, web stranice Continuous Delivery i knjige Continuous Delivery. On nudi ovaj test:
- Inženjerski kod svakog dana stiže do majstora.
- Za svako urezivanje izvodite jedinične testove.
- Ugradnja u masteru je pala, popravljeno je za 10-ak minuta.
Predlaže korištenje ovakvog testa kako biste bili sigurni da imate dovoljno vježbe.
Smatram da je ovo drugo malo kontroverzno. Odnosno, ako to možete popraviti za 10 minuta, onda imate kontinuiranu integraciju, zvuči malo čudno, po mom mišljenju, ali ima smisla. Zašto? Jer ako se često smrzavate, to znači da su vaše promjene male. Ako mala promjena znači da je vaša glavna konstrukcija pokvarena, tada možete brzo pronaći primjer jer je promjena mala. Ovdje ste imali malo spajanje, promijenilo se 20-30 redova u njemu. I, shodno tome, možete brzo shvatiti šta je bio razlog, jer su promjene male, imate vrlo malo područje za traženje problema.
A čak i ako nam se proizvod raspadne nakon izlaska, onda ako imamo praksu Kontinuirane integracije, mnogo nam je lakše djelovati, jer su promjene male. Da, ovo će uticati na planiranje. Ovo će boljeti. I, vjerovatno, najteža stvar u ovoj praksi je naviknuti se na raščlanjivanje zadataka, odnosno kako to učiniti da možete uzeti nešto i obaviti to za nekoliko sati i pritom proći pregled, ako imaš jedan. Pregled je posebna muka.
Jedinični testovi su samo pomoćnik koji vam pomaže da shvatite da li je vaša integracija bila uspješna i da li ništa nije pokvareno. Po mom mišljenju, ni to nije sasvim obavezno, jer to nije poenta prakse.
Ovo je kratak uvod u kontinuiranu integraciju. To je sve što postoji u ovoj praksi. Spreman sam za pitanja.
Opet ću samo ukratko rezimirati:
- Kontinuirana integracija nije Jenkins, nije Gitlab.
- Ovo nije alat, praksa je da svoj kod stapamo u master što je češće moguće.
- To radimo kako bismo izbjegli ogromnu bol koja nastaje spajanjem u budućnosti, odnosno doživljavamo malo bola sada kako ne bismo doživjeli više u budućnosti. To je cela poenta.
- Sa strane postoji komunikacija putem koda, ali ovo vrlo rijetko viđam, ali za to je i dizajniran.
Vaša pitanja
Šta raditi s nedekomponiranim zadacima?
Decompose. Šta je problem? Možete li navesti primjer da postoji zadatak i da nije razložen?
Postoje zadaci koji se ne mogu rastaviti od riječi „potpuno“, na primjer, oni koji zahtijevaju vrlo duboku stručnost i koji se zapravo mogu riješiti u toku mjesec dana da bi se postigao neki probavljiv rezultat.
Ako sam vas dobro razumeo, onda postoji neki veliki i složen zadatak čiji će rezultat biti vidljiv tek za mesec dana?
Da, tako je. Da, rezultat će biti moguće ocijeniti najkasnije za mjesec dana.
U redu. Generalno, to nije problem. Zašto? Jer u ovom slučaju, kada govorimo o grančicama, ne govorimo o grančici sa osobinom. Karakteristike mogu biti velike i složene. Oni mogu uticati na veliki broj komponenti. A možda ih ne možemo u potpunosti obaviti u jednoj grani. Ovo je u redu. Samo treba da razbijemo ovu priču. Ako funkcija nije u potpunosti spremna, to ne znači da se neki dijelovi njenog koda ne mogu spojiti. Dodali ste, recimo, migraciju i postoje neke faze unutar funkcije. Recimo da imate fazu - napravite migraciju, dodajte novu metodu. A ove stvari već možete mjeriti svaki dan.
U redu. U čemu je onda poenta?
Koja je svrha ubijanja malih stvari svaki dan?
Da.
Ako nešto razbiju, to odmah vidite. Imate mali komadić koji je nešto slomio, lakše vam je to popraviti. Poenta je da je spajanje malog dijela sada mnogo lakše nego spajanje nečeg velikog za nekoliko sedmica. I treća stvar je da će drugi inženjeri raditi sa trenutnom verzijom koda. Oni će vidjeti da su neke migracije dodane ovdje, a zatim se pojavila neka metoda koju bi također mogli htjeti koristiti. Svi će vidjeti šta se dešava u vašem kodu. Za ove tri stvari se radi.
Hvala, problem je zatvoren!
(Oleg Soroka) Mogu li dodati? Sve ste tačno rekli, samo želim da dodam jednu frazu.
So.
Uz kontinuiranu integraciju, kod se spaja u zajedničku granu ne kada je funkcija potpuno spremna, već kada se izgradnja prestane kvariti. I možete se sigurno posvetiti savladavanju koliko god puta dnevno želite. Drugi aspekt je da ako iz nekog razloga ne možete razbiti mjesečni zadatak na zadatke najmanje tri dana, ja ćutim oko tri sata, onda imate veliki problem. A činjenica da nemate kontinuiranu integraciju je najmanji od ovih problema. To znači da imate problema sa arhitekturom i nultom inženjerskom praksom. Jer čak i ako je ovo istraživanje, u svakom slučaju ono mora biti formulirano u obliku hipoteza ili ciklusa.
Razgovarali smo o 4 metrike koje razlikuju uspješne kompanije od onih koje zaostaju. Moramo još doživjeti da vidimo ova 4 metrika. Ako je za vaš prosječan zadatak potrebno mjesec dana, onda bih se prvo fokusirao na ovu metriku. Prvo bih smanjio na 3 dana. I nakon toga sam počeo razmišljati o Continuousu.
Da li sam vas dobro razumeo da mislite da generalno nema smisla ulagati u inženjerske prakse ako je za bilo koji zadatak potrebno mesec dana?
Imate kontinuiranu integraciju. I postoji takva tema da za 10 minuta možete ili popraviti popravku ili je vratiti. Zamislite da ste ga izbacili. Štaviše, imate čak i kontinuiranu implementaciju, izbacili ste je na prod i tek tada primijetili da je nešto pošlo po zlu. I morate ga vratiti, ali već ste migrirali svoju bazu podataka. Već imate šemu baze podataka sljedeće verzije, štoviše, imali ste i neku vrstu sigurnosne kopije, a podaci su također upisani tamo.
I koju alternativu imate? Ako vratite kod, on više ne može raditi s ovom ažuriranom bazom podataka.
Baza se kreće samo napred, da.
Ljudi koji imaju lošu inženjersku praksu najvjerovatnije nisu pročitali ni debelu knjigu o... Šta učiniti sa sigurnosnom kopijom? Ako vraćate iz rezervne kopije, to znači da gubite podatke koje ste akumulirali u tom trenutku. Na primjer, radili smo tri sata sa novom verzijom baze podataka, korisnici su se tu registrovali. Odbijate staru sigurnosnu kopiju jer shema ne radi s novom verzijom, pa ste izgubili ove korisnike. A oni su nezadovoljni, kunu se.
Da biste savladali čitav niz praksi koje podržavaju kontinuiranu integraciju i kontinuiranu isporuku, nije dovoljno samo naučiti kako pisati.... Prvo, može ih biti puno, to će biti nepraktično. Osim toga, postoji gomila drugih praksi kao što je Scientific. Postoji takva praksa, GitHub ju je svojevremeno popularizirao. Ovo je kada imate i stari i novi kod koji se izvršavaju u isto vrijeme. Ovo je kada napravite nedovršenu funkciju, ali ona može vratiti neku vrijednost: bilo kao funkcija ili kao Rest API. Izvršavate i novi i stari kod i poredite razliku između njih. A ako postoji razlika, onda prijavite ovaj događaj. Na ovaj način znate da imate novu funkciju spremnu za puštanje iznad stare ako niste imali neslaganje između njih određeno vrijeme.
Postoje stotine takvih praksi. Predlažem da počnete sa razvojem transbaze. Nije 100% na kontinuiranoj integraciji, ali praksa je ista, jedno bez drugog ne može dobro.
Da li ste naveli razvoj transbaze kao primjer gdje možete vidjeti prakse ili predlažete da ljudi počnu koristiti transbase debelopment?
Pogledajte, jer oni to neće moći koristiti. Da biste ih koristili, morate puno čitati. A kada osoba pita: „Šta učiniti sa funkcijom koja traje mjesec dana, to znači da nije čitala o razvoju transbaze.“ Ne bih ga još preporučio. Savjetovao bih da se fokusirate isključivo na temu kako pravilno arhitektonski rastaviti velike zadatke na manje. Ovo je suština razgradnje.
Dekompozicija je jedan od alata arhitekte. Prvo radimo analizu, zatim dekompoziciju, zatim sintezu, pa integraciju. I ovako nam sve ide. I još uvijek treba da rastemo do kontinuirane integracije kroz dekompoziciju. Pitanja se postavljaju u prvoj fazi, a već govorimo o četvrtoj, odnosno što češće radimo integraciju, to bolje. Još je prerano za ovo; bilo bi dobro da prvo srušite svoj monolit.
Morate nacrtati određeni broj strelica i kvadrata na nekom dijagramu. Ne možete reći da ću sada pokazati arhitektonski dijagram nove aplikacije i prikazati jedan kvadrat, unutar kojeg se nalazi zeleno dugme za aplikaciju. U svakom slučaju, biće više kvadrata i strelica. Svaki dijagram koji sam vidio imao je više od jednog. A dekompozicija, čak i na nivou grafičkog predstavljanja, se već odvija. Stoga se kvadrati mogu učiniti nezavisnim. Ako ne, onda imam velika pitanja za arhitektu.
Postoji pitanje iz chata: "Ako je pregled obavezan i traje dugo, možda dan ili više?"
Imate problema sa praksom. Pregled ne bi trebao trajati dan ili više. Ovo je ista priča kao i prethodno pitanje, samo malo blaže. Ako recenzija traje jedan dan, onda će najvjerovatnije ova recenzija imati neku veliku promjenu. To znači da ga treba smanjiti. U razvoju transbaze, koji je Oleg preporučio, postoji priča koja se zove kontinuirani pregled. Njena ideja je da namerno napravimo tako mali pull zahtev, jer nastojimo da se stapamo stalno i malo po malo. I tako zahtjev za povlačenjem mijenja jednu apstrakciju ili 10 linija. Zahvaljujući ovoj recenziji, potrebno nam je nekoliko minuta.
Ako pregled traje dan ili više, nešto nije u redu. Prvo, možda ćete imati problema sa arhitekturom. Ili je ovo veliki dio koda, na primjer 1 linija. Ili je vaša arhitektura toliko složena da je osoba ne može razumjeti. Ovo je malo sputan problem, ali će se morati i riješiti. Možda uopće nema potrebe za pregledom. Moramo razmisliti i o ovome. Pregled je ono što vas usporava. Generalno, ima svojih prednosti, ali morate razumjeti zašto to radite. Da li je ovo način da brzo prenesete informacije, da li je ovo način da interno postavite neke standarde ili šta? Zašto ti ovo treba? Zato što pregled treba da se uradi ili vrlo brzo ili da se u potpunosti poništi. To je kao transbazni razvoj - priča je jako lijepa, ali samo za zrele momke.
Što se tiče 4 metrike, ipak bih preporučio da ih uklonite da biste razumjeli čemu to vodi. Pogledajte brojke, pogledajte sliku, kako je sve loše.
(Dmitrij) Spreman sam da uđem u raspravu o tome sa vama. Brojevi i metrika su sjajni, prakse su odlične. Ali morate razumjeti da li je to potrebno preduzeću. Postoje kompanije kojima nije potrebna takva brzina promjena. Znam kompanije u kojima se promjene ne mogu napraviti svakih 15 minuta. I ne zato što su tako loši. Ovo je takav životni ciklus. A da biste napravili funkciju grana, funkciju prebacivanja, potrebno vam je duboko znanje.
Komplikovano je. Ako želite detaljnije pročitati priču o funkciji prebacivanja, toplo je preporučujem . Postoji i divan članak Martina Fowlera o funkcijama prebacivanja: koje vrste postoje, životni ciklusi, itd. Funkcija prebacivanja je komplikovana.
I još uvijek niste odgovorili na pitanje: "Da li je Dženkins potreban ili ne?"
Dženkins u svakom slučaju zaista nije potreban. Ozbiljno, alati: Jenkins, Gitlab će vam donijeti udobnost. Vidjet ćete da je sklop sastavljen ili nije sastavljen. Oni vam mogu pomoći, ali vam neće dati vježbu. Mogu vam dati samo krug - Ok, ne Ok. A onda, ako i pišete testove, jer ako nema testova, onda je to gotovo besmisleno. Stoga je potreban jer je praktičniji, ali općenito možete živjeti bez njega, nećete puno izgubiti.
Odnosno, ako imate praksu, da li to znači da vam nije potrebna?
Tako je. Preporučujem Jez Humble test. Tu imam ambivalentan stav prema posljednjoj tački. Ali općenito, ako imate tri stvari, stalno se spajate, pokrećete testove urezivanja u masteru, brzo popravljate build u masteru, onda vam možda ništa više ne treba.
Dok čekamo pitanja učesnika, imam jedno pitanje. Upravo smo pričali o šifri proizvoda. Jeste li ga koristili za infrastrukturni kod? Da li je to isti kod, ima li iste principe i isti životni ciklus, ili postoje različiti životni ciklusi i principi? Obično, kada svi pričaju o kontinuiranoj integraciji i razvoju, svi zaborave da postoji i infrastrukturni kod. A u posljednje vrijeme toga je sve više. I treba li sva ta pravila donijeti tamo?
Čak ni da bi trebalo, bilo bi super jer bi na isti način olakšalo život. Čim radimo sa kodom, ne sa bash skriptama, ali imamo normalan kod.
Stop, stop, bash skripta je takođe kod. Ne diraj moju staru ljubav.
Dobro, neću ti gaziti uspomene. Lično ne volim bash. Ružno i zastrašujuće se lomi cijelo vrijeme. I često se nepredvidivo pokvari, zbog čega mi se ne sviđa. Ali u redu, recimo da imate bash kod. Možda stvarno ne razumijem i postoje normalni okviri za testiranje. Samo nisam upoznat. I dobijamo iste pogodnosti.
Čim radimo sa infrastrukturom kao kodom, imamo iste probleme kao programeri. Prije nekoliko mjeseci naišao sam na situaciju da mi je kolega poslao zahtjev za povlačenjem za 1 redova u bash-u. I visiš na smotri 000 sata. Nastaju isti problemi. Još uvijek je šifra. I to je još uvijek saradnja. Zaglavimo sa zahtjevom za povlačenje i zapnemo s činjenicom da rješavamo iste konflikte spajanja u istom bash-u, na primjer.
Sada vrlo aktivno gledam cijelu ovu stvar na najljepšem infra programiranju. Pulumi sam sada uveo u infrastrukturu. Ovo je programiranje u svom najčistijem obliku. Tamo je još ljepše, jer imam sve mogućnosti programskog jezika, tj. napravio sam prekrasan prekidač iz vedra neba sa istim if-ovima i sve je u redu. To jest, moja promjena je već u masteru. Svi ga već vide. Drugi inženjeri znaju za to. To je već uticalo na nešto tamo. Međutim, to nije bilo omogućeno za sve infrastrukture. Upalio se za moje ispitne stolove, na primjer. Stoga, da ponovo odgovorim na vaše pitanje, neophodno je. Nama, kao inženjerima koji rade sa kodom, na isti način olakšava život.
Ako još neko ima pitanja?
Imam pitanje. Želim da nastavim razgovor sa Olegom. Generalno, mislim da ste u pravu, da ako je za zadatak potrebno mesec dana, onda imate problem sa arhitekturom, imate problem sa analizom, dekompozicijom, planiranjem itd. Ali imam osećaj da ako počnete pokušavajući živjeti u skladu s kontinuiranom integracijom, tada ćete početi ispravljati bol planiranjem, jer od toga nećete pobjeći nigdje drugdje.
(Oleg) Da, tako je. Ova praksa je uporediva po naporima sa bilo kojom drugom ozbiljnom praksom koja mijenja kulturu. Najteže je savladati navike, posebno loše navike. A ako je za implementaciju ove prakse potrebna ozbiljna promjena navika onih oko vas: programera, menadžmenta, menadžera proizvodnje, onda vas očekuju iznenađenja.
Kakva bi iznenađenja mogla biti? Recimo da odlučite da ćete se češće integrisati. I imate neke druge stvari vezane za integraciju, na primjer, artefakte. A u vašoj kompaniji, na primjer, postoji politika da se svaki artefakt mora na neki način uračunati u neku vrstu sistema za skladištenje artefakata. I potrebno je neko vrijeme. Osoba treba da označi polje da je on, kao menadžer izdanja, testirao ovaj artefakt kako bi se uvjerio da je spreman za puštanje u proizvodnju. Ako je potrebno 5-10-15 minuta, a raspored radite jednom sedmično, onda je trošenje pola sata jednom sedmično mali porez.
Ako radite kontinuiranu integraciju 10 puta dnevno, onda 10 puta treba pomnožiti sa 30 minuta. A ovo premašuje količinu radnog vremena ovog menadžera izdanja. Jednostavno se umori od toga. Za neke prakse postoje fiksni troškovi. To je sve.
I trebate ili poništiti ovo pravilo da više ne radite takvo smeće, tj. da ručno ne dodjeljujete diplomu da nečemu odgovara. U potpunosti se oslanjate na neki automatizirani skup testova spremnosti.
A ako vam treba dokaz od nekoga, da ga šef potpiše, a da ne uđete u proizvodnju, a da Vasja ne kaže da to dozvoljava itd. - sve te gluposti staju na put praktičaru. Jer ako postoje neke aktivnosti povezane sa porezom, onda se sve povećava 100 puta. Stoga smjenu često neće svi dočekati s radošću. Jer je navike ljudi teško promijeniti.
Kada osoba radi svoj uobičajeni posao, radi ga gotovo bez razmišljanja. Njeno kognitivno opterećenje je nula. On se samo igra s tim, već ima kontrolnu listu u glavi, uradio je to hiljadu puta. A čim dođete i kažete mu: „Hajde da ukinemo ovu praksu i uvedemo novu od ponedeljka“, za njega to postaje snažno kognitivno opterećenje. I dolazi svima odjednom.
Dakle, najjednostavnija stvar, iako ne može svako sebi priuštiti ovaj luksuz, ali to je ono što ja uvijek radim, ovo je sljedeće. Ako započne novi projekat, obično se sve neprovjerene prakse odmah uguraju u ovaj projekat. Dok je projekat mlad, ne rizikujemo baš ništa. Proda još nema, nema se šta uništiti. Stoga se može koristiti kao trening. Ovaj pristup funkcionira. Ali nemaju sve kompanije priliku da često pokreću takve projekte. Iako je i to malo čudno, jer je sada potpuna digitalna transformacija, svi moraju pokrenuti eksperimente kako bi išli ukorak s konkurentima.
Ovdje dolazite do zaključka da prvo morate razumjeti šta trebate učiniti. Svijet nije idealan, a ni prod nije idealan.
Da, ove stvari su međusobno povezane.
Preduzeća takođe ne shvataju uvek da treba da idu ovim putem.
Postoji situacija u kojoj nikakve promjene nisu moguće. Ovo je situacija u kojoj je veći pritisak na tim. Tim je već prilično izgoreo. Ona nema slobodnog vremena za bilo kakve eksperimente. Rade na funkcijama od jutra do večeri. A menadžment ima sve manje funkcija. Potrebno je sve više i više. U takvoj situaciji nikakve promjene nisu moguće. Timu se samo može reći da ćemo sutra raditi isto kao juče, samo trebamo napraviti još malo mogućnosti. U tom smislu, nikakvi prijelazi na bilo kakve prakse nisu mogući. Ovo je klasična situacija kada nema vremena za naoštravanje sjekire, drveće treba posjeći, pa je sjeku tupom sjekirom. Ovdje nema jednostavnih savjeta.
(Dmitrij) Pročitaću pojašnjenje iz ćaskanja: „Ali treba nam puno pokrivenosti testom na različitim nivoima. Koliko vremena je predviđeno za testove? Malo je skupo i oduzima puno vremena.”
(Oleg) Ovo je klasična zabluda. Trebalo bi da ima dovoljno testova da budete sigurni. Kontinuirana integracija nije stvar u kojoj se prvo uradi 100% testova pa tek onda počinjete primjenjivati ovu praksu. Kontinuirana integracija smanjuje vaše kognitivno opterećenje zbog činjenice da je svaka promjena koju vidite svojim očima toliko očigledna da razumijete hoće li nešto pokvariti ili ne, čak i bez testova. Ovo možete brzo testirati u svojoj glavi jer su promjene male. Čak i ako imate samo ručne testere, i njima je lakše. Otkotrljao si se i rekao: "Vidi, je li nešto pokvareno?" Provjerili su i rekli: "Ne, ništa nije pokvareno." Jer tester zna gdje da traži. Imate jedno urezivanje povezano s jednim dijelom koda. I to se iskorištava specifičnim ponašanjem.
Ovdje ste, naravno, uljepšali.
(Dmitry) Ovdje se ne slažem. Postoji praksa - razvoj vođen testom, koji će vas spasiti od ovoga.
(Oleg) Pa, nisam još stigao do te tačke. Prva iluzija je da morate napisati 100% testova ili uopće ne trebate raditi kontinuiranu integraciju. To nije istina. To su dvije paralelne prakse. I nisu direktno zavisni. Vaša pokrivenost testom mora biti optimalna. Optimalno - to znači da ste i sami uvjereni da kvaliteta mastera u kojem je vaš master ostao nakon urezivanja omogućava vam da samouvjereno pritisnete dugme "Deploy" u pijani petak navečer. Kako to postižete? Kroz pregled, kroz pokrivenost, kroz dobro praćenje.
Dobro praćenje se ne razlikuje od testova. Ako jednom pokrenete testove na pre produ, onda oni jednom provjere sve vaše korisničke skripte i to je to. A ako ih pokrenete u beskonačnoj petlji, onda je ovo vaš raspoređeni sistem za praćenje, koji beskonačno sve testira - bilo da se srušilo ili ne. U ovom slučaju, jedina razlika je da li se to radi jednom ili dvaput. Vrlo dobar set testova... radi beskonačno, ovo je praćenje. A pravilno praćenje bi trebalo da bude ovako.
I zato, kako ćete tačno postići ovo stanje kada se spremite u petak uveče i odete kući, drugo je pitanje. Možda si samo hrabar ološ.
Vratimo se malo na kontinuiranu integraciju. Pobjegli smo u malo drugačiju složenu praksu.
A druga iluzija je da MVP, kažu, treba brzo da se uradi, pa tu testovi uopšte nisu potrebni. Ne sigurno na taj način. Činjenica je da kada napišete korisničku priču u MVP-u, možete je ili razviti na loptu, odnosno, čuli ste da postoji neka korisnička priča i odmah potrčali da je kodirate, ili možete raditi koristeći TDD. A prema TDD-u, kako praksa pokazuje, ne traje duže, odnosno testovi su nuspojava. Praksa TDD se ne odnosi na testiranje. Uprkos onome što se zove Test Driven Development, uopšte se ne radi o testovima. Ovo je također prije arhitektonski pristup. Ovo je pristup da se piše upravo ono što je potrebno, a ne da se piše ono što nije potrebno. Ovo je praksa fokusiranja na sljedeću iteraciju vašeg razmišljanja u smislu kreiranja arhitekture aplikacije.
Stoga se nije tako lako riješiti ovih iluzija. MVP i testovi nisu u suprotnosti. Čak, naprotiv, ako radite MVP koristeći TDD vežbu, onda ćete to raditi bolje i brže nego ako to radite bez vježbe, već na lopti.
Ovo je vrlo neočigledna i složena ideja. Kad čujete da ću sada pisati još testova, a istovremeno ću raditi nešto brže, zvuči apsolutno neadekvatno.
(Dmitry) Mnogi ljudi ovdje, kada zovu MVP-a, ljudi su previše lijeni da napišu nešto normalno. A to su još uvijek različite stvari. Nema potrebe da pretvarate MVP u neku lošu stvar koja ne radi.
Da, da, u pravu si.
A onda odjednom MVP u produkciji.
Zauvijek.
A TDD zvuči vrlo neobično kada čujete da pišete testove i čini se da radite više. Zvuči vrlo čudno, ali u stvari ovako ispada brže i ljepše. Kada pišete test, već dosta razmišljate u svojoj glavi o tome kako će se kod zvati i kako, kao i kakvo ponašanje očekujemo od njega. Ne kažete samo da sam napisao neku funkciju i ona nešto radi. Prvo ste mislili da ona ima takve i takve uslove, ona će biti pozvana na takav i takav način. Ovo pokrivate testovima i iz toga razumete kako će vaša sučelja izgledati unutar vašeg koda. Ovo ima veliki uticaj na arhitekturu. Vaš kod automatski postaje modularniji, jer prvo pokušavate da shvatite kako ćete ga testirati, pa tek onda napisati.
Ono što mi se dogodilo sa TDD-om je da sam u nekom trenutku unajmio Ruby mentora dok sam još bio Ruby programer. A on kaže: „Uradimo to prema TDD-u.“ Pomislio sam: „Prokletstvo, sad moram nešto dodatno da napišem.” I dogovorili smo se da ću u roku od dvije sedmice napisati sav radni kod u Python-u koristeći TDD. Posle dve nedelje, shvatio sam da ne želim da se vratim. Nakon dvije sedmice pokušaja da ovo svugdje primijenite, shvatite koliko vam je postalo lakše čak i samo razmišljati. Ali to nije očigledno, pa preporučujem svima da, ako imate osjećaj da je TDD težak, dugotrajan i nepotreban, pokušajte da ga se pridržavate samo dvije sedmice. Dva su mi bila dovoljna.
(Dmitrij) Ovu ideju možemo proširiti sa stanovišta funkcionisanja infrastrukture. Prije nego što pokrenemo bilo šta novo, vršimo monitoring, a zatim pokrećemo. U ovom slučaju, praćenje za nas postaje normalno testiranje. I postoji razvoj kroz praćenje. Ali skoro svi kažu da je dugo, ja sam lijen, napravio sam privremeni nacrt. Ako smo obavili normalno praćenje, razumijemo stanje CI sistema. A CI sistem ima dosta nadzora. Razumijemo stanje sistema, razumijemo šta je u njemu. I tokom razvoja mi samo pravimo sistem da dođe do željenog stanja.
Ove prakse su poznate od davnina. O tome smo razgovarali prije otprilike 4 godine. Ali za 4 godine se praktično ništa nije promijenilo.
Ali s tim u vezi, predlažem da završim zvaničnu diskusiju.
Video (umetnut kao medijski element, ali iz nekog razloga ne radi):
izvor: www.habr.com