Continuous Integration kui praktika, mitte Jenkins. Andrei Aleksandrov

Arutame, miks CI-tööriistad ja CI on täiesti erinevad asjad.

Millist valu CI püüab leevendada, kust tuli idee, millised on viimased tõendid selle toimimise kohta, kuidas mõista, kas teie käsutuses on tõeliselt praktika, mitte lihtsalt paigaldatud Jenkins.

Mõte teha ettekande Continuous Integration'i kohta tuli juba aasta tagasi, kui ma käisin tööotsingutel. Rääkisin 10-15 ettevõttega, neist ainult üks suutis arusaadavalt vastata, mis on CI, ja selgitada, kuidas nad mõistsid, et neil seda pole. Ülejäänud rääkisid arusaamatust juttu Jenkinsist 🙂 Noh, meil on Jenkins, see teeb sündmusi, CI! Ettekandes püüan selgitada, mis on tegelikult Continuous Integration ja miks Jenkins ja sarnased tööriistad on selle suhtes väga nõrgad.

Ja nii, mis tavaliselt tuleb CI sõna peale meelde? Enamikele inimestele tuleb meelde Jenkins, Gitlab CI, Travis jne.

Isegi kui google’ime, pakutakse meile need tööriistad.

Kui küsida, kas need tunduvad tuttavad, siis kohe pärast tööriistade loetlemist räägitakse, et CI tähendab, et teil on Pull Requestis kommittimisel sündmus ja testide läbiviimine.

Continuous Integration ei ole tööriistadest ega testide kogumist haru sees! Continuous Integration on praktika, mis keskendub uue koodi pidevale integreerimisele, ja selleks ei ole absoluutset vajadust üles ehitada Jenkins'e, GitLab'e jne.

Enne kui läheme edasi, et aru saada, milline on tõeline CI, sukeldume esmalt nende inimeste konteksti, kes selle välja mõtlesid, ja tunnetame olukorda, mida nad üritasid lahendada.

Nad üritasid lahendada meeskonnatöö valupunkte!

Vaadakem näiteid, millega arendajad silmitsi seisavad meeskondade koostöös. Oletame, et meil on projekt, git'i peaharud ja kaks arendajat.

Nad alustavad tööd, nagu paljud on juba harjunud. Nad võtavad ülesande Jira's, loovad feature haru ja kirjutavad koodi.

Üks neist lõpetab funktsiooni kiiremini ja liidab selle peaharuga.

Teisel kulus rohkem aega, ta liitus hiljem ja sai konflikti. Nüüd, selle asemel, et kirjutada ettevõttele vajalikke funktsioone, kulutab arendaja oma aega ja energiat konfliktide lahendamisele.

Mida keerulisem on oma funktsiooni ühendada üldise meistriga, seda rohkem aega me selle jaoks kulutame. Ja see on vaid lihtne näide. See on näide, kus arendajaid on vaid kaks. Kujutage nüüd ette, kui neid on 10, 15 või isegi 100, kes kirjutavad ühte repo. Te lähete hulluks, lahendades kõiki neid konflikte.

On veidi teine olukord. Meil on meister ja mitu arendajat, kes teevad midagi.

Nad on loonud igaühele oma haru.

Üks neist liitus, kõik oli head, ülesanne anti üle.

Teine arendaja samal ajal andis oma ülesande. Oletame, et ta esitas selle ülevaatamiseks. Paljudes firmades on praktika – ülevaatus. Ühelt poolt on see hea ja kasulik praktika, teisalt aga pidurdab see meid paljuski. Me ei süvene sellesse, aga siin on suurepärane näide, kuhu võib viia vale ülevaatuse ajalugu. Te esitasite pull requesti ülevaatamiseks. Arendajal ei olnud rohkem midagi teha. Mida ta siis hakkab tegema? Ta hakkab võtma muid ülesandeid.

Sel ajal tegi teine arendaja veel midagi.

Esimene täitis kolmanda ülesande.

Ja mingil pikemal ajal, kui tema ülevaade on proovitud, püüab ta sulanduda. Ja mis juhtub? Ta satub tohutute konfliktide piiristikku. Miks? Sest seni, kuni tema pull request oli ülevaatamisel, on koodis juba liiga palju muutunud.

Lisaks konfliktide teemale on probleemiks ka suhtlused. Kui teie haru on ülevaatamisel, ootab midagi, ja kui te kaua töötate funktsiooni kallal, lõpetate jälgimise, mis veel teie teenuse koodibaasis muutub. Võib-olla olete asja, mille hetkel proovite lahendada, juba eile lahendanud ja saate mõnda meetodit taaskasutada. Kuid te ei näe seda, sest te töötate alati vananenud haruga. Ja see vananenud haru toob alati kaasa selle, et peate lahendama merge-konflikti.

Tuleb välja, et kui töötame meeskonnas, st mitte üks inimene uurib repot, vaid umbes 5-10 inimest, siis mida kauem me oma koodi põhiharusse ei lisame, seda enam kannatame selle tõttu, et lõpuks tuleb midagi sulanduda. Ja mida rohkem me konfliktidega silmitsi seisame ning millega vanema versiooniga töötame, seda rohkem probleeme meil on.

Koos töötamine on valus! Me segame alati üksteist.

Sellele probleemile pöörati tähelepanu üle 20 aasta tagasi. Esimene viide pideva integreerimise praktikast leiti äärmuslikest programmeerimistest.

