Pogovorimo se o tem, zakaj so orodja CI in CI popolnoma različni stvari.
Katero bolečino naj bi rešil CI, od kod ideja, kakšne so zadnje potrditve, da deluje, kako razumeti, da imaš prakso in ne samo nameščenega Jenkinsa.
Ideja o pripravi reportaže o Nenehni integraciji se je pojavila pred enim letom, ko sem hodila na razgovore in iskala službo. Pogovarjal sem se z 10-15 podjetji, samo eno je znalo jasno odgovoriti, kaj je KI in razložiti, kako so ugotovili, da ga nimajo. Ostali so govorili nerazumljive neumnosti o Jenkinsu :) No, imamo Jenkinsa, se gradi, CI! Med poročilom bom skušal razložiti, kaj pravzaprav je neprekinjena integracija in zakaj imajo Jenkins in podobna orodja s tem zelo šibek odnos.
Torej, na kaj običajno pomislite, ko slišite besedo CI? Večina ljudi bo pomislila na Jenkinsa, Gitlab CI, Travisa itd.
Tudi če poguglamo, nam bo dalo ta orodja.
Če ste seznanjeni s spraševanjem, vam bodo takoj po seznamu orodij povedali, da je CI, ko gradite in izvajate teste v zahtevi za vlečenje za objavo.
Nenehna integracija ne gre za orodja, ne za sklope s testi v veji! Nenehna integracija je praksa zelo pogoste integracije nove kode in za njeno uporabo sploh ni treba ograjevati Jenkins, GitLab itd.
Preden ugotovimo, kako izgleda popolna CI, se najprej potopimo v kontekst ljudi, ki so si jo zamislili, in občutimo bolečino, ki so jo poskušali rešiti.
In rešili so bolečino sodelovanja kot ekipa!
Oglejmo si primere težav, s katerimi se srečujejo razvijalci pri razvoju v skupinah. Tukaj imamo projekt, glavno vejo v git in dva razvijalca.
In so se lotili dela, kot so bili vsi že zdavnaj vajeni. Prevzeli smo nalogo v veliki shemi stvari, ustvarili vejo funkcij in napisali kodo.
Eden je hitreje dokončal funkcijo in jo združil v master.
Drugi je potreboval več časa, kasneje se je združil in končal s konfliktom. Zdaj razvijalec namesto pisanja funkcij, ki jih podjetje potrebuje, porabi svoj čas in energijo za reševanje sporov.
Težje kot je združiti svojo lastnost s skupnim mojstrom, več časa porabimo za to. In to sem pokazal na dokaj preprostem primeru. To je primer, ko sta razvijalca samo 2. Predstavljajte si, da 10 ali 15 ali 100 ljudi v podjetju piše v en repozitorij. Ponoreli boste, da boste rešili vse te konflikte.
Obstaja nekoliko drugačen primer. Imamo mojstra in nekaj razvijalcev, ki nekaj delajo.
Ustvarili so vejico.
Eden je umrl, vse je bilo v redu, opravil je nalogo.
Drugi razvijalec je medtem predal svojo nalogo. Recimo, da ga je poslal v pregled. Mnoga podjetja imajo prakso, imenovano pregled. Po eni strani je ta praksa dobra in koristna, po drugi pa nas v marsičem upočasnjuje. Ne bomo se spuščali v to, toda tukaj je odličen primer, do česa lahko privede zgodba o slabi recenziji. Poslali ste zahtevo za vleko v pregled. Razvijalec nima več kaj storiti. Kaj začne delati? Začne prevzemati druge naloge.
V tem času je drugi razvijalec naredil nekaj drugega.
Prvi je opravil tretjo nalogo.
In po dolgem času je bil njegov pregled preizkušen in poskuša se sprijazniti. Torej, kaj se dogaja? Ujame ogromno konfliktov. Zakaj? Ker medtem ko je njegov pull request visel v pregledu, se je v kodi že marsikaj spremenilo.
Poleg zgodbe s konflikti je zgodba s komunikacijami. Medtem ko vaša nit visi na pregledu, medtem ko nekaj čaka, medtem ko dolgo delate na funkciji, nehate slediti, kaj se še spreminja v kodni bazi vaše storitve. Morda je bilo to, kar poskušate rešiti zdaj, že rešeno včeraj in lahko izberete neko metodo in jo znova uporabite. Vendar tega ne boste videli, ker vedno delate z zastarelo vejo. In ta zastarela veja vedno povzroči, da morate razrešiti spor združevanja.
Izkazalo se je, da če delamo kot ekipa, tj. po repozitoriju ne brska ena oseba, ampak 5-10 ljudi, dlje ko ne dodajamo svoje kode v master, bolj trpimo, ker na koncu potrebujemo nekaj potem združi. In več ko imamo konfliktov in s starejšo različico delamo, več težav imamo.
Početi nekaj skupaj je boleče! Drug drugemu smo vedno v napoto.
Ta problem je bil opažen pred več kot 20 leti. Prvo omembo prakse kontinuirane integracije sem našel v ekstremnem programiranju.
Extreme Programming je prvo agilno ogrodje. Stran se je pojavila leta 96. In ideja je bila, da uporabimo nekakšne programerske prakse, načrtovanje in drugo, da bi bil razvoj čim bolj fleksibilen, da bi se lahko hitro odzvali na morebitne spremembe ali zahteve naših strank. In s tem so se začeli soočati pred 24 leti, da če nekaj delaš zelo dolgo in ob strani, potem za to porabiš več časa, ker imaš konflikte.
Zdaj bomo posamezno analizirali frazo »Neprekinjena integracija«. Če ga neposredno prevedemo, dobimo kontinuirano integracijo. Toda kako neprekinjen je, ni zelo jasno; je zelo prekinjen. Toda koliko integracije ima, tudi ni zelo očitno.
In zato vam zdaj ponujam citate iz Ekstremnega programiranja. In obe besedi bomo analizirali ločeno.
Integracija - Kot sem že rekel, stremimo k temu, da vsak inženir dela z najnovejšo različico kode, tako da stremi k temu, da svojo kodo čim pogosteje doda v skupno vejo, tako da so to majhne veje. Kajti če so veliki, se lahko zlahka zataknemo s spori spajanja za en teden. To še posebej velja, če imamo dolg razvojni cikel, kot je slap, ko je razvijalec odšel za en mesec, da bi zmanjšal neko ogromno funkcijo. In na stopnji integracije bo obtičal zelo dolgo.
Integracija je, ko vzamemo svojo vejo in jo integriramo z glavnim, jo združimo. Obstaja ultimativna možnost, ko smo transbase razvijalec, kjer si prizadevamo zagotoviti, da takoj pišemo masterju brez dodatnih vej.
Na splošno integracija pomeni, da vzamete svojo kodo in jo povlečete v master.
Kaj je tukaj mišljeno z besedo "neprekinjeno", kaj se imenuje kontinuiteta? Praksa pomeni, da si razvijalec prizadeva čim hitreje integrirati svojo kodo. To je njegov cilj pri opravljanju katere koli naloge - čim hitreje spraviti svojo kodo v master. V idealnem svetu bi razvijalci to počeli vsakih nekaj ur. To pomeni, da vzamete majhen problem in ga združite v glavnega. Vse je super. To je tisto, za kar si prizadevate. In to je treba početi nenehno. Takoj, ko nekaj narediš, takoj daš v master.
In razvijalec, ki nekaj naredi, je odgovoren za to, kar je naredil, da je delovalo in ni ničesar pokvaril. Tukaj običajno izide zgodba o testu. Želimo izvesti nekaj testov na naši objavi, na našem spajanju, da se prepričamo, ali deluje. In tukaj vam lahko pomaga Jenkins.
Ampak z zgodbami: naredimo spremembe majhne, pustimo, da so naloge majhne, naredimo problem in ga takoj poskušajmo nekako vgraditi v master - tukaj noben Jenkins ne bo pomagal. Ker vam bo Jenkins pomagal izvajati samo teste.
Brez njih lahko. To te ne bo nič prizadelo. Kajti cilj vadbe je meriti čim pogosteje, da ne bi v prihodnje izgubljali ogromno časa za morebitne konflikte.
Predstavljajmo si, da smo leta 2020 iz neznanega razloga brez interneta. In delamo lokalno. Nimamo Jenkinsa. To je v redu. Še vedno lahko naredite lokalno podružnico. Vanjo ste napisali kodo. Nalogo smo opravili v 3-4 urah. Preklopili smo na master, izvedli git pull in tam združili našo vejo. pripravljena Če to počnete pogosto, čestitamo, imate stalno integracijo!
Kakšni dokazi v sodobnem svetu obstajajo, da je vredno porabljati energijo? Ker na splošno je težko. Če boste poskušali delati tako, boste razumeli, da bo nekaj načrtovanja zdaj prizadeto, več časa boste morali posvetiti razgradnji nalog. Kajti če narediš človek ..., potem se ne boš mogel hitro sprijazniti in boš posledično zabredel v težave. Ne boste imeli več prakse.
In to bo drago. Od jutri dalje ne bo mogoče takoj delati z uporabo neprekinjene integracije. Potrebovali boste zelo dolgo časa, da se navadite na to, zelo dolgo boste potrebovali, da se boste navadili na razčlenjevanje nalog, trajalo bo zelo dolgo, da se boste navadili na ponavljanje prakse pregleda, če ga imate . Ker naš cilj je, da se danes stopi. In če opravite pregled v treh dneh, potem imate težave in Stalna integracija za vas ne deluje.
Toda ali imamo zdaj kakšne ustrezne dokaze, ki nam govorijo, da je vlaganje v to prakso smiselno?
Prva stvar, ki mi je prišla na misel, je State of DevOps. To je študija, ki so jo fantje izvajali 7 let. Zdaj to počnejo kot neodvisna organizacija, vendar pod Googlom.
In njihova študija iz leta 2018 je pokazala korelacijo med podjetji, ki poskušajo uporabiti kratkotrajne podružnice, ki se hitro integrirajo, pogosto integrirajo in imajo boljše kazalnike uspešnosti IT.
Kateri so ti indikatorji? To so 4 meritve, ki jih vzamejo od vseh podjetij v svojih vprašalnikih: pogostost uvajanja, čas za izvedbo sprememb, čas za obnovitev storitve, stopnja napak pri spremembah.
In, prvič, obstaja ta korelacija, vemo, da imajo podjetja, ki pogosto merijo, veliko boljše meritve. In podjetja so razdeljena na več kategorij: to so počasna podjetja, ki nekaj počasi proizvajajo, srednje zmogljiva, visoko zmogljiva in elitna. Elita sta Netflix, Amazon, ki sta super hitra, naredita vse hitro, lepo in učinkovito.
Druga zgodba, ki se je zgodila pred slabim mesecem. Technology Radar ima odličen članek o Gitflowu. Gitflow se od vseh drugih razlikuje po tem, da so njegove veje dolgožive. Obstajajo izdajne veje, ki živijo dolgo časa, in značilne veje, ki prav tako živijo dolgo časa. Ta praksa pri Technology Radar se je premaknila na HOLD. Zakaj? Ker se ljudje soočajo z bolečino integracije.
Če vaša veja živi zelo dolgo, se zatakne, pokvari in začnemo porabiti več časa za to, da bi jo nekako spremenili.
In pred kratkim je avtor Gitflowa dejal, da če je vaš cilj neprekinjena integracija, če je vaš cilj, da se želite čim pogosteje vrteti, potem je Gitflow slaba ideja. Članku je posebej dodal, da če imaš backend, kjer si lahko prizadevaš za to, potem ti je Gitflow odveč, ker te bo Gitflow upočasnil, Gitflow ti bo delal težave z integracijo.
To ne pomeni, da je Gitflow slab in ga ne bi smeli uporabljati. Za druge priložnosti je. Na primer, ko morate podpirati več različic storitve ali aplikacije, tj. kjer potrebujete podporo za daljše časovno obdobje.
Toda če se pogovarjate z ljudmi, ki podpirajo takšne storitve, boste slišali veliko bolečine glede dejstva, da je bila ta različica 3.2, ki je bila pred 4 meseci, vendar ta popravek ni bil vključen vanjo in zdaj, da bi ga naredili, morate narediti kup sprememb. In zdaj so spet obtičali in zdaj se že en teden ubadajo in poskušajo implementirati novo funkcijo.
Kot je Aleksander Kovalev pravilno ugotovil v klepetu, korelacija ni enaka vzročni zvezi. To je resnica. To pomeni, da ni neposredne povezave, da če imate stalno integracijo, bodo vse metrike odlične. Vendar obstaja pozitivna korelacija, da če je eden eden, je najverjetneje tudi drugi. Ni dejstvo, ampak zelo verjetno. To je samo korelacija.
Zdi se, da nekaj že delamo, zdi se, da se že združujemo, ampak kako naj razumemo, da imamo še vedno stalno integracijo, da se združujemo precej pogosto?
Jez Humble je avtor priročnika, Accelerate, spletnega mesta Continuous Delivery in knjige Continuous Delivery. Ponuja tale test:
- Inženirska koda pride mojstru vsak dan.
- Za vsako objavo zaženete teste enote.
- Gradnja v masterju je padla, popravljeno je bilo v približno 10 minutah.
Predlaga uporabo takšnega testa, da se prepričate, ali imate dovolj prakse.
Slednje se mi zdi malo sporno. Se pravi, če lahko to popraviš v 10 minutah, potem imaš stalno integracijo, po mojem mnenju zveni malo nenavadno, vendar je smiselno. Zakaj? Kajti če pogosto zamrzneš, pomeni, da so tvoje spremembe majhne. Če majhna sprememba pomeni, da je vaša glavna zgradba pokvarjena, potem lahko hitro najdete primer, ker je sprememba majhna. Tukaj ste imeli majhno spajanje, spremenjenih 20-30 vrstic. In v skladu s tem lahko hitro razumete, kaj je bil razlog, ker so spremembe majhne, imate zelo majhno območje za iskanje težave.
In tudi če naš izdelek po izdaji razpade, potem, če imamo prakso kontinuirane integracije, nam je veliko lažje ukrepati, ker so spremembe majhne. Da, to bo vplivalo na načrtovanje. To bo bolelo. In verjetno je najtežje v tej praksi navaditi se razdeliti naloge, torej kako to narediti tako, da lahko nekaj vzameš in narediš v nekaj urah in hkrati opraviš pregled, če imaš enega. Pregled je posebna bolečina.
Preizkusi enot so le pomočnik, ki vam pomaga razumeti, ali je bila vaša integracija uspešna in ali se ni nič pokvarilo. Po moje tudi to ni povsem obvezno, ker to ni smisel prakse.
To je kratek uvod v stalno integracijo. To je vse, kar je v tej praksi. Pripravljen sem na vprašanja.
Še enkrat bom na kratko povzel:
- Stalna integracija ni Jenkins, ni Gitlab.
- To ni orodje, je praksa, da svojo kodo čim pogosteje združimo v master.
- To naredimo zato, da bi se izognili ogromni bolečini, ki nastane ob združitvah v prihodnosti, to pomeni, da zdaj doživimo malo bolečine, da je ne bi doživljali več v prihodnosti. To je bistvo.
- Na strani je komunikacija preko kode, vendar to zelo redko vidim, vendar je tudi to namenjeno.
vprašanja
Kaj narediti z nerazgrajenimi nalogami?
Razkrojiti. V čem je problem? Lahko navedete primer, da obstaja naloga in ni razčlenjena?
Obstajajo naloge, ki jih ni mogoče razstaviti iz besede "popolnoma", na primer tiste, ki zahtevajo zelo globoko strokovno znanje in jih je dejansko mogoče rešiti v enem mesecu, da dosežemo nek prebavljiv rezultat.
Če vas prav razumem, potem obstaja neka velika in kompleksna naloga, katere rezultat bo viden šele čez mesec dni?
Da, tako je. Da, rezultat bo mogoče oceniti šele čez mesec dni.
Globa. Na splošno to ni problem. Zakaj? Ker v tem primeru, ko govorimo o vejicah, ne govorimo o vejici s posebnostjo. Funkcije so lahko velike in kompleksne. Lahko vplivajo na veliko število komponent. In morda jih ne moremo narediti v celoti v eni veji. To je v redu. Samo razčleniti moramo to zgodbo. Če funkcija ni popolnoma pripravljena, to ne pomeni, da nekaterih delov njene kode ni mogoče združiti. Dodali ste, recimo, selitev in v funkciji je nekaj stopenj. Recimo, da imate stopnjo – naredite selitev, dodajte novo metodo. In te stvari lahko merite že vsak dan.
Globa. V čem je potem smisel?
Kakšen smisel ima vsakodnevno ubijanje majhnih stvari?
Da.
Če kaj polomijo, to takoj vidiš. Imate majhen košček, ki je nekaj pokvaril, lažje ga boste popravili. Bistvo je, da je združiti majhen kos zdaj veliko lažje kot združiti nekaj velikega čez nekaj tednov. In tretja točka je, da bodo drugi inženirji delali s trenutno različico kode. Videli bodo, da so bile tukaj dodane nekatere migracije, nato pa se je pojavila neka metoda, ki bi jo morda želeli uporabiti. Vsi bodo videli, kaj se dogaja v vaši kodi. Za te tri stvari se vadi.
Hvala, zadeva je zaključena!
(Oleg Soroka) Ali lahko dodam? Vse ste pravilno povedali, rad bi dodal samo eno frazo.
Так.
Z neprekinjeno integracijo se koda ne združi v skupno vejo, ko je funkcija popolnoma pripravljena, ampak ko se zgradba preneha kvariti. In lahko se varno zavežete, da boste obvladali tolikokrat na dan, kot želite. Drugi vidik je, da če iz nekega razloga ne morete razdeliti mesečne naloge na naloge vsaj tri dni, sem tiho tri ure, potem imate velik problem. In dejstvo, da nimate kontinuirane integracije, je najmanjša od teh težav. To pomeni, da imate težave z arhitekturo in nič inženirskih praks. Kajti tudi če je to raziskava, mora biti v vsakem primeru oblikovana v obliki hipotez ali cikla.
Govorili smo o 4 metrikah, ki ločujejo uspešna podjetja od zaostalih. Še vedno moramo živeti, da vidimo te 4 meritve. Če vaša povprečna naloga traja en mesec, potem bi se najprej osredotočil na to meritev. Najprej bi ga znižal na 3 dni. In po tem sem začel razmišljati o Continuous.
Ali sem vas prav razumel, da mislite, da na splošno nima smisla vlagati v inženirske prakse, če katera koli naloga traja en mesec?
Imate stalno integracijo. In obstaja taka tema, da lahko v 10 minutah popravite popravek ali ga vrnete nazaj. Predstavljajte si, da ste ga razvaljali. Še več, imate celo neprekinjeno uvajanje, uvedli ste ga v prod in šele nato opazili, da je šlo nekaj narobe. In to morate vrniti nazaj, vendar ste svojo zbirko podatkov že preselili. Shemo baze podatkov naslednje različice že imate, še več, imeli ste tudi neko varnostno kopijo in tam so bili tudi zapisani podatki.
In kakšno alternativo imate? Če vrnete kodo nazaj, potem ne more več delovati s to posodobljeno bazo podatkov.
Osnova se premika samo naprej, ja.
Ljudje s slabimi inženirskimi praksami najverjetneje tudi niso prebrali debele knjige o .... Kaj narediti z varnostno kopijo? Če obnovite iz varnostne kopije, to pomeni, da izgubite podatke, ki ste jih v tistem trenutku nabrali. Na primer, tri ure smo delali z novo različico baze podatkov, uporabniki so se tam registrirali. Staro varnostno kopijo zavrnete, ker shema ne deluje z novo različico, zato ste izgubili te uporabnike. In so nezadovoljni, prisegajo.
Da bi obvladali celotno paleto praks, ki podpirajo neprekinjeno integracijo in neprekinjeno dostavo, ni dovolj, da se samo naučite pisati.... Prvič, lahko jih je veliko, to bo nepraktično. Poleg tega obstaja kup drugih praks, kot je Scientific. Obstaja takšna praksa, GitHub jo je nekoč populariziral. To je takrat, ko se istočasno izvajata stara in nova koda. To je, ko naredite nedokončano funkcijo, vendar lahko vrne nekaj vrednosti: bodisi kot funkcija ali kot Rest API. Izvedete tako novo kot staro kodo in primerjate razliko med njima. In če obstaja razlika, potem zabeležite ta dogodek. Na ta način veste, da imate novo funkcijo, ki je pripravljena za uvedbo poleg stare, če že določen čas ni bilo neskladja med obema.
Takih praks je na stotine. Predlagam, da začnete z razvojem transbase. Ni 100 % pri stalni integraciji, vendar so prakse enake, eno brez drugega ne more dobro živeti.
Ali ste navedli transbase razvoj kot primer, kjer lahko vidite prakse, ali predlagate, da ljudje začnejo uporabljati transbase debelopment?
Poglejte, ker ga ne bodo mogli uporabiti. Če jih želite uporabiti, morate veliko prebrati. In ko človek vpraša: "Kaj narediti s funkcijo, ki traja en mesec, to pomeni, da ni prebral o transbase razvoju." Ne bi ga še priporočal. Svetoval bi, da se osredotočite izključno na temo, kako pravilno arhitekturno razdeliti velike naloge na manjše. To je bistvo razgradnje.
Dekompozicija je eno izmed arhitektovih orodij. Najprej naredimo analizo, nato dekompozicijo, nato sintezo in nato integracijo. In tako se nam vse izide. In še vedno moramo rasti do nenehne integracije z razgradnjo. Vprašanja se porajajo že na prvi stopnji, govorimo pa že o četrti stopnji, in sicer pogosteje kot izvajamo integracijo, bolje je. Za to je še prezgodaj; dobro bi bilo najprej posekati svoj monolit.
Na nekem diagramu morate narisati več puščic in kvadratov. Ne morete reči, da bom zdaj pokazal arhitekturni diagram nove aplikacije in pokazal en kvadrat, znotraj katerega je zeleni gumb za aplikacijo. V vsakem primeru bo kvadratov in puščic več. Vsak diagram, ki sem ga videl, je imel več kot enega. In razgradnja, tudi na ravni grafičnega prikaza, že poteka. Zato so kvadrati lahko neodvisni. Če ne, potem imam velika vprašanja za arhitekta.
Iz klepeta je vprašanje: "Če je pregled obvezen in traja dolgo, morda en dan ali več?"
Imate težave s prakso. Pregled naj ne traja en dan ali več. To je ista zgodba kot prejšnje vprašanje, le malo mehkejša. Če pregled traja en dan, se ta pregled najverjetneje dogaja pri zelo veliki spremembi. To pomeni, da ga je treba zmanjšati. Pri transbase razvoju, ki ga je priporočil Oleg, obstaja zgodba, imenovana stalni pregled. Njena ideja je, da namenoma naredimo tako majhno zahtevo po vleku, ker se trudimo združiti nenehno in po malem. In tako zahteva za vlečenje spremeni eno abstrakcijo ali 10 vrstic. Zahvaljujoč temu pregledu nam vzame nekaj minut.
Če pregled traja en dan ali več, je nekaj narobe. Prvič, morda imate nekaj težav z arhitekturo. Ali pa je to velik del kode, na primer 1 vrstic. Ali pa je vaša arhitektura tako kompleksna, da je človek ne more razumeti. To je malce postranski problem, a tudi to bo treba rešiti. Morda pregled sploh ni potreben. Tudi o tem moramo razmišljati. Pregled je stvar, ki vas upočasni. Na splošno ima svoje prednosti, vendar morate razumeti, zakaj to počnete. Je to način za hitro posredovanje informacij, je to način za interno postavljanje nekih standardov ali kaj? Zakaj potrebuješ to? Ker je treba pregled opraviti zelo hitro ali pa ga v celoti preklicati. To je kot transbase deveploment – zgodba je zelo lepa, a samo za zrele fante.
Kar zadeva 4 meritve, bi vseeno priporočal, da jih odstranite, da boste razumeli, do česa to vodi. Poglejte številke, poglejte sliko, kako slabo je vse.
(Dmitry) Pripravljen sem vstopiti v razpravo o tem z vami. Številke in meritve so odlične, prakse so odlične. Vendar morate razumeti, ali podjetje to potrebuje. So podjetja, ki ne potrebujejo takšne hitrosti sprememb. Poznam podjetja, kjer sprememb ni mogoče narediti vsakih 15 minut. Pa ne zato, ker so tako slabi. To je tak življenjski krog. Za izdelavo funkcije vej, funkcije preklopa, potrebujete globoko znanje.
Zapleteno je. Če želite podrobneje prebrati zgodbo o funkciji preklopa, jo toplo priporočam . Obstaja čudovit članek Martina Fowlerja o preklopnih funkcijah: katere vrste obstajajo, življenjski cikli itd. Preklopna funkcija je zapletena.
In še vedno niste odgovorili na vprašanje: "Ali je Jenkins potreben ali ne?"
Jenkins v nobenem primeru res ni potreben. Resno, orodja: Jenkins, Gitlab vam bodo prinesla udobje. Videli boste, da je sklop sestavljen ali ne. Lahko vam pomagajo, vendar vam ne bodo dali vaje. Lahko vam dajo samo krog - Ok, ne Ok. In potem, če pišeš tudi teste, ker če testov ni, potem je to skoraj nesmiselno. Zato je potreben, ker je bolj priročen, a na splošno lahko živite brez njega, ne boste veliko izgubili.
Se pravi, če imate prakse, ali to pomeni, da jih ne potrebujete?
Tako je. Priporočam test Jez Humble. Do zadnje točke imam ambivalenten odnos. Toda na splošno, če imate tri stvari, nenehno združujete, izvajate teste na objavah v masterju, hitro popravite gradnjo v masterju, potem morda ne potrebujete ničesar drugega.
Medtem ko čakamo na vprašanja udeležencev, imam jaz vprašanje. Ravno smo govorili o kodi izdelka. Ste ga uporabili za kodo infrastrukture? Ali gre za isto kodo, ali ima ista načela in enak življenjski cikel ali pa obstajajo različni življenjski cikli in načela? Običajno, ko vsi govorijo o stalni integraciji in razvoju, vsi pozabijo, da obstaja tudi infrastrukturna koda. In zadnje čase je tega čedalje več. In ali bi morali vsa ta pravila prinesti tja?
Niti ne, da bi moralo biti, bilo bi super, ker bi na enak način olajšalo življenje. Takoj ko delamo s kodo, ne s skripti bash, ampak imamo običajno kodo.
Stop, stop, bash skript je tudi koda. Ne dotikaj se moje stare ljubezni.
V redu, ne bom poteptal tvojih spominov. Bash osebno ne maram. Ves čas se zlomi grdo in strašljivo. In pogosto se nepredvidljivo pokvari, zato ga ne maram. Ampak v redu, recimo, da imate kodo bash. Mogoče res ne razumem in obstajajo običajni okviri testiranja. Samo nisem seznanjen. In dobimo enake ugodnosti.
Takoj, ko delamo z infrastrukturo kot kodo, imamo enake težave kot razvijalci. Pred nekaj meseci sem naletel na situacijo, ko mi je kolega poslal zahtevo za vlečenje za 1 vrstic v bash. In na pregledu visiš 000 ure. Pojavijo se enake težave. Še vedno je koda. In še vedno je sodelovanje. Zataknemo se pri zahtevi za vlečenje in zataknemo se pri dejstvu, da na primer rešujemo iste spore spajanja v istem bashu.
Zdaj zelo aktivno gledam celotno to stvar na najlepšem infra programiranju. Zdaj sem Pulumija vključil v infrastrukturo. To je programiranje v najčistejši obliki. Tam je še lepše, ker imam vse zmožnosti programskega jezika, se pravi, da sem z istimi if-ji naredil lep preklopnik in je vse vredu. Se pravi, moja sprememba je že v masterju. Vsi ga že lahko vidijo. Drugi inženirji vedo za to. Tam je že nekaj vplivalo. Vendar ni bil omogočen za vse infrastrukture. Vklopil se je na primer za moje testne mize. Zato je treba ponovno odgovoriti na vaše vprašanje. Nam kot inženirjem, ki delamo s kodo, olajša življenje na enak način.
Če ima še kdo vprašanja?
Imam vprašanje. Želim nadaljevati razpravo z Olegom. Na splošno mislim, da imate prav, da če naloga traja en mesec, potem imate problem z arhitekturo, imate problem z analizo, dekompozicijo, načrtovanjem itd. Ampak imam občutek, da če začnete poskusite živeti v skladu s kontinuirano integracijo, potem boste začeli popravljati bolečino z načrtovanjem, saj se ji ne boste izognili nikjer drugje.
(Oleg) Ja, tako je. Ta praksa je po naporih primerljiva s katero koli drugo resno prakso spreminjanja kulture. Najtežje se je znebiti navad, še posebej slabih. In če je za izvajanje te prakse potrebna resna sprememba navad tistih okoli vas: razvijalci, vodstvo, vodja proizvodnje, potem vas čakajo presenečenja.
Kakšna presenečenja bi lahko bila? Recimo, da se odločite, da se boste pogosteje integrirali. Imate še nekaj drugih stvari, povezanih z integracijo, na primer artefakte. In v vašem podjetju, na primer, obstaja politika, da mora biti vsak artefakt na nek način evidentiran v nekem sistemu za shranjevanje artefaktov. In traja nekaj časa. Oseba mora potrditi polje, da je kot upravitelj izdaje preizkusil ta artefakt, da zagotovi, da je pripravljen za izdajo v produkciji. Če traja 5-10-15 minut, vendar naredite postavitev enkrat na teden, potem je poraba pol ure enkrat na teden majhen davek.
Če izvajate neprekinjeno integracijo 10-krat na dan, je treba 10-krat pomnožiti s 30 minutami. In to presega količino delovnega časa tega upravitelja izdaj. Preprosto se naveliča tega dela. Za nekatere prakse obstajajo fiksni stroški. To je vse.
In to pravilo morate preklicati, da ne delate več takšnih smeti, tj. ne dodelite ročno diplome, ki ustreza nečemu. V celoti se zanašate na nek samodejni nabor testov pripravljenosti.
In če potrebujete dokazilo od nekoga, tako da ga šef podpiše, in ne vstopite v proizvodnjo, ne da bi Vasya rekel, da to dovoljuje itd. - vse te neumnosti pridejo na pot praktiku. Ker če so neke dejavnosti povezane z davkom, potem se vse poveča 100-krat. Zato menjave pogosto ne bodo vsi sprejeli z veseljem. Ker je navade ljudi težko spremeniti.
Ko človek opravlja svoje običajno delo, to počne skoraj brez razmišljanja. Njena kognitivna obremenitev je enaka nič. Samo igra se s tem, v glavi že ima kontrolni seznam, to je naredil že tisočkrat. In takoj, ko prideš in mu rečeš: "Ukinimo to prakso in s ponedeljkom uvedimo novo," postane zanj to močna kognitivna obremenitev. In pride vsem naenkrat.
Zato je najpreprostejša stvar, čeprav si tega razkošja ne more privoščiti vsak, ampak to vedno počnem, to je naslednje. Če se začne nov projekt, potem se običajno vse nepreizkušene prakse takoj stlačijo v ta projekt. Čeprav je projekt mlad, ne tvegamo ničesar. Proda še ni, nič ni za uničiti. Zato se lahko uporablja kot usposabljanje. Ta pristop deluje. Toda vsa podjetja nimajo možnosti, da bi pogosto začela s takšnimi projekti. Čeprav je tudi to nekoliko nenavadno, saj je zdaj popolna digitalna preobrazba, vsi morajo izvajati eksperimente, da lahko držijo korak s tekmeci.
Tu prideš do zaključka, da moraš najprej razumeti, kaj moraš narediti. Svet ni idealen in tudi prod ni idealen.
Da, te stvari so med seboj povezane.
Podjetja tudi ne razumejo vedno, da morajo iti po tej poti.
Obstaja situacija, v kateri spremembe sploh niso možne. To je situacija, ko je na ekipo večji pritisk. Ekipa je že precej požgana. Za eksperimente nima prostega časa. Na funkcijah delajo od jutra do večera. In upravljanje ima vedno manj funkcij. Zahteva se vedno več. V takih razmerah sploh niso možne spremembe. Ekipi lahko samo rečemo, da bomo jutri naredili isto kot včeraj, le narediti moramo malo več funkcij. V tem smislu niso mogoči nobeni prehodi v nobene prakse. To je klasična situacija, ko ni časa za brušenje sekire, drevesa je treba posekati, zato sekajo s topo sekiro. Tukaj ni preprostih nasvetov.
(Dmitrij) Prebral bom pojasnilo iz klepeta: »Potrebujemo pa veliko pokritosti s testi na različnih ravneh. Koliko časa je namenjenega testom? Malo je drago in vzame veliko časa.«
(Oleg) To je klasična napačna predstava. Za samozavest bi moralo biti dovolj testov. Kontinuirana integracija ni stvar, pri kateri se najprej opravi 100 % testov in šele nato začnete uporabljati to prakso. Nenehna integracija zmanjša vašo kognitivno obremenitev zaradi dejstva, da je vsaka sprememba, ki jo vidite z očmi, tako očitna, da razumete, ali bo nekaj pokvarila ali ne, tudi brez testov. To lahko hitro preizkusite v svoji glavi, ker so spremembe majhne. Tudi če imate samo ročne testerje, je tudi njim lažje. Stopil si ven in rekel: "Poglej, se je kaj pokvarilo?" Preverili so in rekli: "Ne, nič ni pokvarjeno." Ker tester ve, kje iskati. Imate eno potrditev, povezano z enim delom kode. In to se izkorišča s posebnim vedenjem.
Tukaj ste seveda olepšali.
(Dmitrij) Tukaj se ne strinjam. Obstaja praksa - testni razvoj, ki vas bo rešil tega.
(Oleg) No, nisem še prišel do te točke. Prva iluzija je, da morate napisati 100 % testov ali pa vam nenehne integracije sploh ni treba izvajati. Ni res. Gre za dve vzporedni praksi. In niso neposredno odvisni. Vaša pokritost s testom mora biti optimalna. Optimalno - to pomeni, da ste sami prepričani, da vam kakovost mojstra, v katerem je vaš mojster ostal po potrditvi, omogoča, da samozavestno pritisnete gumb »Razporedi« v pijanem petkovem večeru. Kako to dosežete? S pregledom, s pokritostjo, z dobrim spremljanjem.
Dober nadzor se ne razlikuje od testov. Če enkrat zaženeš teste na pre prod, potem enkrat preverijo vse tvoje uporabniške skripte in to je to. In če jih poganjate v neskončni zanki, potem je to vaš razporejen nadzorni sistem, ki neskončno testira vse – ne glede na to, ali se je zrušilo ali ne. V tem primeru je razlika le v tem, ali se izvaja enkrat ali dvakrat. Zelo dober nabor testov... teče neskončno, to je spremljanje. In pravilno spremljanje bi moralo biti takšno.
In kako točno boste to stanje dosegli, ko se boste v petek zvečer uredili in odšli domov, je drugo vprašanje. Mogoče si samo drzen izmeček.
Vrnimo se malo nazaj k Nenehni integraciji. Zbežali smo v malo drugačno kompleksno prakso.
In druga iluzija je, da je MVP, pravijo, treba narediti hitro, zato testi tam sploh niso potrebni. Zagotovo ne na ta način. Dejstvo je, da ko pišete uporabniško zgodbo v MVP, jo lahko razvijete na žogo, to je, da ste slišali, da obstaja nekakšna uporabniška zgodba in ste jo takoj tekli kodirati, ali pa lahko delate z uporabo TDD. In glede na TDD, kot kaže praksa, ne traja dlje, tj. testi so stranski učinek. V praksi TDD ne gre za testiranje. Kljub tako imenovanemu testno usmerjenemu razvoju sploh ne gre za teste. To je tudi precej arhitekturni pristop. To je pristop k pisanju točno tistega, kar je potrebno, in ne pisanju tistega, kar ni potrebno. To je praksa osredotočanja na naslednjo ponovitev vašega razmišljanja v smislu ustvarjanja arhitekture aplikacije.
Zato se teh iluzij ni tako enostavno znebiti. MVP in testi si ne nasprotujejo. Celo, nasprotno, če MVP delaš s TDD vadbo, potem boš to naredil bolje in hitreje, kot če bi to delal brez vaje, ampak na žogo.
To je zelo neočitna in zapletena ideja. Ko slišite, da bom zdaj pisal več testov in hkrati nekaj naredil hitreje, se sliši popolnoma neustrezno.
(Dmitry) Mnogi ljudje tukaj, ko pokličejo MVP, so ljudje preleni, da bi napisali nekaj normalnega. In to so še vedno različne stvari. MVP ni treba spreminjati v nekaj slabega, ki ne deluje.
Ja, ja, prav imaš.
In potem nenadoma MVP v prod.
Za vedno.
In TDD se sliši zelo nenavadno, ko slišite, da pišete teste in se zdi, da opravljate več dela. Sliši se zelo nenavadno, a v resnici tako izpade hitreje in lepše. Ko pišeš test, že v glavi veliko razmišljaš o tem, kakšna koda se bo klicala in kako ter kakšno vedenje od nje pričakujemo. Ne rečete samo, da sem napisal neko funkcijo in ta nekaj naredi. Sprva si mislil, da ima takšne in drugačne pogoje, jo bodo poklicali na tak in tak način. To pokrijete s testi in iz tega razumete, kako bodo vaši vmesniki videti znotraj vaše kode. To ima velik vpliv na arhitekturo. Vaša koda samodejno postane bolj modularna, saj najprej poskušate razumeti, kako jo boste testirali, in jo šele nato napišete.
Pri TDD se mi je zgodilo to, da sem na neki točki najel mentorja za Ruby, ko sem bil še Ruby programer. In pravi: "Naredimo to v skladu s TDD." Pomislil sem: "Prekleto, zdaj pa moram še nekaj napisati." In dogovorili smo se, da bom v dveh tednih napisal vso delujočo kodo v Pythonu z uporabo TDD. Po dveh tednih sem spoznal, da se ne želim vrniti. Po dveh tednih poskusov uporabe tega povsod ugotoviš, koliko lažje ti je postalo celo samo razmišljati. Vendar to ni očitno, zato vsem priporočam, da če imate občutek, da je TDD težaven, dolgotrajen in nepotreben, poskusite vztrajati le dva tedna. Dva sta mi zadostovala.
(Dmitry) To idejo lahko razširimo z vidika delovanja infrastrukture. Preden lansiramo kaj novega, naredimo nadzor in nato lansiramo. V tem primeru spremljanje za nas postane običajno testiranje. In s spremljanjem je razvoj. Toda skoraj vsi pravijo, da je dolg, sem len, naredil sem začasni osnutek. Če smo opravili normalno spremljanje, razumemo stanje sistema CI. In sistem CI ima veliko spremljanja. Razumemo stanje sistema, razumemo, kaj je v njem. In med razvojem samo naredimo sistem, da pride do želenega stanja.
Te prakse so znane že dolgo. O tem sva razpravljala pred približno 4 leti. Toda v 4 letih se ni spremenilo praktično nič.
Toda na tej točki predlagam, da končam uradno razpravo.
Video (vstavljen kot medijski element, vendar iz neznanega razloga ne deluje):
Vir: www.habr.com