Raspravimo zašto su CI alati i CI potpuno različite stvari.
Koju muku namjerava riješiti CI, odakle ideja, koje su zadnje potvrde da radi, kako razumjeti da imate praksu, a ne samo instaliranog Jenkinsa.
Ideja o izradi reportaže o Kontinuiranoj integraciji javila se prije godinu dana, kada sam išla na razgovore i tražila posao. Razgovarao sam s 10-15 tvrtki, samo je jedna od njih znala jasno odgovoriti što je CI i objasniti kako su shvatili da je nemaju. Ostali su pričali neshvatljive gluposti o Jenkinsu :) Pa imamo Jenkinsa, gradi se, CI! Tijekom izvješća pokušat ću objasniti što je zapravo kontinuirana integracija i zašto Jenkins i slični alati imaju vrlo slab odnos s tim.
Dakle, što vam obično padne na pamet kada čujete riječ CI? Većina ljudi pomislit će na Jenkinsa, Gitlab CI, Travisa itd.
Čak i ako guglamo, dat će nam ove alate.
Ako ste upoznati s pitanjem, odmah nakon popisa alata, reći će vam da je CI kada gradite i izvodite testove u Pull Requestu za commit.
Kontinuirana integracija se ne odnosi na alate, ne na sklopove s testovima u grani! Continuous Integration je praksa vrlo česte integracije novog koda i za njezino korištenje uopće nije potrebno ograditi Jenkins, GitLab itd.
Prije nego što shvatimo kako izgleda potpuni CI, prvo zaronimo u kontekst ljudi koji su ga osmislili i osjetimo bol koju su pokušavali riješiti.
I riješili su bol zajedničkog rada kao tima!
Pogledajmo primjere poteškoća s kojima se programeri susreću pri razvoju u timovima. Ovdje imamo projekt, 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, stvorili granu značajke i napisali kod.
Jedan je brže završio značajku i spojio je u master.
Drugom je trebalo više vremena, kasnije se spojilo i završilo sukobom. Sada, umjesto da piše značajke koje su potrebne poslovanju, programer troši svoje vrijeme i energiju na rješavanje sukoba.
Što je teže kombinirati vašu značajku sa zajedničkim majstorom, to više vremena trošimo na to. I to sam pokazao na prilično jednostavnom primjeru. Ovo je primjer u kojem postoje samo 2 programera. Zamislite da 10 ili 15 ili 100 ljudi u tvrtki piše u jedno spremište. Poludjet ćeš da riješiš sve te sukobe.
Postoji nešto drugačiji slučaj. Imamo majstora i neke programere koji nešto rade.
Stvorili su grančicu.
Jedan je umro, sve je bilo u redu, prošao je zadatak.
Drugi programer je u međuvremenu predao svoj zadatak. Recimo da ga je poslao na recenziju. Mnoge tvrtke imaju praksu koja se zove pregled. S jedne strane, ova praksa je dobra i korisna, s druge strane, usporava nas u mnogočemu. Nećemo ulaziti u to, ali evo sjajnog primjera do čega može dovesti priča o lošoj recenziji. Poslali ste zahtjev za povlačenje na pregled. Programer više ne može ništa učiniti. Što počinje raditi? Počinje preuzimati druge zadatke.
Tijekom tog vremena, drugi programer napravio je nešto drugo.
Prvi je završio treći zadatak.
I nakon dužeg vremena, njegova recenzija je testirana, i on se pokušava pomiriti. I što ima? Hvata ogroman broj sukoba. Zašto? Jer dok je njegov pull request visio u recenziji, dosta stvari se već promijenilo u kodu.
Osim priče sa sukobima, tu je i priča s komunikacijama. Dok vaša nit stoji na pregledu, dok nešto čeka, dok dugo radite na nekoj značajci, prestajete pratiti što se još mijenja u bazi koda vašeg servisa. Možda je ono što sada pokušavate riješiti već riješeno jučer i možete uzeti neku metodu i ponovno je upotrijebiti. 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 jedna osoba po repozitoriju, već 5-10 ljudi, onda što dulje ne dodamo naš kod u master, to više patimo jer nam u konačnici treba nešto onda to spoji. I što više sukoba imamo, i sa starijom verzijom radimo, imamo više problema.
Raditi nešto zajedno je bolno! Jedno drugom uvijek stojimo na putu.
Ovaj problem je uočen prije više od 20 godina. Prvo spominjanje prakse kontinuirane integracije pronašao sam u ekstremnom programiranju.
Extreme Programming je prvi agilni framework. Stranica se pojavila 96. godine. I ideja je bila koristiti nekakve prakse programiranja, planiranja i ostalog, kako bi razvoj bio što fleksibilniji, kako bismo mogli brzo odgovoriti na sve promjene ili zahtjeve naših klijenata. I s tim su se počeli suočavati prije 24 godine, da ako nešto radite jako dugo i sa strane, onda trošite više vremena na to jer imate sukobe.
Sada ćemo zasebno analizirati frazu "Kontinuirana integracija". Ako to izravno prevedemo, dobivamo kontinuiranu integraciju. Ali nije jasno koliko je kontinuiran; vrlo je diskontinuiran. No, koliko je integracija također nije baš očito.
I zato vam sada dajem citate iz Ekstremnog programiranja. I analizirat ćemo obje riječi odvojeno.
Integracija - Kao što sam već rekao, nastojimo osigurati da svaki inženjer radi s najnovijom verzijom koda, tako da nastoji što češće dodavati svoj kod u zajedničku granu, tako da su to male grane. Jer ako su velike, onda lako možemo zaglaviti sa sukobima spajanja tjedan dana. Ovo je posebno istinito ako imamo dug razvojni ciklus kao što je vodopad, gdje je programer otišao na mjesec dana kako bi smanjio neku veliku značajku. I on će zapeti u fazi integracije jako dugo.
Integracija je kada uzmemo našu granu i integriramo je s masterom, spojimo je. Postoji ultimativna opcija kada smo transbase programer, gdje nastojimo osigurati da odmah pišemo masteru bez dodatnih grananja.
Općenito, integracija znači uzeti svoj kod i povući ga u master.
Što se ovdje misli pod riječju "kontinuirano", što se zove kontinuitet? Praksa implicira da programer nastoji integrirati svoj kod što je brže moguće. To je njegov cilj pri obavljanju bilo kojeg zadatka - dovesti svoj kod u master što je brže moguće. U idealnom svijetu programeri bi to činili svakih nekoliko sati. Odnosno, uzmete mali problem i spojite ga u master. Sve je odlično. To je ono čemu težite. I to se mora činiti kontinuirano. Čim nešto napraviš, odmah to staviš u majstora.
A programer koji nešto napravi odgovoran je za ono što je napravio da to funkcionira i da ništa ne pokvari. Ovdje obično izlazi priča o testu. Želimo pokrenuti neke testove na našem predanju, na našem spajanju, kako bismo bili sigurni da radi. I tu vam Jenkins može pomoći.
Ali s pričama: neka promjene budu male, neka zadaci budu mali, napravimo problem i odmah ga pokušamo nekako ugraditi u master - tu nikakav Jenkins neće pomoći. Zato što će vam Jenkins samo pomoći u provođenju testova.
Možeš i bez njih. Ovo te uopće neće povrijediti. Jer cilj vježbe je što češće mjeriti, kako se u budućnosti ne bi gubilo ogromno vrijeme na bilo kakve konflikte.
Zamislimo da smo iz nekog razloga u 2020. bez interneta. I radimo lokalno. Nemamo Jenkinsa. Ovo je u redu. Još uvijek možete napraviti lokalni ogranak. Napisali ste neki kod u njemu. Zadatak smo izvršili za 3-4 sata. Prebacili smo se na master, napravili git pull i tamo spojili našu granu. Spreman. Ako to činite često, čestitamo, imate kontinuiranu integraciju!
Koji dokazi u suvremenom svijetu postoje da se na to isplati trošiti energiju? Jer općenito je teško. Ako pokušate raditi na ovaj način, shvatit ćete da će dio planiranja sada biti pogođen, morat ćete posvetiti više vremena razlaganju zadataka. Jer ako učiniš čovječe..., onda se nećeš moći brzo pomiriti i, shodno tome, doći ćeš u nevolju. Nećete više imati praksu.
I bit će skupo. Neće biti moguće odmah raditi od sutra koristeći kontinuiranu integraciju. Trebat će vam jako puno vremena da se naviknete na to, trebat će vam jako dugo vremena da se naviknete na dekomponiranje zadataka, bit će vam potrebno jako dugo vremena da se naviknete na ponavljanje prakse pregleda, ako ga imate . Jer cilj nam je da se danas otopi. A ako obavite pregled unutar tri dana, onda imate problema i Kontinuirana integracija vam ne radi.
No, imamo li trenutno relevantne dokaze koji nam govore da ulaganje u ovu praksu ima smisla?
Prvo što mi je palo na pamet je State of DevOps. Ovo je studija koju dečki provode 7 godina. Sada to rade kao neovisna organizacija, ali pod Googleom.
A njihova studija iz 2018. pokazala je korelaciju između tvrtki koje pokušavaju koristiti kratkotrajne podružnice koje se brzo integriraju, integriraju se često i imaju bolje IT pokazatelje performansi.
Koji su to pokazatelji? Ovo su 4 metrike koje uzimaju od svih tvrtki u svojim upitnicima: učestalost implementacije, vrijeme potrebno za promjene, vrijeme za ponovno uspostavljanje usluge, stopa neuspjeha promjena.
I, kao prvo, postoji ta korelacija, znamo da tvrtke koje često mjere imaju mnogo bolju metriku. I oni imaju podjelu tvrtki u nekoliko kategorija: to su spore tvrtke koje nešto sporo proizvode, srednje performanse, visoke performanse i elita. Elita su Netflix, Amazon, koji su super brzi, rade sve brzo, lijepo i učinkovito.
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 ogranci izdanja koji žive dugo vremena i značajni ogranci koji također žive dugo vremena. Ova praksa u Technology Radaru prešla je na HOLD. Zašto? Jer ljudi se suočavaju s boli integracije.
Ako vaša grana živi jako dugo, zaglavi, pokvari se, a mi počnemo trošiti više vremena pokušavajući napraviti neku vrstu promjene na njoj.
A nedavno je autor Gitflowa rekao da ako je vaš cilj kontinuirana integracija, ako vam je cilj da se želite vrtjeti što je češće moguć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 stvoriti probleme s integracijom.
To ne znači da je Gitflow loš i da ga ne treba koristiti. To je za druge prilike. Na primjer, kada trebate podržati nekoliko verzija usluge ili aplikacije, tj. kada vam je potrebna podrška na duži vremenski period.
Ali ako razgovarate s ljudima koji podržavaju takve usluge, čut ćete mnogo boli o činjenici da je ova verzija bila 3.2, što je bilo prije 4 mjeseca, ali ovaj popravak nije bio uključen u nju i sada, da bi to napravio, morate napraviti hrpu promjena. A sada su opet zapeli i sada se petljaju tjedan dana pokušavajući implementirati neku novu značajku.
Kao što je Alexander Kovalev ispravno primijetio u chatu, korelacija nije isto što i uzročnost. To je istina. Odnosno, nema izravne veze da će sve metrike biti izvrsne ako imate kontinuiranu integraciju. Ali postoji pozitivna korelacija da ako je jedan jedan, onda je najvjerojatnije i drugi. Nije činjenica, ali najvjerojatnije. To je samo korelacija.
Čini se da već nešto radimo, čini se da se već spajamo, ali kako shvatiti da još uvijek imamo Kontinuiranu integraciju, da se dosta često spajamo?
Jez Humble autor je priručnika, Accelerate, web stranice Continuous Delivery i knjige Continuous Delivery. On nudi ovaj test:
- Šifra inženjera dolazi majstoru svaki dan.
- Za svaki commit izvodite jedinične testove.
- Gradnja u majstoru je pala, popravljeno je za 10-ak minuta.
Predlaže korištenje ovakvog testa kako biste bili sigurni da imate dovoljno prakse.
Ovo drugo smatram malo kontroverznim. Odnosno, ako to možete popraviti za 10 minuta, onda imate Continuous Integration, zvuči malo čudno, po meni, ali ima smisla. Zašto? Jer ako često zamrzavate, to znači da su vaše promjene male. Ako mala promjena znači da je vaša glavna verzija pokvarena, tada možete brzo pronaći primjer jer je promjena mala. Ovdje ste imali malo spajanje, promijenilo se 20-30 redaka. I, sukladno tome, možete brzo shvatiti koji je razlog, jer su promjene male, imate vrlo malo područje za traženje problema.
Čak i ako se naš proizvod raspadne nakon izdavanja, onda ako imamo praksu kontinuirane integracije, puno nam je lakše djelovati, jer su promjene malene. Da, to će utjecati na planiranje. Ovo će boljeti. I, vjerojatno, najteža stvar u ovoj praksi je naviknuti se na raščlanjivanje zadataka, odnosno kako to učiniti tako da nešto uzmete i napravite za nekoliko sati i pritom prođete pregled, ako imate jedan. Pregled je zasebna boljka.
Unit testovi su samo pomoćnik koji vam pomaže da shvatite je li vaša integracija bila uspješna i je li se nešto pokvarilo. Po mom mišljenju, ni to nije sasvim obavezno, jer to nije smisao prakse.
Ovo je kratki uvod u kontinuiranu integraciju. To je sve što se tiče ove prakse. Spreman sam za pitanja.
Opet ću samo ukratko rezimirati:
- Kontinuirana integracija nije Jenkins, nije Gitlab.
- Ovo nije alat, praksa je da stapamo svoj kod u master što je češće moguće.
- To činimo kako bismo izbjegli ogromnu bol koja nastaje spajanjem u budućnosti, odnosno, sada doživljavamo malu bol kako ne bismo doživjeli još više u budućnosti. To je cijela poanta.
- Sa strane postoji komunikacija preko koda, ali ja to jako rijetko vidim, ali za to je i dizajniran.
pitanja
Što učiniti s nerazloženim zadacima?
razgraditi. U čemu je problem? Možete li dati primjer da postoji zadatak, a da nije dekomponiran?
Postoje zadaci koji se ne mogu raščlaniti iz riječi "u potpunosti", na primjer, oni koji zahtijevaju vrlo duboku stručnost i koji se zapravo mogu riješiti tijekom mjesec dana da bi se postigao neki probavljivi rezultat.
Ako sam vas dobro razumio, onda postoji neki veliki i složen zadatak čiji će rezultat biti vidljiv tek za mjesec dana?
Da, tako je. Da, bit će moguće procijeniti rezultat najkasnije za mjesec dana.
Fino. Općenito to nije problem. Zašto? Jer u ovom slučaju, kada govorimo o grančicama, ne govorimo o grančici s obilježjem. Značajke mogu biti velike i složene. Mogu utjecati na veliki broj komponenti. A možda ih ne možemo učiniti u potpunosti u jednoj grani. Ovo je u redu. Samo trebamo rastaviti ovu priču. Ako značajka nije potpuno spremna, to ne znači da se neki dijelovi njezinog koda ne mogu spojiti. Dodali ste, recimo, migraciju i postoje neke faze unutar značajke. Recimo da imate fazu - napravite migraciju, dodajte novu metodu. A te stvari već možete mjeriti svaki dan.
Fino. U čemu je onda smisao?
Koja je svrha ubijati male stvari svaki dan?
Da.
Ako nešto razbiju, odmah se vidi. Imate mali komad koji je nešto pokvario, lakše ćete to popraviti. Poanta je da je sada puno lakše spojiti mali dio nego spojiti nešto veliko za nekoliko tjedana. I treća točka je da će drugi inženjeri raditi s trenutnom verzijom koda. Vidjet će da su ovdje dodane neke migracije, a zatim se pojavila neka metoda koju bi i oni željeli koristiti. Svi će vidjeti što se događa u vašem kodu. Za ove tri stvari se vježba.
Hvala, problem je zatvoren!
(Oleg Soroka) Mogu li dodati? Sve si dobro rekao, samo da dodam jednu rečenicu.
So.
Uz kontinuiranu integraciju, kod se spaja u zajedničku granu ne kada je značajka potpuno spremna, već kada se verzija prestane kvariti. I možete se sa sigurnošću posvetiti svladavanju koliko god puta dnevno želite. Drugi aspekt je da ako iz nekog razloga ne možete podijeliti mjesečni zadatak na zadatke barem tri dana, šutim oko tri sata, onda imate veliki problem. A činjenica da nemate kontinuiranu integraciju najmanji je od ovih problema. To znači da imate problema s arhitekturom i nultom inženjerskom praksom. Jer čak i ako je ovo istraživanje, onda ono u svakom slučaju mora biti formulirano u obliku hipoteza ili ciklusa.
Razgovarali smo o 4 metrike koje razlikuju uspješne tvrtke od onih koje zaostaju. Još uvijek moramo živjeti da vidimo ova 4 metrička pokazatelja. Ako je vašem prosječnom zadatku potrebno mjesec dana, tada bih se prvo usredotočio na ovu metriku. Ja bih prvo spustio na 3 dana. I nakon toga sam počeo razmišljati o Continuousu.
Jesam li vas dobro razumio da mislite da općenito nema smisla ulagati u inženjersku praksu ako se za bilo koji zadatak treba mjesec dana?
Imate kontinuiranu integraciju. I postoji takva tema da u 10 minuta možete ili popraviti popravak ili ga vratiti. Zamislite da ste ga izbacili. Štoviše, imate čak i kontinuiranu implementaciju, izbacili ste je na prod i tek tada primijetili da je nešto pošlo po zlu. I trebate ga vratiti, ali već ste migrirali svoju bazu podataka. Već imate shemu baze podataka sljedeće verzije, štoviše, imali ste i neku vrstu sigurnosne kopije, a podaci su također tamo zapisani.
I koju alternativu imate? Ako vratite kod, on više ne može raditi s ovom ažuriranom bazom podataka.
Baza se pomiče samo naprijed, da.
Ljudi koji imaju lošu inženjersku praksu najvjerojatnije nisu ni pročitali debelu knjigu o... Što učiniti sa sigurnosnom kopijom? Ako vraćate iz sigurnosne kopije, to znači da gubite podatke koje ste nakupili u tom trenutku. Na primjer, tri sata smo radili s novom verzijom baze, korisnici su se tamo registrirali. Odbijate staru sigurnosnu kopiju jer shema ne radi s novom verzijom, pa ste izgubili te korisnike. I oni su nezadovoljni, psuju.
Kako biste svladali cijeli niz praksi koje podržavaju kontinuiranu integraciju i kontinuiranu isporuku, nije dovoljno samo naučiti pisati.... Prvo, može ih biti puno, bit će nepraktično. Osim toga, postoji hrpa drugih praksi kao što je Scientific. Postoji takva praksa, GitHub ju je svojedobno popularizirao. To je kada imate i stari i novi kod koji se izvode u isto vrijeme. To je kada napravite nedovršenu značajku, ali ona može vratiti neku vrijednost: bilo kao funkcija ili kao Rest API. Izvršavate i novi kod i stari kod i uspoređujete razliku između njih. A ako postoji razlika, onda zapisujete ovaj događaj. Na taj način znate da imate novu značajku spremnu za uvođenje povrh stare ako niste imali odstupanja između te dvije određeno vrijeme.
Postoje stotine takvih praksi. Predlažem da počnete s transbase razvojem. Ona nije 100% na kontinuiranoj integraciji, ali prakse su iste, jedno ne može dobro živjeti bez drugog.
Jeste li dali transbase development kao primjer gdje možete vidjeti praksu ili predlažete ljudima da 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: "Što učiniti sa značajkom koja traje mjesec dana, to znači da nije čitala o transbase razvoju." Još ga ne bih preporučio. Savjetovao bih da se usredotočite isključivo na temu kako ispravno arhitektonski rastaviti velike zadatke na manje. Ovo je bit razgradnje.
Dekompozicija je jedan od alata arhitekta. Prvo radimo analizu, zatim dekompoziciju, zatim sintezu, pa integraciju. I ovako nam sve ide. I dalje trebamo rasti do kontinuirane integracije kroz dekompoziciju. Pitanja se javljaju kod prve faze, a već govorimo o četvrtoj fazi, odnosno što češće radimo integraciju, to bolje. Još je prerano za to; bilo bi lijepo da prvo posječete svoj monolit.
Morate nacrtati niz 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 je zeleni gumb za aplikaciju. U svakom slučaju bit će više kvadrata i strelica. Svaki dijagram koji sam vidio imao je više od jednog. A dekompozicija, čak i na razini grafičkog prikaza, već se događa. Stoga se kvadrati mogu učiniti neovisnima. Ako ne, onda imam velika pitanja za arhitekta.
Postoji pitanje iz chata: "Ako je pregled obavezan i traje dugo, možda dan ili više?"
Imate problema s praksom. Pregled ne bi trebao trajati dan ili više. Ovo je ista priča kao i prethodno pitanje, samo malo blaže. Ako pregled traje jedan dan, onda se najvjerojatnije ovaj pregled događa zbog neke velike promjene. To znači da ga treba smanjiti. U transbase razvoju, koji je Oleg preporučio, postoji priča koja se zove kontinuirani pregled. Njezina je ideja da tako mali zahtjev za povlačenjem napravimo namjerno, jer težimo spajanju stalno i malo po malo. I tako zahtjev za povlačenjem mijenja jednu apstrakciju ili 10 redaka. 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 s arhitekturom. Ili je ovo velik dio koda, 1 redaka, na primjer. Ili je vaša arhitektura toliko složena da je čovjek ne može razumjeti. Ovo je malo usputan problem, ali i njega će se morati riješiti. Možda uopće nema potrebe za pregledom. Moramo razmisliti i o ovome. Pregled je ono što vas usporava. Općenito ima svojih prednosti, ali morate razumjeti zašto to radite. Je li to način da brzo prenesete informacije, je li to način da interno postavite neke standarde ili što? Zašto ti ovo treba? Jer pregled treba obaviti ili vrlo brzo ili u potpunosti otkazati. To je kao transbase deveploment - priča je vrlo lijepa, ali samo za zrele dečke.
Što se tiče 4 metrike, ipak bih preporučio njihovo uklanjanje kako biste razumjeli čemu to vodi. Pogledajte brojke, pogledajte sliku, kako je sve loše.
(Dmitrij) Spreman sam ući u raspravu o tome s vama. Brojevi i metrika su sjajni, praksa je sjajna. Ali morate razumjeti treba li to poslu. Postoje tvrtke kojima nije potrebna takva brzina promjena. Znam tvrtke u kojima se promjene ne mogu raditi svakih 15 minuta. I ne zato što su tako loši. Ovo je takav životni ciklus. A da biste napravili značajku grana, značajku prebacivanja, potrebno vam je duboko znanje.
Komplicirano je. Ako želite detaljnije pročitati priču o značajci prebacivanja, toplo je preporučujem . Postoji prekrasan članak Martina Fowlera o značajkama preklopnika: koje vrste postoje, životnim ciklusima itd. Značajka preklopnika je komplicirana.
I još uvijek niste odgovorili na pitanje: "Je li Jenkins potreban ili ne?"
Jenkins u svakom slučaju zapravo nije potreban. Ali ozbiljno, alati: Jenkins, Gitlab će vam donijeti pogodnost. Vidjet ćete da je sklop sastavljen ili nije sastavljen. Oni vam mogu pomoći, ali vam neće dati praksu. Mogu vam dati samo krug - Ok, ne Ok. A onda, ako pišete i 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, znači li to da vam ne treba?
Tako je. Preporučam Jez Humble test. Tu prema zadnjoj točki imam ambivalentan stav. Ali općenito, ako imate tri stvari, stalno stapate, izvodite testove na komitima u masteru, brzo popravljate izgradnju u masteru, onda vam možda ne treba ništa drugo.
Dok čekamo pitanja sudionika, imam jedno pitanje. Upravo smo razgovarali o šifri proizvoda. Jeste li ga koristili za infrastrukturni kod? Je li to isti kod, ima li ista načela i isti životni ciklus ili postoje različiti životni ciklusi i principi? Obično, kada svi govore o kontinuiranoj integraciji i razvoju, svi zaborave da postoji i infrastrukturni kod. A u zadnje vrijeme toga je sve više. I treba li sva ta pravila tamo donijeti?
Čak ni da bi trebalo biti, bilo bi super jer bi na isti način olakšalo život. Čim radimo s kodom, ne s bash skriptama, ali imamo normalan kod.
Stani, stani, bash skripta je također kod. Ne diraj moju staru ljubav.
Dobro, neću gaziti tvoja sjećanja. Osobno ne volim bash. Lomi se ružno i strašno cijelo vrijeme. I često se nepredvidivo pokvari, zato ga ne volim. Ali u redu, recimo da imate bash kod. Možda stvarno ne razumijem i postoje normalni okviri za testiranje. Samo nisam upućen. I dobivamo iste beneficije.
Čim radimo s infrastrukturom kao kodom, imamo iste probleme kao i programeri. Prije nekoliko mjeseci susreo sam se sa situacijom u kojoj mi je kolega poslao zahtjev za povlačenjem 1 redaka u bashu. I visiš na smotri 000 sata. Javljaju se isti problemi. Još uvijek je šifra. I dalje je to suradnja. Zapeli smo sa zahtjevom za povlačenjem i zapeli smo s činjenicom da rješavamo iste sukobe spajanja u istom bashu, na primjer.
Sada vrlo aktivno gledam cijelu ovu stvar na najljepšem infra programiranju. Sada sam Pulumija uveo u infrastrukturu. Ovo je programiranje u svom najčišćem obliku. Tu je još ljepše, jer imam sve mogućnosti programskog jezika, tj. napravio sam prekrasan prekidač iz vedra neba s istim if-ovima i sve je u redu. Odnosno, moj kusur je već u masteru. Svi ga već mogu vidjeti. Drugi inženjeri znaju za to. Tu je već nešto utjecalo. Međutim, nije bio omogućen za sve infrastrukture. Uključio se na mojim ispitnim stolovima, na primjer. Stoga je potrebno ponovno odgovoriti na vaše pitanje. To olakšava život nama, kao inženjerima koji rade s kodom, na isti način.
Ako još netko ima pitanja?
Imam pitanje. Želim nastaviti raspravu s Olegom. Općenito, mislim da ste u pravu, da ako zadatak traje mjesec dana da se završi, onda imate problem s arhitekturom, imate problem s analizom, dekompozicijom, planiranjem itd. Ali imam osjeć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 usporediva je u naporima s bilo kojom drugom ozbiljnom praksom koja mijenja kulturu. Najteže je riješiti se navika, pogotovo loših. A ako je za implementaciju ove prakse potrebna ozbiljna promjena navika onih oko vas: programera, uprave, voditelja proizvodnje, onda vas čekaju iznenađenja.
Kakva bi iznenađenja mogla biti? Recimo da odlučite da ćete se češće integrirati. A imate i neke druge stvari vezane uz integraciju, na primjer, artefakte. A u vašoj tvrtki, na primjer, postoji politika da svaki artefakt mora biti evidentiran na neki način u nekoj vrsti sustava za pohranu artefakata. I potrebno je neko vrijeme. Osoba treba označiti okvir da je on, kao voditelj izdanja, testirao ovaj artefakt kako bi osigurao da je spreman za puštanje u proizvodnju. Ako vam treba 5-10-15 minuta, ali radite raspored jednom tjedno, onda je trošenje pola sata jednom tjedno mali porez.
Ako radite kontinuiranu integraciju 10 puta dnevno, tada 10 puta treba pomnožiti s 30 minuta. A to premašuje količinu radnog vremena ovog upravitelja 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. ne dodjeljujete ručno diplomu koja odgovara nečemu. U potpunosti se oslanjate na neki automatizirani skup testova spremnosti.
A ako vam treba dokaz od nekoga, tako da ga šef potpiše, a vi ne ulazite u proizvodnju, a da Vasja ne kaže da on to dopušta itd. - sve te gluposti staju na put praktičaru. Jer ako su neke aktivnosti povezane s porezom, onda se sve povećava 100 puta. Stoga smjenu često neće svi dočekati s radošću. Zato što se ljudske navike teško mijenjaju.
Kada osoba radi svoj uobičajeni posao, radi ga gotovo bez razmišljanja. Njezino kognitivno opterećenje je nula. On se samo igra s tim, već ima popis u glavi, učinio je to tisuću puta. I čim dođete i kažete mu: "Otkažimo ovu praksu i uvedimo novu od ponedjeljka", za njega to postaje snažno kognitivno opterećenje. I dođe svima odjednom.
Stoga, najjednostavnija stvar, iako si ne može svatko priuštiti ovaj luksuz, ali to je ono što ja uvijek radim, ovo je sljedeće. Ako se započne s novim projektom, onda se obično sve neprovjerene prakse odmah utrpaju u ovaj projekt. Iako je projekt mlad, zapravo ništa ne riskiramo. Još nema Proda, nema se što uništiti. Stoga se može koristiti kao trening. Ovaj pristup funkcionira. Ali nemaju sve tvrtke priliku često pokretati takve projekte. Iako je i to malo čudno, jer sada je u tijeku potpuna digitalna transformacija, svatko mora pokrenuti eksperimente kako bi držao korak s konkurencijom.
Ovdje dolazite do zaključka da prvo morate razumjeti što trebate učiniti. Svijet nije idealan, a ni prod nije idealan.
Da, te stvari su međusobno povezane.
Poduzeća također ne razumiju uvijek da moraju ići tim putem.
Postoji situacija u kojoj nikakve promjene nisu moguće. Ovo je situacija u kojoj je veći pritisak na momčad. Ekipa je već poprilično izgorjela. Ona nema slobodnog vremena za bilo kakve eksperimente. Na karakteristikama rade od jutra do večeri. A upravljanje ima sve manje značajki. Potrebno je sve više i više. U takvoj situaciji nikakve promjene nisu moguće. Timu se može samo reći da ćemo sutra raditi isto što i jučer, samo trebamo napraviti malo više mogućnosti. U tom smislu, nikakvi prijelazi u bilo kakve prakse nisu mogući. Ovo je klasična situacija kad se nema vremena naoštriti sjekiru, treba posjeći drveće, pa ga sjeku tupom sjekirom. Ovdje nema jednostavnih savjeta.
(Dmitrij) Pročitat ću pojašnjenje iz chata: "Ali potrebno nam je mnogo pokrivenosti testovima na različitim razinama. Koliko je vremena predviđeno za testove? Malo je skupo i oduzima puno vremena.”
(Oleg) Ovo je klasična zabluda. Trebalo bi biti dovoljno testova da biste bili sigurni. Kontinuirana integracija nije stvar gdje se prvo napravi 100% testova pa tek onda počnete primjenjivati ovu praksu. Kontinuirana integracija smanjuje vaše kognitivno opterećenje zbog činjenice da je svaka promjena koju vidite svojim očima toliko očita da znate hoće li nešto pokvariti ili ne, čak i bez testova. To možete brzo testirati u svojoj glavi jer su promjene male. Čak i ako imate samo ručne testere, i njima je lakše. Otkotrljali ste se i rekli: "Vidi, je li nešto pokvareno?" Provjerili su i rekli: "Ne, ništa nije pokvareno." Jer tester zna gdje treba tražiti. Imate jedan commit povezan s jednim dijelom koda. I to se iskorištava specifičnim ponašanjem.
Ovdje ste, naravno, uljepšali.
(Dmitrij) Tu se ne slažem. Postoji praksa - testni razvoj, koji će vas spasiti od ovoga.
(Oleg) Pa, još nisam došao do te točke. Prva iluzija je da trebate napisati 100% testova ili uopće ne morate raditi kontinuiranu integraciju. To nije istina. To su dvije paralelne prakse. I nisu izravno ovisni. Vaša pokrivenost testom trebala bi biti optimalna. Optimalno - to znači da ste sami uvjereni da vam kvaliteta mastera u kojem je vaš master ostao nakon predaje omogućuje da samouvjereno pritisnete gumb "Deploy" u pijani petak navečer. Kako to postižete? Kroz pregled, kroz pokrivenost, kroz dobar monitoring.
Dobro praćenje ne razlikuje se od testova. Ako jednom pokrenete testove na pre prod-u, oni jednom provjeravaju sve vaše korisničke skripte i to je to. A ako ih pokrenete u beskonačnoj petlji, onda je ovo vaš implementirani sustav nadzora, koji beskonačno testira sve - bez obzira je li se srušilo ili ne. U ovom slučaju razlika je samo u tome radi li se to jednom ili dvaput. Vrlo dobar set testova... radi se beskrajno, ovo je praćenje. I pravilno praćenje trebalo bi biti ovakvo.
I stoga, kako ćete točno postići to stanje kada se u petak navečer spremite i odete kući, drugo je pitanje. Možda si samo drsko smeće.
Vratimo se malo na kontinuiranu integraciju. Pobjegli smo u malo drugačiju složenu praksu.
A druga je iluzija da MVP, kažu, treba napraviti brzo, pa tamo pretrage uopće nisu potrebne. Ne sigurno na taj način. Činjenica je da kada pišete korisničku priču u MVP-u, možete je razvijati na brzinu, odnosno čuli ste da postoji neka korisnička priča i odmah ste je otrčali kodirati, ili možete raditi koristeći TDD. A prema TDD-u, kao što praksa pokazuje, ne traje duže, tj. Testovi su nuspojava. Praksa TDD-a nije testiranje. Unatoč onome što se naziva Test Driven Development, uopće se ne radi o testovima. Ovo je također više arhitektonski pristup. Ovo je pristup pisanju točno onoga što je potrebno, a ne pisanju onoga što nije potrebno. Ovo je praksa fokusiranja na sljedeću iteraciju vašeg razmišljanja u smislu stvaranja arhitekture aplikacije.
Stoga se nije tako lako osloboditi tih iluzija. MVP i testovi nisu u suprotnosti. Čak, naprotiv, ako radiš MVP koristeći TDD vježbu, onda ćeš to raditi bolje i brže nego da to radiš bez vježbe, već na lopti.
Ovo je vrlo neočita i složena ideja. Kad čujete da ću sada pisati više testova, a u isto vrijeme ću nešto raditi brže, to zvuči apsolutno neadekvatno.
(Dmitrij) Mnogi ljudi ovdje, kada zovu MVP, ljudi su previše lijeni da napišu nešto normalno. A to su ipak različite stvari. Nema potrebe pretvarati MVP u neku lošu stvar koja ne radi.
Da, da, u pravu ste.
I onda odjednom MVP u prod.
Zauvijek i uvijek.
I TDD zvuči vrlo neobično kada čujete da pišete testove i čini se da radite više. Zvuči jako čudno, ali zapravo ovako ispadne brže i ljepše. Kada pišete test, već uveliko razmišljate u glavi o tome koji će se kod i kako zvati, kao i kakvo ponašanje od njega očekujemo. Ne kažete samo da sam napisao neku funkciju i ona nešto radi. Prvo ste mislili da ona ima takve i takve uvjete, bit će pozvana na takav i takav način. To pokrivate testovima i iz toga razumijete kako će vaša sučelja izgledati unutar vašeg koda. To ima ogroman utjecaj na arhitekturu. Vaš kod automatski postaje više modularan, jer prvo pokušavate razumjeti kako ćete ga testirati, a tek onda napisati.
Ono što mi se dogodilo s TDD-om je da sam u nekom trenutku zaposlio Ruby mentora dok sam još bio Ruby programer. A on kaže: "Učinimo to prema TDD-u." Pomislio sam: "Dovraga, sad moram nešto dodatno napisati." I dogovorili smo se da ću u roku od dva tjedna napisati sav radni kod u Pythonu koristeći TDD. Nakon dva tjedna shvatio sam da se ne želim vratiti. Nakon dva tjedna pokušaja da ovo primijenite posvuda, shvatite koliko vam je postalo lakše čak i samo razmišljati. Ali to nije očito, stoga preporučujem svima da, ako imate osjećaj da je TDD težak, dugotrajan i nepotreban, pokušajte ga se držati samo dva tjedna. Dvije su mi bile dovoljne.
(Dmitrij) Ovu ideju možemo proširiti sa stajališta rada infrastrukture. Prije nego što lansiramo bilo što novo, vršimo nadzor i zatim lansiramo. U ovom slučaju praćenje za nas postaje normalno testiranje. I postoji razvoj kroz praćenje. Ali gotovo svi kažu da je dugo, lijen sam, napravio sam privremeni nacrt. Ako smo obavili normalno praćenje, razumijemo stanje CI sustava. I CI sustav ima puno nadzora. Razumijemo stanje sustava, razumijemo što je unutar njega. A tijekom razvoja samo izrađujemo sustav da dođe do željenog stanja.
Ove prakse poznate su dugo vremena. Razgovarali smo o tome prije otprilike 4 godine. Ali u 4 godine praktički se ništa nije promijenilo.
Ali na ovoj bilješci, predlažem da završimo službenu raspravu.
Video (umetnut kao medijski element, ali iz nekog razloga ne radi):
Izvor: www.habr.com