Äärmuslik programmeerimine on pirmine agiilne raamistik. Lehekülg ilmus 1996. aastal. Idee oli kasutada programmeerimise, planeerimise ja muu praktikaid, et arendamine oleks võimalikult paindlik, et saaksime kiiremini reageerida muudatustele ja kliendi nõudmistele. Nad hakkasid 24 aastat tagasi märkama, et kui sa teed midagi väga kaua ja eraldi, siis kulutad sellele rohkem aega, sest sul tekivad konfliktid.

Praegu analüüsime fraasi „pidev integreerimine“ sõna-sõnalt. Kui tõlkida otse, siis saame pidev integreerimine. Kuid kui pidev see tegelikult on, ei ole väga selge, see on pigem katkestatud. Samuti ei ole selge, kui palju see on integratsioon.

Seetõttu toon teile praegu tsitaate äärmuslikust programmeerimisest. Ja me analüüsime mõlemat sõna eraldi.

Integreerimine — Nagu ma juba mainisin, püüame, et iga insener töötaks kõige värskemate koodiversioonidega ja lisaks oma koodi võimalikult sageli peamise haru külge, et need oleksid väiksed harud. Sest kui need on suured, võime kergesti nädalaks kinni jääda ühinemis konfliktidesse. Eriti kui meil on pikk arendustsükkel, nagu waterfall, kus arendaja läheb kuuks ajaks midagi suurt arendama. Ja integreerimise etapis jääb ta tõeliselt pikaks ajaks kinni.

Integreerimine on see, kui me võtame oma haru ja integreerime selle peamise haruga, ühildame selle. On ideaalne variant, kus me transbase development, kus püüame kirjutada otse peaharu, ilma igasuguste liigsete harudeta.

Üldiselt on integreerimine oma koodi võtmine ja selle peaharu viimine.

Mida mõeldakse sõna „continuous“ all, mis tähendab pidevust? Praktikas püüab arendaja integreerida oma koodi võimalikult kiiresti. See on tema eesmärk iga ülesande täitmisel – saada oma kood põhiharusse nii kiiresti kui võimalik. Ideaalilises maailmas teeksid arendajad seda iga paari tunni järel. S.t. sa võtad väikese ülesande, mergid selle põhiharusse. Kõik on suurepärane. Sa püüdled selle poole. Ja seda tuleb teha pidevalt. Niipea, kui sa midagi teed, paigutad sa selle kohe põhiharusse.

Ja arendaja, kes midagi teeb, vastutab selle eest, et see töötab ja mitte midagi ei katke. Siin tõuseb tavaliselt esile testide teema. Soovime käivitada mõned testid meie commit'ile, meie mergile, et veenduda, et see töötab. Siin võivad teile suureks abiks olla Jenkins.

Aga lugudega: teeme muudatused väikestena, teeme ülesanded väikestena, ja teeme ülesande ning üritame selle kohe ühendusse saada – siin ei aita Jenkinsid. Sest Jenkins aitab teil ainult teste käivitada.

Te saate ka ilma nendeta hakkama. See ei takista teid milleski. Sest praktika eesmärk on ühendada nii tihti kui võimalik, et mitte raisata aega tulevikus tekkivate konfliktide peale.

Kujutame ette, et meil on 2020. aasta ja mingil põhjusel pole internetti. Ja me töötame lokaalselt. Meil pole Jenkinsit. See on normaalne. Te saate ikkagi luua lokaalse haru. Te olete sinna kirjutanud mingit koodi. Tehke ülesanne 3-4 tunni jooksul. Vahetage peaharule, tehke git pull ja ühendage oma haru sinna. Valmis. Kui teete seda tihti – õnnitleme, teil on pidev integreerimine!

Millised on tänapäeva maailmas tõendid, mis näitavad, et selleks tasub pingutada? Sest üldiselt on see keeruline. Kui proovite nii töötada, mõistate, et peate mingisugusest planeerimisest kinni pidama ja rohkem aega ülesannete koostamiseks kulutama. Sest kui teete man…, siis te ei saa kiiresti liita ja seetõttu jääte hätta. Teie praktikast ei piisa enam.

Ja see tuleb kalliks maksma. Alustada kohe järgmiseks päevaks pideva integreerimisega ei õnnestu. Te harjute sellega väga kaua, palju aega kulub ülesannete koostamise harjumise peale, palju aega kulub ülevaatuspraktika muutmise harjumise peale, kui see teil juba on. Sest meie eesmärk on, et see liituks täna. Kui teete ülevaatust kolme päeva jooksul, on teil probleeme ja pidev integreerimine ei toimi.

Aga kas meil on mingeid aktuaalseid tõendeid just nüüd, mis ütlevad, et sellesse praktikasse investeerimine on mõttekas?

Esimene asi, mis mulle pähe tuli, on State of DevOps. See on uuring, mida kutid on juba seitse aastat läbi viinud. Praegu teevad nad seda sõltumatu organisatsioonina, kuid Google'i all.

Ja nende uurimus 2018. aastal näitas korrelatsiooni ettevõtete vahel, kes püüavad kasutada lühiajalisi harusid, mis integreeruvad kiiresti ja sageli. Nende IT-tulemuslikkus on oluliselt parem.

Millised on need näitajad? Need on neli mõõdikut, mida nad küsitlustes kõigist ettevõtetest koguvad: deployimise sagedus, muudatuste ooteaeg, teenuse taastamise aeg ja muudatuste ebaõnnestumise määr.

Esiteks, on olemas see korrelatsioon: me teame, et ettevõtted, kes teevad sulandamisi tihti, saavutavad nende mõõdikute osas paremaid tulemusi. Samuti jagavad nad ettevõtteid erinevatesse kategooriatesse: aeglased ettevõtted, medium performer, high performer ja eliit. Eliit on Netflix, Amazon, kes on superkiired — nad teevad kõik kiiresti, kenasti ja kvaliteetselt.

Teine lugu, mis juhtus alles kuu aega tagasi. Technology Radar'is ilmus suurepärane märkmete postitus Gitflow'st. Gitflow erineb teistest sellega, et tema harud elavad kaua. On väljaandmispuud, mis elavad kaua ning funktsioonide harud, mis samuti kaua elavad. See praktika on Technology Radar'is hakanud HOLD-i minema. Miks? Sest inimesed seisavad silmitsi integratsiooni probleemidega.

Kui sinu haru elab väga pikka aega, jääb see kinni, hakkab mädanema, ja me hakkame kulutama rohkem aega selle muutmise tegemiseks.

Ja hiljuti ütles Gitflow autor, et kui püüad saavutada pidevat integreerimist ja soovid, et saaksid võimalikult sageli edasi liikuda, siis Gitflow on halb idee. Ta lisas oma artiklis, et kui sul on backend, kus saad sellele püüda, siis Gitflow on sulle üleliigne, kuna see aeglustab sind ja loob integreerimisega probleeme.

See ei tähenda, et Gitflow oleks halb ja et seda ei tohiks kasutada. See sobib muudes olukordades. Näiteks, kui pead toetama mitut versiooni teenusest või rakendusest, s.t. kui pead toetama pikka aega.

Aga kui suhtled inimestega, kes selliseid teenuseid toetavad, kuuled palju nördimust selle üle, et see versioon oli 3.2, mis oli 4 kuud tagasi ja kuhu see parandamine ei saanud, ning nüüd, et see sisse viia, tuleb teha hulk muudatusi. Ja nad takerdusid jälle ja nii nad näpivad nädal aega, et võtta ja liita mingi uus funktsioon.

Nagu Alexander Kovalev õigesti märkis vestluses, ei tähenda korrelatsioon, et tegemist on põhjus-tagajärjega. See on tõsi. St. ei ole mingit otsest seost, et kui teil on pidev integreerimine, siis kõik näitajad on imeliselt head. Kuid on positiivne korrelatsioon, et kui üks on olemas, siis tõenäoliselt on ka teine. See ei ole kindlasti, aga tõenäoliselt. See on ainult korrelatsioon.

Tundub, et me teeme juba midagi, näiliselt me merge’ime, aga kuidas mõista, et meil on siiski pidev integreerimine, et me merge’ime piisavalt tihti?

Jez Humble on Handbooki, Accelerate'i, Continuous Delivery veebisaidi ja raamatu „Continuous Delivery“ autor. Ta pakub välja sellise testi:

• Arendaja kood jõuab masterisse igapäevaselt.
• Iga commit'i puhul käitate te unit-testid.
• Masteri build kukkus alla, see parandati umbes 10 minutiga.

Ta soovitab kasutada sellist testi, et veenduda, et praktika on teil tõeliselt olemas.

Viimane punkt tundub mulle veidi vaidluslik. Kui saate vea 10 minutiga parandada, siis tähendab see, et teil on pidev integreerimine, mis kõlab veidi kummaliselt, aga see omamoodi mõte eksisteerib. Miks? Sest kui te teete sageid liiteid, tähendab see, et muudatused on väikesed. Kui väike muudatus põhjustab teie põhiversiooni katkestamise, suudate selle kiiresti leida, kuna muudatus on väike. Oletame, et teil oli väike liitmine, kus muudeti 20–30 rida. Seetõttu saate kiiresti aru, mis põhjus oli, kuna muudatused on napid ja teil on probleemide otsimiseks väga väike ala.

Ja isegi kui meie tootmisserver pärast väljalaset kokku kukub, siis kui meil on pideva integreerimise praktika, on meil palju lihtsam tegutseda, kuna muudatused on väikesed. Jah, see mõjutab planeerimist. See teeb haiget. Ja tõenäoliselt on kõige keerulisem selles praktikas see, et harjuda ülesandeid jaotama, st kuidas teha nii, et võtaks midagi teha mitu tundi ja seejärel läbida kvalitatiivne ülevaatus, kui see on olemas. Ülevaatus on täiesti eraldi mure.

Ühik-testid on lihtsalt abivahend, mis aitab teil mõista, kas teie integreerimine on õnnestunud ja midagi pole katki läinud. Minu arvates pole see ka täiesti kohustuslik punkt, kuna praktika mõte ei seisne selles.

Siin on lühidalt Continuous Integration'i kohta. See on kõik, mis selle praktika kohta teada on. Olen küsimustele avatud.

Lühidalt kokku võttes ütlen veel kord:

• Continuous Integration ei tähenda Jenkins'i ega GitLab'i.
• See ei ole tööriist, vaid praktika, mille kohaselt liidame meie koodi võimalikult tihti master'isse.
• Tee seda selleks, et vältida tulevikus suuri probleeme, mis seotud mergimisega; ehk tekitame praegu väikese valulikkuse, et tulevikus vältida suurt. See on kogu idee.
• Koodiga toimub suhtlemine, aga ma näen seda väga harva, kuigi selleks see on ka ette nähtud.

Küsimused

Mida teha ülesannete mitte-dekompositsiooniga?

Dekompositsioon. Mis on probleem? Kas suudate tuua näite, et on mingi ülesanne, mida ei saa dekompositsiooniks jagada?

On selliseid ülesandeid, mida ei saa absoluutselt lahti harutada, näiteks need, mis nõuavad väga sügavat ekspertiisi ja mida on võimalik lahendada tegelikult kuu aega enne mingit arusaadavat tulemust.

Kui ma sind õigesti mõistan, siis on mingi suur ja keeruline ülesanne, mille tulemust saab näha ainult kuu pärast?

Jah, kõik on õige. Jah, tulemuse hindamine on võimalik mitte varem kui kuu pärast.

Hea küll. Üldiselt pole see probleem. Miks? Sest antud juhul, kui räägime harudest, ei räägi me harust koos funktsiooniga. Funktsioonid võivad olla suured ja keerulised. Need võivad hõlmata suurt hulka komponente. Ja võib-olla me ei saa neid täielikult teha ühes haru. See on normaalne. Me peame lihtsalt selle loo lahti harutama. Kui funktsioon ei ole lõpuni valmis, ei tähenda see, et mõningaid selle koodi osi ei saa liita. Sa oled näiteks lisanud migratsiooni ja funktsiooni sees on mõned etapid. Sul on näiteks etapp – teha migratsioon, lisada uus meetod. Ja need asjad, mida saab juba iga päev liita.

Hea küll. Mis siis on selle mõte?

Miks on mõtet igapäevaselt väikeseid muudatusi kokku viia?

Jah.

Kui need on midagi katki teinud, siis näed seda kohe. Sul on väikene tükk, mis midagi katki tegi, ja seda on lihtsam parandada. Mõtteks on see, et väikese tüki ühendamine on oluliselt lihtsam kui suure ühendamine nädalate pärast. Ja kolmas mõte on see, et teised insenerid saavad töötada juba aktuaalse koodiversiooniga. Nad näevad, et siia on lisandunud migratsioonid ja siia on ilmunud mingi meetod, mida nad võivad samuti soovida kasutada. Kõik näevad, mis su koodis toimub. Just nende kolme asja nimel seda praktikat tehakse.

Aitäh, küsimus on suletud!

(Oleg Soroka) Kas ma võin lisada? Sa ütlesid kõike õigesti, tahan lihtsalt ühe lause lisada.

Nii.

Continuous Integration'i puhul liidetakse kood ühisesse haru mitte siis, kui funktsioon on täielikult valmis, vaid siis, kui ehitus enam ei katke. Ja võite rahulikult commiteerida masterisse niipalju kordi päevas kui soovite. Teine aspekt – kui te mingil põhjusel ei suuda kuumisi ülesannet jagada vähemalt kolme päeva ülesanneteks, rääkimata kolmest tunnist, siis on teil suur probleem. Ja see fakt, et teil ei ole Continuous Integration'i – on kõige väiksem neist probleemidest. See tähendab, et teil on probleeme arhitektuuriga ja inseneripraktikad on nullis. Sest isegi kui see on uurimistöö, tuleks seda siiski vormistada hüpoteeside või tsüklina.

Rääkisime neljast mõõdikust, mis eristavad edukaid ettevõtteid mahajäänutest. Nendest neljast mõõdikust tuleb veel läbi elada. Kui teie keskmine ülesanne kestab kuu aega, siis soovitaksin kõigepealt sellele mõõdikale tähelepanu pöörata. Vähendage see esmalt kolme päeva peale. Ja pärast seda hakake mõtlema Continuous'e peale.

Kas ma sain õigesti aru, et arvad, et investeerimine inseneripraktikatesse ei ole mõistlik, kui igasugune ülesanne kestab kuu aega?

Sul on pidev integreerimine. Ja seal on selline teema, et sa kas parandad vea 10 minuti jooksul või tagasitõmbad. Kujuta ette, et sa selle välja andsid. Ja sul on isegi pidev juurutamine, sa andsid selle välja produktsiooni ja alles siis märkad, et midagi läks valesti. Ja sul tuleb see tagasi võtta, aga su andmebaasi migratsioon on juba toimunud. Sul on juba andmebaasi skeem järgmises versioonis, veel rohkem, on toimunud ka mingisugune varundamine, veel sinna andmed salvestatud.

Ja mis sul on alternatiivina? Kui sa tagasitõmbad koodi, siis see ei saa enam töötada selle uuendatud andmebaasiga.

Andmebaas liigub ainult edasi, jah.

Inimestel, kellel on halb inseneripraktika, on tõenäoliselt, et nad pole paksu raamatut ... ka lugenud. Mida teha varundusega? Kui sa taastud varundusest, siis sa kaotad andmed, mis selle hetkeni kogusid. Näiteks töötasid kolme tunni jooksul uue versiooniga andmebaasis, sinna registreerusid kasutajad. Sa tagastusid vanale varundusele, kuna uue versiooniga skeem ei tööta, vastavalt sellele kaotad sa need kasutajad. Ja nad on rahulolematud, nad pahandavad.

Ettevalmistamiseks, et omandada kogu praktika, mis toetab pidevat integreerimist ja pidevat tarnimist, ei piisa lihtsalt kirjutamisest... Esiteks, neid võib olla väga palju, mille tõttu muutub see ebaefektiivseks. Lisaks on seal hulk teisi praktikaid, näiteks teaduslikud. On olemas praktika, mille populariseeris GitHub, kus vana ja uus kood töötab samaaegselt. See tähendab, et sa teed pooleliolevat funktsiooni, mis saab mingit väärtust tagastada: kas funktsiooni või REST API kaudu. Sa täidad nii uut koodi kui ka vana koodi ja võrdled nende vahelist erinevust. Ja kui erinevus eksisteerib, siis logid selle sündmuse. Nii tead, et su uus funktsioon on valmis vanale peale kukkuma, kui teatud ajaperioodi jooksul ei ole nende kahe vahel lahknevust.

Selliseid praktikaid on sadu. Ma soovitaksin alustada transbase arendamisest. See ei ole 100% pideva integreerimise mudel, kuid praktikad on samasugused, üks ilma teiseta ei ela hästi.

Kas tõid transbase arendamise näitena, kust saab praktikaid vaadata, või soovitad inimestel alustada transbase arendamise kasutamist?

Vaadake, kuna nad ei saa seda kasutada. Selleks, et seda kasutada, tuleb palju lugeda. Ja kui inimesel on küsimus: „Mida teha funktsiooniga, mis võtab kuu aega“, siis see tähendab, et ta ei ole lugenud transbase arendamise kohta. Ma ei soovitaks seda praegu. Ma soovitaksin keskenduda rangelt sellele, kuidas suurte ülesannete arhitektuuriliselt õigesti väiksemateks tükkideks jagada. Just see on dekompositsiooni tuum.

Dekompositsioon on üks arhitekti tööriistu. Esiteks teeme analüüsi, seejärel dekompositsiooni, seejärel sünteesi ja seejärel integratsiooni. Nii koguneb meie jaoks kõik kokku. Ja pidev integratsioon nõuab dekompositsiooni kaudu arengut. Esimesel etapil tekivad küsimused, aga me räägime juba neljandast etapist, st mida sagedamini integratsiooni teeme, seda parem. Selleks on veel varakene, oleks hea esmalt oma monoliiti pisut toimetada.

Tuleb joonistada mingisuguseid nooli ja ruute mingile skeemile. Sa ei saa öelda, et nüüd näitan ma uue rakenduse arhitektuurskeemi ja näitan ühte ruutu, mille sees on roheline nupp rakenduse jaoks. Igal juhul on ruute ja nooli rohkem. Igas skeemis, mida ma olen näinud, on neid rohkem kui üks. Ja isegi graafilise esitlemise tasemel toimub dekompositsioon juba. Seetõttu saab ruute teha sõltumatuks. Kui ei, siis on mul arhitekti vastu suured küsimused.

Küsimus vestlusest: „Kas ülevaatus on kohustuslik ja kestab kaua, mõnikord päeva või kauem?“

Teie praktikaga on probleeme. Ülevaatus ei tohiks kesta päeva või rohkem. See on sama lugu nagu eelneva küsimusega, ainult veidi leebem. Kui ülevaatus kestab päeva, tähendab see, et tõenäoliselt on tegemist väga suure muudatusega. Seega tuleks seda jagada väiksemateks osadeks. Olegi soovitatud transbase arenduses on selline mõte, mida nimetatakse pidevaks ülevaatuseks. Selle idee on see, et me teeme teadlikult nii väikese pull request'i, et soovime pidevalt väikeste muudatustega liituda. Seega muudab pull request ühe abstraktsiooni või 10 rida. Tänu sellele kestab meie ülevaatus paar minutit.

Kui ülevaade võtab päeva või enam, siis on midagi valesti. Esiteks võivad teil olla probleemid arhitektuuriga. Või on see suur koodilõik, näiteks 1000 rida. Või on teie arhitektuur nii keeruline, et inimene ei saa sellest aru. See on probleem, mida tuleb samuti lahendada. Võib-olla ei olegi ülevaatust vaja. Sellele peaksite samuti mõtlema. Ülevaatus on see, mis teid pidurdab. Sellel on oma eelised, kuid tuleb mõista, miks te seda teete. Kas see on teie jaoks kiire teabe edastamise viis, kas selle kaudu seadistate sisemisi standardeid või midagi muud? Miks teil seda on vaja? Sest ülevaatus peab olema kas väga kiire või tuleks see hoopis ära jätta. See on nagu transbase'i arendamine – väga ilus lugu, kuid ainult küpsetele inimestele.

Mis puutub nelja mõõdikusse, siis soovitaksin need siiski eemaldada, et mõista, kuhu see viib. Vaadata numbreid, vaadata pilti, kui halb see kõik veel on.

(Dmitri) Olen valmis selle üle sinuga arutama. Numbrid ja mõõdikud on kõik tore, praktika on tore. Kuid tuleb mõista, kas see on ettevõttele vajalik. On ettevõtteid, kellele ei ole selline muutuste sagedus vajalik. Tuntud on ettevõtted, kus ei tohi muudatusi teha iga 15 minuti järel. Ja mitte seepärast, et nad oleksid kedagi halvad. See on elutsükkel. Ja et kasutada funktsioonide haru ja funktsioonide lülitit, on vaja sügavaid teadmisi.

See on keeruline. Kui soovite lugeda rohkem funktsioonide lülitite ajaloost, siis soovitan tungivalt. https://trunkbaseddevelopment.com/. Ja Martin Floweri korral on suurepärane artikkel funktsioonide lülititest: milliseid tüüpe, elutsükleid jms. Funktsioonide lülitid – see on keeruline.

Ja sa ikkagi ei vastanud küsimusele: 'Kas Jenkins on vajalik või mitte?'

Jenkins ei ole tegelikult kunagi vajalik. Kui tõsiselt rääkida, siis tööriistad nagu Jenkins ja Gitlab toovad mugavust. Näete, kas ehitamine toimis või mitte. Nad aitavad teil, kuid nad ei anna teile praktilisi kogemusi. Nad võivad anda vaid ringi – OK, mitte OK. Ja seda juhul, kui te kirjutate veel teste, sest kui teste ei ole, siis on see peaaegu mõttetu. Seetõttu on vaja, sest see on mugavam, kuid üldiselt saate ka ilma selleta hakkama, ei kaota kuigi palju.

K. e. kui teil on praktika, kas see tähendab, et teil ei ole seda vaja?

Just. Soovitan Jez Humble'i testi. Ma olen viimase punkti osas kahtleval seisukohal. Kuid kokkuvõttes, kui teil on kolm asja: te ühendate pidevalt, käivitate teste masteris tehtud muudatuste puhul, kiiresti parandate masteri ehituse, siis võib-olla ei ole teil rohkemat vajagi.

Kui me ootame osalejatelt küsimusi, siis minul on küsimus. Me rääkisime tootekoodist. Kas sa oled kasutanud ka infrastruktuurikoodi? Kas see on sama kood, millel on samad põhimõtted ja eluiga, või on seal teised eluiga ja põhimõtted? Üldiselt, kui kõik räägivad pidevast integreerimisest ja arendamisest, unustavad nad, et infrastruktuurikood on samuti olemas. Viimasel ajal on seda üha rohkem. Kas peaksime sinna tuua kõik need reeglid?

See ei ole ainult soovitus, see oleks suurepärane, kuna see lihtsustaks elu. Niipea kui me töötame koodiga, mitte bash-skriptidega, vaid meil on normaalne kood.

Peatu-peat, bash-skript on samuti kood. Ära puutu minu vana armastust.

Hea küll, ma ei hakka sinu mälestusi tallama. Mul on bash'i vastu isiklik antipaatia. See puruneb inetult ja haaravalt kogu aeg. Ja see katkeb sageli ettearvamatult, seetõttu ma ei armasta seda. Aga hästi, oletame, et sul on bash'is kood. Võib-olla tõesti ma ei tea ja seal on normaalsed testimise raamistikud. Ma lihtsalt ei ole teadlik. Ja me saame samu eeliseid.

Kui me töötame infrastruktuuriga nagu koodiga, kohtame samu probleeme nagu arendajad. Mõned kuud tagasi sattusin olukorda, kus kolleeg saatis mulle 1 000 rea suuruse bash'i pull request'i. Ja sa jääd 4 tunniks ülevaate tegemisse kinni. Probleemid on samad. See on ikka veel kood. Ja ikka veel koostöö. Me jääme kinni pull request'i ja meid pidurdavad samad bash'i mergenüübid.

Ma jälgisin seda asja praegu väga aktiivselt, keskendudes tarkvara infrastruktuuri maksimaalselt ilusale kodeerimisele. Olen praegu integreerinud infrastrukturi Pulumi. See on puhtalt kodeerimine. Seal on see veel kaunim, sest mul on kõik programmeerimiskeele võimalused. See tähendab, et ma tegin samade if-de abil kauneid toggles ja kõik on hästi. Minu muudatus on juba Masteris. Kõik näevad seda. Teised insenerid on sellest teadlikud. See on juba millegi peale mõjutanud. Kuid see ei ole aktiveeritud kõigis infrastruktuurides. See on aktiveeritud näiteks minu testkeskkondades. Seega, vastates su küsimusele veel kord, see on vajalik. See lihtsustab meie elu inseneridena, kes töötavad koodiga, täpselt samamoodi.

Kas kellelgi on veel küsimusi?

Mul on küsimus. Soovin jätkata arutelu Olegiga. Üldiselt arvan, et sul on õigus, et kui ülesanne võtab sul kuu aega, siis on sul arhitektuuriga probleeme, sul on probleeme analüüsiga, dekompositsiooniga, planeerimisega jne. Kuid mul on tunne, et kui hakkad püüdma elada Continuous Integration'i järgi, siis hakkad oma planeerimisega seotud muresid lahendama, sest sa ei pääse sellest muidu.

(Oleg) Jah, kõik on nii. Selle praktika töömaht on sarnane igasuguste teiste tõsiste praktikatega, mis muudavad kultuuri. Kõige raskem on harjumuste ületamine, eriti halbade harjumuste. Ja kui selle praktika juurutamiseks on vajalik tõsine muutus ümbritsevates harjumustes: arendajates, juhtkonnas, tootmisjuhtides, siis ootavad sind üllatused.

Millised üllatused võivad tulla? Oletame, et otsustasite, et hakkate sagedamini integreerima. Ja teie integratsioonis on seotud veel mõned asjad, näiteks artefaktid. Ja teie ettevõttes on näiteks poliitika, et iga artefakt peab olema mingil moel arvesse võetud mingis artefaktide laosüsteemis. Ja see võtab aega. Inimene peab märkima, et tema, kui väljalaskemanager, on katsetanud seda artefakti tootmisse panekuks. Kui see võtab 5-10-15 minutit, kuid samas teete väljalaske kord nädalas, siis nädalas pool tundi kulutada – see on väike maks.

Kui teete pidevat integreerimist 10 korda päevas, siis tuleb 10 korda korrutada 30 minutiga. Ja see ületab selle väljalaskemanageri tööaja. Ta lihtsalt väsib sellest. On pidevad kulud mõningatele praktikatest. Ja kõik.

Ja teil on kas vaja see reegel tühistada, et te enam sellisega ei tegele, st te ei määra käsitsi millegi vastavuse astet. Te toetute täielikult mingile automatiseeritud testide komplektile, et kontrollida valmisolekut.

Ja kui teil on vaja kellegi tõendit, et juht kirjutaks alla, ja te ei lähe produktsiooni, kui Vasja ei ole öelnud, et tal on lubatud jne. – siis kogu see jama takistab praktikaid. Sest kui on seotud mingisuguste tegevustega maksud, siis kõik muutub 100 korda keerulisemaks. Seetõttu võidakse üleminekut tihti mitte kõigiga rõõmuga vastu võtta. Inimeste harjumustele on raske muutuda.

Kui inimene teeb harjumuspärast tööd, siis ta teeb seda praktiliselt mitte mõeldes. Selle kognitiivne koormus on null. Ta lihtsalt teeb valmisoleku järgi, tal on peas juba kontroll-loend, ta on seda tuhat korda teinud. Ja kui sa tuled ja ütled talle: "Ära tühista seda praktikat ja alates esmaspäevast rakendame uut", siis see muutub tema jaoks tohutuks kognitiivseks koormuseks. Ja see koormus tuleb kõigi jaoks korraga.

Seega on kõige lihtsam, kuigi tõsi, et mitte kõik ei suuda endale seda luksust lubada, kuid mina teen alati just nii. Kui algab uus projekt, siis tavaliselt sokutatakse sellesse projekti kõik katsetamata praktikad. Kui projekt on noor, ei riskime me eriti millegagi. Prod veel ei eksisteeri, seega pole midagi kaotada. Seetõttu saab seda kasutada treeninguna. Selline lähenemine töötab. Aga mitte kõik ettevõtted ei saa endale lubada selliste projektide tihedat algust. Kuigi see on ka veidi kummaline, kuna praegu toimub pidev digitaalne transformatsioon, peaksid kõik eksperimente käivitama, et konkurentide ees püsida.

Siin tabad end olukorrast, kus sul peab esmalt olema arusaam sellest, mida sa tegema pead. Maailm ei ole ideaalne, prod ka ei ole ideaalne.

Jah, need asjad on omavahel seotud.

Ärivaldkonnas ei ole ka alati selgust, et nad peavad sinna suunda liikuma.

On olukord, kus muutused ei ole üldse võimalikud. See juhtub siis, kui meeskonnale avaldatakse suuremat survet. Meeskond on juba üsna väsinud. Neil pole üldse reservi katsetamiseks. Nad töötavad hommikust õhtuni funktsioonide kallal. Ja juhtkonnale tundub, et funktsioone pole kunagi piisavalt. Nõutakse aina rohkem ja rohkem. Sellises olukorras ei ole üldse mingeid muutusi võimalik teha. Meeskonnale saab öelda ainult, et homme teeme nagu eile, lihtsalt tuleb teha funktsioon veidi rohkem. Mingeid üleminekuid uutele praktikale ei ole võimalik teha. See on klassikaline olukord, kus pole aega kirvest teritada, peab puid langetama, seetõttu langetatakse nurgataguse kirvega. Siin pole lihtsaid nõuandeid.

(Dmitri) Loen välja täpsustuse vestlustest: «Aga vajame suurt testimise katvust erinevatel tasemetel. Kui palju aega testimisele kulutatakse? Tundub, et see on liiga kallis, võtab palju aega.»

(Oleg) See on klassikaline eksiarvamus. Testide peab olema piisavalt, et teil endil oleks kindlus. Continuous Integration ei ole selline asi, kus kõigepealt tehakse 100% teste ja alles siis hakatakse seda praktikat rakendama. Continuous Integration vähendab teie kognitiivset koormust, kuna iga muudatus, mida te näete, on nii ilmselge, et te mõistate – kas see rikub midagi või mitte, isegi ilma testideta. Te saate seda kiiresti oma peas testida, kuna muudatused on väikesed. Isegi kui teil on ainult käsitsi testijad, on neil samuti lihtsam. Te esitate ja ütlete: „Vaata, ei ole midagi katki?” Nad kontrollivad ja ütlevad: „Ei, ei ole midagi katki.” Sest tester teab, kuhu vaadata. Teil on üks commit seotud ühe koodijupiga. Ja see väljendub konkreetses käitumises.

Siin oled sa muidugi natuke ilusamaks teinud.

(Dmitri) Siin ma ei nõustu. On olemas praktika – testimise kaudu arendamine, mis just sellest päästab.

(Oleg) Siin, ma ei ole veel sinna jõudnud. Esimene illusioon on see, et tuleb kirjutada täpselt 100% teste või et Continuous Integrationiga ei tule üldse tegeleda. See ei ole tõsi. Need on kaks paralleelset praktikat ja need ei sõltu otseselt üksteisest. Teie testide katmine peaks olema optimaalne. Optimaalne tähendab, et te olete ise kindel, et see kvaliteet, millega teie master pärast commit'i jääb, lubab teil kindlalt vajutada nuppu 'Deploy' reede õhtul, isegi joobes. Kuidas te seda saavutate? Ülevaatete, katmise ja hea jälgimise kaudu.

Hea jälgimine ei erine testidest. Kui te käivitate teste ainult ühe korra pre prod'is, siis kontrollivad nad teie kõiki kasutajate stsenaariume ainult korra. Kuid kui te neid käivitate lõpmatus tsüklis, siis on see teie rakendatud jälgimisüsteem, mis katab pidevalt kõike – kas on kokku kukkunud või mitte. Sel juhul on vahe ainult korduvuses. Väga hea testide komplekt, mida käivitatakse lõpmatult, on jälgimine. Ja õige jälgimine peaks olema just selline.

Ja seega, kuidas te jõuate sellesse olekusse, kui te reede õhtul oma koodi juurutate ja koju lahkute, on teine küsimus. Võib-olla olete lihtsalt julge peast soe.

Naaseme hetkeks tagasiviivale pidevale integreerimisele. Oleme natuke teise keerulise praktikaga kõrvale pöördunud.

Ja teine illusioon on see, et MVP-d tuleb kiiresti teha, seega pole testid üldse vajalikud. See pole päris nii. Asi on selles, et kui te kirjutate MVP-s user story, siis on selle arendamine võimalik kas kiirelt, st kuulete, et kuskil on mingi user story ja kohe hakkate seda kodeerima, või töötada TDD järgi. Ja TDD praktika näitab, et see ei kesta kauem, st testid on pigem kõrvalmõju. TDD praktika ei seisne mitte testimises. Kuigi see kannab nime Test Driven Development, on seal tegelikult tegemist millegi muuga kui testidega. See on pigem arhitektuuriline lähenemine. See on lähenemine, kuidas kirjutada täpselt seda, mida on vaja, ja mitte kirjutada seda, mis pole vajalik. See praktika keskendub sellele, kuidas järgmist iteratsiooni teie arengu mõttes rakenduse arhitektuuri loomisel saavutada.

Seetõttu ei ole neist illusioonidest nii lihtne vabaneda. MVP ja testid ei excluded üksteist. Tegelikult, vastupidi, kui teete MVP-d TDD praktikaga, siis teete selle paremini ja kiiremini kui lihtsalt proovimata.

See on väga ebamugav ja keeruline mõte. Kui kuulete, et nüüd hakkan kirjutama veel teste ja samal ajal teen midagi kiiremini, kõlab see täiesti ebaadekvaatselt.

(Dmitri) Siin paljud, kui räägivad MVP-st, on inimestel laisk kirjutada midagi korralikku. Need on siiski erinevad asjad. Ärge muutke MVP-d mingiks halvaks asjaks, mis ei tööta.

Jah-jah, sa oled õige.

Ja siis äkki MVP prod.

Igaveseks.

TDD kõlab esialgu väga ebatavaline, kui kuuled, et kirjutad teste ja tundub, et teed rohkem tööd. See võib tunduda kummaline, kuid tegelikult on see tõhusam ja elegantsem. Kui sa kirjutad testi, mõtled juba peas palju selle üle, millist koodi ja kuidas sa kutsud, samuti millist käitumist me sellelt oodata saame. Sa ei ütle lihtsalt, et ma kirjutasin mingi funktsiooni ja see teeb midagi. Esmalt sa mõtled, et sellel on sellised tingimused ja nii kutsutakse seda. Sa katad selle testidega ja seeläbi saad aru, kuidas sinu koodi sees olevad liidesed välja näevad. See mõjutab arhitektuuri väga palju. Su kood muutub automaatselt moodulamaks, sest sa püüad esmalt mõista, kuidas sa seda testida saad, ja alles seejärel kirjutad selle.

Minu TDD teekond oli selline, et ühel hetkel palkasin Ruby mentori, kui olin veel Ruby programmeerija. Ta ütles: "Teeme nii, et sa hakkad TDD-d rakendama." Mõtlesin: "Issand, nüüd pean veel midagi lisaks kirjutama." Lepisime kokku, et ma kirjutangi järgmise kahe nädala jooksul kogu olemasoleva koodi Pythonis TDD põhjal. Kahes nädalas sain aru, et ma ei taha enam tagasi minna. Kahe nädala jooksul püüdes seda igal pool rakendada, mõistsin, kui palju lihtsam on isegi lihtsalt mõelda. Kuid see ei ole ilmselge, seega soovitan kõigil, kellele tundub, et TDD on keeruline, aeganõudev ja üleliigne, proovida seda järgida ainult kaks nädalat. Minule piisab kahest.

(Dmitri) Saame selle mõtte infrastruktuuri käitamise vaatenurgast lahti. Enne kui käivitame midagi uut, teeme me monitooringu ja seejärel käivitame. Sel juhul muutub meie monitooring normaalseks testimiseks. Ja arendamine toimub monitooringu kaudu. Kuid enamik inimesi ütleb, et see võtab kaua aega, mul on laisk, tegin ajutise mustandi. Kui me teeme monitooringu korralikult, saame aru CI süsteemi seisundist. CI süsteemis on palju monitooringut. Saame aru süsteemi seisundist, mõistame, mis selle sees toimub. Ja arendamise ajal loome süsteemi, et see saavutaks soovitud oleku.

Need praktikad on olnud tuntud juba ammu. Arutasime seda umbes 4 aastat tagasi. Kuid nelja aastaga ei ole praktiliselt midagi muutunud.

Käesolevates märkustes soovitan ametliku arutelu lõpetada.

Video (sisestatud meediaelemendina, kuid mikski ei tööta):

https://youtu.be/zZ3qXVN3Oic

Allikas: habr.com