Continuous Integration kui praktika, mitte Jenkins. Andrei Aleksandrov

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

Millist valu CI peaks lahendama, kust idee alguse sai, millised on viimased tõendid, et see toimib, ja kuidas mõista, et teil on olemas praktika, mitte lihtsalt paigaldatud Jenkins.

Mõte pidada ettekannet Continuous Integrationist tekkis juba aastat tagasi, kui käisin tööintervjuudel. Suhtlesin 10-15 ettevõttega, neist vaid üks suutis arusaadavalt vastata, mis on CI ja kuidas nad mõistsid, et neil seda ei ole. Ülejäänud rääkisid arusaamatut juttu Jenkinsist 🙂. Noh, meil on Jenkins, see teeb kogumisi, CI! Ettekanne püüab selgitada, mis on tegelikult Continuous Integration ja miks Jenkins ja sarnased tööriistad on selle suhtes väga nõrgalt seotud.

Nii et, mis tavaliselt tuleb meelde sõna CI kuuldes? Enamiku inimeste jaoks tulevad pähe Jenkins, Gitlab CI, Travis jne.

Isegi kui me otsime seda internetist, siis pakub see meile neid tööriistu.

Kui küsida tuttavatelt, siis kohe pärast tööriistade loetlemist räägitakse, et CI on siis, kui teie Pull Request'is toimub kogumine ja testide läbiviimine.

Continuous Integration ei ole seotud tööriistadega, ei ole seotud kogumiste ja testide tegemisega haru sees! Continuous Integration on praktika, mis hõlmab uue koodi väga sagedast integreerimist, ning selle rakendamiseks ei ole sugugi vajalik Jenkinsite, GitLabi jms ehitamine.

Enne kui vaatame, milline näeb välja täiemahuline CI, süveneme kõigepealt inimestesse, kes selle välja mõtlesid, ja tunnetame seda valu, millega nad püüdsid toime tulla.

Nad lahendasid meeskonnatöö valu!

Vaadakem näiteid, milliste raskustega arendajad meeskonnatöös silmitsi seisavad. Oletame, et meil on projekt, git'te master-haru ja kaks arendajat.

Ja nad läksid tööle, nagu on kaua harjutud. Võtsid ülesande JIRA's, lõid feature haru, kirjutavad koodi.

Üks lõpetas funktsiooni kiiremini ja liitis selle masterisse.

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

Mida keerulisem on oma funktsiooni ühendada üldise põhiga, seda rohkem aega me selleks kulutame. Ja see on veel piisavalt lihtne näide, mida ma näitasin. See on näide, kus arendajaid on vaid 2. Kujutage ette, kui 10 või 15 või 100 inimest ettevõttes kirjutavad ühte hoidlat. Te hakkate ära pöörama, kui kõiki neid konflikte lahendada.

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

Nad on loonud igaühele oma haru.

Üks ühendas, kõik on hästi, ülesanne on valmis.

Teine arendaja samal ajal andis oma ülesande valmis. Oletame, et ta esitas selle ülevaatamiseks. Paljudes ettevõtetes on praktika – ülevaatus. Ühest küljest on see praktika – hea ja kasulik, teisest küljest tõkestab see meid tihti. Ärgem laskugem sellesse sügavale, aga siin on suurepärane näide, kuidas vale ülevaatuse praktika võib põhjustada probleeme. Te esitasite pull request'i ülevaatamiseks. Arendajal pole enam midagi teha. Mida ta hakkab tegema? Ta hakkab võtma teisi ülesandeid.

Selle aja jooksul tegi teine arendaja veel midagi.

Esimene täitis kolmanda ülesande.

Ja pärast mõnda aega, kui tema ülevaatus on läbi viidud, üritab ta uuesti liituda. Ja mis juhtub? Ta satub tohututesse konfliktidesse. Miks? Sest seni, kuni tema pull request oli ülevaatamiseks, muutus koodis palju.

Peale konfliktide on veel teema suhtluses. Seni, kuni teie haru on ülevaatamiseks, seni, kuni see ootab, ja seni, kuni te viibite funktsiooni arendamisega, lõpetate te jälgimise, mis veel teie teenuse koodibaasis muutub. Võib-olla on see, mida te praegu üritate lahendada, juba eile lahendatud ja mingit meetodit saab taaskasutada. Aga te ei näe seda, sest töötate alati vananenud haruga. Ja see vananenud haru toob alati kaasa selle, et peate lahendama ühildamisprobleemi.

Kuna me töötame meeskonnana, st mitte üks inimene ei toimi hoidlas, vaid inimesi on 5-10, siis mida kauem me oma koodi masterisse ei lisa, seda rohkem me kannatame selle tõttu, et lõpuks on vaja midagi ühendama hakata. Ja mida rohkem meil on konflikte ja mida vanema versiooniga me töötame, seda rohkem on meil probleeme.

Koos midagi teha – see on valus! Me segame alati üksteist.

Selle probleemile pöörati tähelepanu üle 20 aasta tagasi. Esimese mainimise praktika Continuous Integration kohta leidsin äärmuslikust programmeerimisest.

Äärmuslik programmeerimine on esimene agile raamistiku element. Lehekülg ilmus 1996. aastal. Idee oli kasutada teatud programmeerimis- ja planeerimistavasid ning muid aspekte, et arendus oleks võimalikult paindlik, et saaksime kiiremini reageerida muutustele ja klientide nõudmistele. 24 aastat tagasi alustasid nad sellega, et kui sa teed midagi väga kaua ja eraldi, kulutad selle asemel rohkem aega, sest tekivad konfliktid.

Nüüd uurime fraasi „Continuous Integration” eraldi sõnadena. Kui tõlkida otse, saame pidev integreerimine. Kuid kui pidev see tegelikult on, ei ole väga selge; see on üsna katkestatud. Samuti ei ole selge, kui palju see on integreerimine.

Ja seetõttu toongi teieni nüüd tsitaate äärmuslikust programmeerimisest. Kaks sõna analüüsime eraldi.

Integreerimine — Nagu juba mainisin, püüame, et iga insener töötaks kõige jõudsamate koodiversioonidega, et ta püüaks oma koodi sageli lisada peavoolu, et need oleksid väiksed harud. Sest kui need on suured, võime lihtsalt nädalaks merge-konfliktidega kinni jääda. Eriti kui meil on pikk arendustsükkel, nagu waterfall, kus arendaja läheb kuuks ajaks tegema mõnda suurt omadust. Ja integreerimise etapis jääb ta tõeliselt pikaks ajaks kinni.

Integreerimine tähendab, et võtame oma haru ja integreerime selle peavooluga, me teeme selle merge. On ka äärmuslik variant, kus me transbase developer, kus me püüame kirjutada otse peavoolu, ilma igasuguste lisaharudeta.

Üldiselt on integreerimine võtta oma kood ja tuua see peavoolu.

Mida mõistetakse sõna „continuous” all, mis on pidevuse mõiste? Praktika tähendab, et arendaja püüab oma koodi integreerida võimalikult kiiresti. See on tema eesmärk igas ülesandes – muuta nii, et tema kood ilmuks masterisse võimalikult kiiresti. Ideaalne maailm oleks see, kus arendajad teevad seda iga paari tunni tagant. T. e. võtad väikese ülesande, mergid selle masterisse. Kõik on suurepärane. Sa püüad seda saavutada. Ja seda tuleb teha pidevalt. Niipea kui oled midagi teinud, surud kohe selle masterisse.

Ja arendaja, kes midagi teeb, on vastutav selle eest, et see toimiks ja midagi ei katki läheks. Siin ilmub tavaliselt välja lugu katsetest. Me tahame käivitada mõningaid teste meie commit’i, meie merge’i kohta, et veenduda, et see töötab. Siin võivad aidata teid Jenkins.

Aga lugudega: las muudatused on väikesed, las ülesanded on väikesed, las teeme ülesande ja proovime kohe selle masterisse mergida – siin ei aita teid Jenkins. Sest Jenkins aitab teid ainult testide käivitamisel.

Sa saad hakkama ka ilma nendeta. See ei sega sind absoluutselt. Sest praktika eesmärk on mergeerida võimalikult tihti, et tulevikus ei peaks kulutama tohutult aega konfliktide lahendamisele.

Kujutage ette, et meil on 2020. aasta ja mingil põhjusel pole internetti. Me töötame kohapeal. Meil ei ole Jenkinsit. See on normaalne. Sa saad ikka võtta ja luua kohalik haru. Sa oled sinna kirjutanud mingi koodi. Tegid ülesande 3-4 tunni jooksul. Lülitusid masterisse, tegid git pulli, mergisid oma haru sinna. Valmis. Kui teed seda sageli – õnnitleme, sul on Continuous Integration!

Millised on tänapäeval tõendid selle kohta, et sellele tasub jõudu rakendada? Sest üldiselt on see keeruline. Kui sa proovid nii töötada, mõistad, et sul on nüüd vaja mingit planeerimist, pead rohkem aega kulutama ülesannete dekompositsioonile. Sest kui sa teed man…, ei saa sa kiiresti mergeerida ja seetõttu satud raskusesse. Praktikat sul enam pole.

Ja see tuleb kallis. Töö Continuous Integration'iga alates järgmise päevast ei õnnestu. Te peate kõik väga kaua harjuma, te harjute väga kaua ülesandeid dekomponeerima, harjute väga kaua oma ülevaatamise praktikat, kui see teil on, muutma. Sest meie eesmärk on, et see sulanduks täna. Ja kui te teete ülevaadet kolme päeva jooksul, siis on teil probleem ja Continuous Integration ei õnnestu teil.

Aga kas meil on mõni praegu oled tõend, mis ütleb meile, et sellesse praktikas investeerimine on mõttekas?

Esimene asi, mis mulle pähe tuli – on State of DevOps. See on uuring, mida poisid teevad juba 7 aastat. Nüüd nad teevad seda sõltumatuna organisatsioonina, aga Google'i all.

Ja nende uuring 2018. aastal näitas seost ettevõtete vahel, kes üritavad kasutada lühiajalisi haru, mis integreeruvad kiiresti ja tihti, nende IT jõudlusnäitajad on oluliselt paremad.

Mis need näitajad on? Need on 4 mõõdikut, mida nad saavad kõikidelt ettevõtetelt oma küsitluste kaudu: deployment frequency, lead time for changes, time to restore service, change failure rate.

Esiteks, on see seos olemas, me teame, et ettevõtetel, kes sulanduvad tihti, on need mõõdikud palju paremad. Ja neil on ettevõtete jagamine mitmesse kategooriasse: aeglased ettevõtted, kes toodavad midagi aeglaselt, keskmine tegija, hea tegija ja eliit. Eliit on Netflix, Amazon, kes on uskumatult kiire, teevad kõik kiiresti, kenasti ja kvaliteetselt.

Teine lugu, mis juhtus kuu aega tagasi. Technology Radar'is ilmus suurepärane märkus Gitflow'ist. Gitflow erineb kõikidest teistest seetõttu, et selle harud elavad kaua. On avaldamis harud, mis elavad kaua, ja funktsiooniharu, mis ka elavad kaua. See praktika on Technology Radar'is liikunud HOLD-i. Miks? Sest inimesed puutuvad kokku integratsioonivaluga.

Kui sul haru elab väga kaua, siis see häilib, läheb vanaks ja me hakkame kulutama rohkem aega, et sellesse mingit muudatust teha.

Ja hiljuti ütles Gitflow autor, et kui püüdlete pideva integreerimise poole ja soovite võimalikult sageli edasi liikuda, on Gitflow halb mõte. Ta täiendavalt märkis artiklis, et kui teil on tagaplaan, kus saate sellele suunata, siis on Gitflow teile liialt koormav, kuna see aeglustab teid ja tekitab integreerimise probleeme.

See ei tähenda, et Gitflow oleks halb ega sobiks kasutamiseks. See on mõeldud teiste olukordade jaoks. Näiteks siis, kui peate toetama mitmeid teenuse või rakenduse versioone, st olukordades, kus peate seda pikema aja jooksul toetama.

Kuid kui suhtlete inimestega, kes selliseid teenuseid toetavad, kuulete palju kaebusi selle kohta, et versioon 3.2 oli neli kuud tagasi ja seal ei olnud selle parandust, ja nüüd, et see parandada, on vajalik teha hulk muudatusi. Ja nad on taas ummikus, veetes nädala selle kallal, et võtta ja liita mingi uus funktsioon.

Kuidas märkis Alexander Kovalev õigesti vestluses, ei tähenda korrelatsioon põhjust ja tagajärge. See on tõsi. Siis ei ole mingit otsest seost, et kui teil on pidev integreerimine, siis on kõik mõõdikud suurepärased. Kuid on positiivne korrelatsioon, et kui üks, siis on tõenäoliselt ka teine. See ei ole fakt, aga tõenäoliselt. See on lihtsalt korrelatsioon.

Tundub, et me juba teeme midagi, näiliselt liitume, kuid kuidas mõista, et meil on ikkagi pidev integreerimine, et me liitume piisavalt sageli?

Jez Humble on raamatu 'Accelerate', Continuous Delivery veebisaidi ja raamatu 'Pidev tarnimine' autor. Ta pakub sellist testi:

• Inseneri kood jõuab meistrisse igapäevaselt.
• Iga commit'i korral käivitate unit-testid.
• Meistri ehitus purunes, see parandati umbes 10 minuti jooksul.

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

Viimase punkti osas olen ma veidi kahtlev. Ehk kui teil õnnestub probleem 10 minuti jooksul lahendada, siis tähendab see, et teil on pidev integratsioon, see kõlab minu arust veidi kahtlaselt, kuid sellel on oma mõte. Miks? Sest kui te teete tihti liitumisi, siis tähendab see, et teie muudatused on väikesed. Kui teie väike muudatus põhjustas põhiharu purunemise, saate kiiresti probleemi tuvastada, sest muudatus on tilluke. Teil oli väike liitumine, mis muutis 20-30 rida. Seega saate kiiresti aru, mis oli põhjuseks, sest muudatused on pisikesed ja teil on probleemide otsimiseks väga väike valdkond.

Ja isegi kui meil pärast väljalaskmist tootmine kokku kukub, teeb pideva integreerimise praktika meie töö palju lihtsamaks, sest muudatused on väikesed. Jah, see mõjutab planeerimist. See on valus. Ja ilmselt on selle praktika kõige raskem osa harjuda ülesandeid jagama, s.t. kuidas võtta midagi ja teha see mõne tunni jooksul, samal ajal kui läbite ülevaatuse, kui see teil on. Ülevaatus on eraldi valu.

Üksuse testid on lihtsalt abivahend, mis aitab teil mõista, kas teie integreerimine õnnestus ja kas midagi läks katki. Minu arvates ei ole see ka kokkuvõttes kohustuslik punkt, sest praktika sisu ei seisne selles.

See on lühidalt pidevast integreerimisest. See on kõik, mis selle praktika kohta on. Olen valmis küsimustele vastama.

Kokkuvõtteks veel kord ütlen:

• Pidev integreerimine ei ole Jenkins, see ei ole Gitlab.
• See ei ole tööriist, see on praktika, mille kohaselt me liidame oma koodi peaharusse võimalikult tihti.
• Teeme seda selleks, et vältida tohutut valu, mis tekib tulevaste liitumistega, s.t. tunneme nüüd väikest valu, et mitte tunda suurt valu tulevikus. See on kogu mõte.
• Koodi kaudu kulgeb suhtlus, kuid ma näen seda väga harva, kuigi selleks see ka mõeldud on.

Küsimused

Mida teha lahti dekompositsiooniga ülesannetega?

Dekomposeerida. Mis probleem? Kas saate tuua näite, et on ülesanne, mida ei saa dekomponeerida?

On olemas ülesandeid, mida ei saa üldse dekomponeerida, näiteks need, mis nõuavad väga sügavat ekspertiisi ja mis võivad tegelikult kesta kuu aega, enne kui mingit arvestatavat tulemust saavutatakse.

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

Jah, kõik on õige. Jah, tulemust saab hinnata mitte varem kui kuu pärast.

Hea. Üldiselt pole see probleem. Miks? Sest antud juhul, kui me räägime harudest, siis me ei räägi harust, millel on funktsioon. Funktsioonid võivad olla suured ja keerulised. Need võivad mõjutada suurt hulka komponente. Ja võib-olla ei suuda me neid täielikult ühte haru panna. See on normaalne. Me peame lihtsalt seda lugu jagama. Kui funktsioon ei ole lõpuni valmis, siis see ei tähenda, et mõned selle koodi tükid ei saa ühineda. Sa lisasid, ütleme, migratsiooni ja funktsiooni sees on mõned etapid. Sul on, ütleme, etapp – teha migratsioon, lisada uus meetod. Ja neid asju saad juba igapäevaselt ühendada.

Hea. Mis siis on selle mõte?

Mis mõte on igapäevaselt väikeste asjade ühinemises?

Jah.

Kui need on sulle midagi katki teinud, näed sa seda kohe. Sul on väike tükk, mis midagi katki tegi, ja sul on lihtsam see parandada. Mõte on see, et praegu on väikese tüki ühendamine palju lihtsam kui midagi suurt ühendamine paar nädalat hiljem. Ja kolmas mõte on see, et teised insenerid töötavad juba aktuaalse koodiversiooniga. Nad näevad, et siin on mõned migratsioonid lisandunud, ja siin on ilmunud mõni meetod, mida nad võib-olla ka soovivad kasutada. Kõik näevad, mis sinu koodis toimub. Just nende kolme asja nimel praktika toimumiski.

Aitäh, küsimus on selge!

(Oleg Soroka) Kas ma võin lisada? Sa ütlesid kõik õigesti, tahan ainult ühte lauset lisada.

Nii.

Continuous Integration'i puhul liidetakse kood ühisesse harusse mitte siis, kui funktsioon on täielikult valmis, vaid siis, kui ehitus on katkenud. Ja võite julgelt pühenduda masterisse nii palju kordi kui soovite päevas. Teine aspekt – kui te ei saa mingil põhjusel kuupikkust ülesannet jagada vähemalt kolmeks päevaks, ma räägin kolmest tunnist, siis on teil suur probleem. Ja see, et teil pole Continuous Integrationi – on selle probleemide seas väikseim. See tähendab, et teil on probleemid arhitektuuriga ja inseneripraktika on null. Sest isegi kui tegemist on uurimistööga, tuleb see igal juhul vormistada hüpoteeside või tsüklina.

Me rääkisime neljast mõõtmetest, mis eristavad edukaid ettevõtteid tagapoolsetest. Enne nende nelja mõõtme saavutamist tuleb veel kõvasti vaeva näha. Kui keskmise ülesande täitmine võtab aega kuu, siis soovitaksin kõigepealt sellele mõõtmele keskenduda. Asetaksin selle esimese kolme päeva piiridesse. Ja alles seejärel alustada pideva arendamise mõtetega.

Kas ma sain õigesti aru, et arvad, et investeerida inseneripraktikatesse pole mõtet, kui sul iga ülesanne võtab kuu aega?

Sul on pidev integreerimine. Seal on selline asi, et sa kas parandad vea 10 minutiga või rullid tagasi. Kujutle, et sa oled selle välja lasknud. Samuti on sul isegi pidev juurutamine, sa oled selle tootmisse saatnud ja alles siis märkad, et midagi läks valesti. Ja nüüd pead selle tagasi rullima, kuid sul on juba toimunud andmebaasi migratsioon. Sinu andmebaasi skeem on juba järgmise versiooni peal, lisaks on toimunud ka mingi varundamine ning sinna on juba andmeid salvestatud.

Mis alternatiiv sul on? Kui sul on kood tagasi rullitud, siis see ei saa enam uuendatud andmebaasiga töötada.

Andmebaas liigub ainult edasi, jah.

Inimestel, kellel on halvad inseneripraktikad, on tõenäoliselt ka paks raamat selle kohta … pole lugenud. Mida teha varundusega? Kui sa taastud varundusest, siis kaotad andmed, mis selle aja jooksul on kogunenud. Näiteks töötasid kolme tunni jooksul uue andmebaasi versiooniga, kus kasutajad registreerusid. Sa taastad vana varunduse, sest uue versiooniga skeem ei tööta, seega need kasutajad, kelle sa kaotasid, on rahulolematud ja kurdavad.

Kogu selle praktikate spektri omandamiseks, mis toetavad Continuous Integration'i ja Continuous Delivery't, ei piisa vaid programmist kirjutamisest ... Esiteks, neid võib olla väga palju, mis muutub ebapraktiiseks. Lisaks on seal palju teisi praktikaid, nagu Scientific. On selline praktika, mida GitHub kunagi populariseeris. See on siis, kui sinu vana kood ja uus kood töötavad samaaegselt. See on siis, kui sa teed puuduolevat funktsiooni, mis võib tagastada mingisuguse väärtuse: kas funktsioonina või Rest API'na. Sa täidad nii uut kui ka vana koodi ja võrdled nende vahelisi erinevusi. Ja kui erinevus on olemas, siis sa logid selle sündmuse. Nii tead, et sinu uus funktsioon on valmis vanale ülesse ehitamiseks, kui sul ei ole teatud aja jooksul nende kahe vahel erinevusi.

Selliseid praktikaid on sadu. Ma soovitaksin alustada transbase arendusega. See ei ole 100 % Continuous Integrationil, kuid praktikad on samad, üks ilma teiselt elab halvasti.

Kas sa tõid transbase arenduse näitena, kust saab praktikaid vaadata, või soovitad sa inimestel hakata kasutama transbase arendust?

Vaadata, kuna nad ei saa seda kasutada. Selleks, et neid kasutada, tuleb palju teavet lugeda. Kui inimesel on küsimus: "Mida teha funktsiooniga, mis võtab kuu aega?", siis see tähendab, et ta ei ole transbase arenduse kohta lugenud. Ja ma ei soovitaks veel kasutada. Ma soovitaksin keskenduda ainult sellele, kuidas õigesti arhitektuurselt suured ülesanded väiksemateks murda. Selles seisnebki dekonstruktsioon.

Dekonstruktsioon on üks arhitekti tööriistadest. Esiteks teeme analüüsi, siis dekonstruktsiooni, seejärel sünteesi ja lõpuks integratsiooni. Nii koondame kõik kokku. Ja arendusele tuleb enne jõuda läbi dekonstruktsiooni. Esimese etapi jooksul tekivad küsimused, aga me räägime juba neljandast etapist, st mida sagedamini integreerida, seda parem. Veel on liiga vara integreerida, võiks esmalt oma monoliti pisut lõhustada.

On some diagram, you need to draw a number of arrows and squares. You can't just say, 'Now I'll show the architectural diagram of the new application and show one square with a green button for the application.' In any case, there will be more squares and arrows. On any diagram I've seen, there were more than one. And decomposition is already done at the level of graphical representation. Therefore, the squares can be independent. If not, then I have big questions for the architect.

There is a question from the chat: 'If the review is mandatory and takes a long time, over a day?'

You have issues with practice. The review shouldn't take more than a day. This is the same story as the previous question, just a bit softer. If the review takes a day, it probably concerns some very large change. It needs to be smaller. In the transbase development that Oleg recommended, there's a concept called continuous review. The idea is that we make pull requests intentionally small because we aim to merge continuously and in small increments. Therefore, a pull request changes one abstraction or 10 lines. This way, our reviews take a couple of minutes.

If a review takes a day or more, then something is wrong. Firstly, you may have some issues with architecture. Either it's a large chunk of code, say, 1,000 lines, or your architecture is so complex that a person cannot understand it. This is a side issue, but it also needs to be addressed. Perhaps, there is no need for a review at all. This is also something to consider. Reviews are the thing that slows you down. They have their benefits overall, but you need to understand why you are doing this. Is it a way for you to quickly pass on information? Is it for you to set certain standards internally, or what? Why do you need this? Because a review needs to be either very quick or completely canceled. This is like transbase development—it’s a very beautiful concept, but only for mature teams.

Regarding the 4 metrics, I would recommend measuring them to understand what they lead to. Look at the numbers, see the picture, how bad it all is.

(Dmitri) Olen valmis arutama seda sinuga. Numbrid ja mõõdikud on kõik suurepärased, praktika on samuti suurepärane. Kuid tuleb aru saada, kas see on äri jaoks vajalik. On ettevõtteid, kellele ei ole vajalik selline muutuste kiirus. Ma tean ettevõtteid, kus muudatusi ei saa teha iga 15 minuti tagant. Ja mitte sellepärast, et nad oleksid halvad. See on elutsükkel. Ja et teostada funktsiooni branches, funktsiooni toggle, on vajalikud sügavad teadmised.

See on keeruline. Kui soovite lugeda lähemalt funktsioonist toggle, siis soovitan väga. https://trunkbaseddevelopment.com/. Ja Martin Fowleril on suurepärane artikkel funktsioonidest toggle: milliseid tüüpe, elutsükleid jne on olemas. Funktsioon toggle on keeruline.

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

Jenkins ei ole tegelikult ühelgi juhul vajalik. Kui tõsiselt rääkida, siis tööriistad: Jenkins, Gitlab toovad teile mugavust. Te näete, kas kogumine õnnestus või mitte. Need võivad teid aidata, kuid nad ei tule teiega praktikat. Nad võivad anda teile lihtsalt ringi – Ok, ei Ok. Ja seda juhul, kui te kirjutate veel teste, sest kui teste ei ole, siis on see peaaegu mõttetu. Seetõttu on see vajalik, kuna see on mugavam, kuid üldiselt on võimalik ka ilma selleta elada, kaotate mitte palju.

St. kui teil on praktika, siis ei ole see teile vajalik?

Täpselt. Soovitan Jez Humble'i testi. Seal mul on viimase punkti suhtes kahetised tunded. Kuid üldiselt, kui teil on kolm asja, te liidate pidevalt, käitate teste commitide peal masteris, kiiresti parandate buildi masteris, siis võib-olla ei ole teil rohkem midagi vaja.

Kuna me ootame osalejatelt küsimusi, on mul küsimus. Me rääkisime praegu toote koodist. Kas oled kasutanud seda infrastruktuuri koodi jaoks. Kas see on sama kood, sellel on samad printsiibid ja sama elutsükkel, või on seal teised elutsüklid ja printsiibid? Tavaliselt, kui kõik räägivad pidevast integreerimisest ja arendamisest, unustatakse, et on ka infrastruktuuri kood. Ja viimasel ajal on seda üha rohkem ja rohkem. Kas peaksime seal rakendama neid reegleid?

Isegi mitte, et peaks, vaid see oleks suurepärane, kuna see lihtsustab elu. Kuni me töötame koodiga, mitte bash-skriptidega, ja meil on korralik kood.

Peatus-peatuse, bash-skript – see on samuti kood. Ära puutu minu vana armastust.

Hea, ma ei hakka sinu mälestusi tallama. Mul on bashi vastu isiklik vastumeelsus. See laguneb rumalalt ja hirmuäratavalt kogu aeg. Ja see laguneb sageli ettearvamatult, seega ei meeldi see mulle. Aga oletame, et sul on bashis kood. Võib-olla ma tõesti ei tea ja seal on normaalsed testimisraamistike. Ma lihtsalt ei ole kursis. Ja me saame samu plusse.

Niipea kui me töötame infrastruktuuriga nagu koodiga, saame kõik samad probleemid nagu arendajad. Mõni kuu tagasi sattusin olukorda, kus kolleeg saatis mulle 1 000 rida bashi pull requesti. Ja sa jääd 4 tunniks seda üle vaatama. Probleemid on samad. See on ikka veel kood. Ja ikka veel koostöö. Me jääme kinni pull requesti ja jääme kinni bashi sama merge-konfliktide lahendamisse.

Ma vaatan praegu väga aktiivselt kogu seda asja maksimaalselt ilusa infrastruktuuri programmeerimise suunas. Olen praegu infrastruktuuri tõmmanud Pulumi. See on puhtalt programmeerimine. Seal on see veelgi ilusam, sest mul on kõik programmeerimiskeele võimalused, st ma tegin sama IF-idega ilusaid toggle-sid ja kõik on hästi. Nimelt, mu muudatus on juba masteris. Seda näevad juba kõik. Teised insenerid on sellest kursis. See on juba millegile mõjutanud. Kuid samas ei aktiveeritud see kõigile infrastruktuuridele. See aktiveeriti näiteks minu testkeskkondade jaoks. Seetõttu, vastates sinu küsimusele veel kord, see on vajalik. See muudab meie elu inseneridena, kes töötavad koodiga, kindlasti lihtsamaks.

Kas kellelgi on veel küsimusi?

Mul on küsimus. Soovin jätkata arutelu Olegiga. Üldiselt arvan, et sa oled õige, et kui ülesanne võtab sul kuu aega, siis sul on arhitektuuri probleem, sul on analüüsi, dekompositsiooni, planeerimise jne probleem. Aga mul on selline tunne, et kui sa hakkad proovima elada Continuous Integration järgi, siis hakkad sa planeerimisega seotud probleeme parandama, sest sa ei pääse sellest enam kuskile.

(Oleg) Jah, kõik on nii. Selle praktika töömaht on võrreldav mis tahes muu tõsise praktikaga, mis muudab kultuuri. Kõige raskem takistuste ületamine on harjumused, eriti halvad harjumused. Ja kui selle praktika rakendamiseks on vaja tõsist harjumuste muutmist ümbritsevate inimeste seas: arendajad, juhtkond, tootmisjuht, siis ootavad teid üllatused.

Millised võivad olla üllatused? Oletame, et otsustasite, et hakkate sagedamini integreerima. Ja teie integreerimisele on seotud veel mingid asjad, näiteks artefaktid. Teie ettevõttes on näiteks poliitika, et iga artefakt peab olema mingil moel arvesse võetud mingis artefaktide ladustamise süsteemis. Ja see võtab aega. Inimene peab märkima, et ta, kui väljaandete haldur, on selle artefakti testinud valmisoleku osas tootmisse viimiseks. Kui see võtab 5-10-15 minutit, aga samal ajal teete väljaandeid kord nädalas, siis nädalas pooltunnine ajakulu ei ole suur maksu.

Kui teete pidevat integreerimist 10 korda päevas, siis tuleb 10 korda korrutada 30 minutiga. Ja see ületab selle väljaandete halduri tööaega. Ta lihtsalt väsib selle tegemisest. Mingid praktikaid on pidevad kulud. Ja kõik.

Ja teil on vaja kas tühistada see reegel, et te ei tegele selliste asjadega, st et te ei määrata käsitsi vastavust millegi suhtes. Te toetute täielikult mingitele automatiseeritud valmisoleku testide komplektidele.

Ja kui teil on kellegilt tõend, et juht allkirjastab, ja te ei liiguta tootmisse, kui Vassja ei ütle, et ta lubab jne – kõik see jama takistab praktikaid. Sest kui mingid tegevused on maksuna seotud, siis kõik kümneid kordi suureneb. Seega ei ole toimetuse muudatus kõigile alati rõõm. Sest inimeste harjumusi on raske muuta.

Kui inimene teeb harjumuspärast tööd, teeb ta seda praktiliselt mitte mõeldes. Selle kognitiivne koormus on null. Ta teeb lihtsalt valmiste pealt, tal on peas juba kontrollnimekiri, ta on seda tuhat korda teinud. Ja kui sa tuled ja ütled talle: „Ärme tee seda praktikat ja alates esmaspäevast rakendame uut,” siis muutub see tema jaoks suureks kognitiivseks koormuseks. Ja see koormus hakkab kõigile koheselt pihta.

Seega on kõige lihtsam, kuigi see luksus ei ole kõigile kergesti kättesaadav, kuid mina teen alati just nii. Kui käivitatakse uus projekt, siis torkavad kõik proovimata praktikad kohe sellesse projekti. Seni, kuni projekt on uus, ei riski me eriti millegagi. Prod pole veel saadaval, pole mida kokku varisema panna. Seetõttu saab seda kasutada treeninguna. Selline lähenemine töötab. Kuid mitte kõik ettevõtted ei saa selliseid projekte sageli alustada. Kuigi see on ka veidi kummaline, kuna praegu toimub pidev digitaalne transformatsioon, peavad kõik katsetusi käivitama, et konkurentidega sammu pidada.

Siin satud sa vastu sellele, et sul peaks alguses olema arusaam sellest, mida sul on vaja teha. Maailm ei ole ideaalne, prod ka ei ole ideaalne.

Jah, need asjad on omavahel seotud.

Äril pole ka alati arusaama, et nad peavad minema just sinna, kuhu peab.

On olukord, kus ei ole mingid muudatused üldse võimalikud. See on olukord, kus meeskonnale avaldatakse suuremat survet. Meeskond on juba üsna läbipõlenud. Neil ei ole enam mingit reservaega katsetuste jaoks. Nad töötavad hommikust õhtuni funktsioonide kallal. Ja juhtkonnale on funktsioonidest alati vähe. Nõutakse üha rohkem ja rohkem. Sellises olukorras ei ole üldse mingid muudatused võimalikud. Meeskonnale saab vaid öelda, et homme teeme täpselt nii nagu eile, lihtsalt tuleb teha funktsioone natuke rohkem. Mingid üleminekud mingitesse praktikatesse selles mõttes ei ole võimalikud. See on klassikaline olukord, kus pole aega kirvest teritada, peab puid langetama, seega langetatakse tuima kirvega. Siin lihtsaid nõuandeid ei ole.

(Dmitri) Loen välja täpsustuse vestlusest: „Aga vajavad suurt testimise katet erinevatel tasanditel. Kui palju aega pühendatakse testimisele? See on kuidagi kallis, võtab palju aega.”

(Oleg) See, this is a classic misconception. There should be enough tests to ensure your own confidence. Continuous Integration is not something where you first run 100% of the tests and only then start applying this practice. Continuous Integration reduces your cognitive load because each change you see is so obvious that you understand whether it will break something or not, even without tests. You can quickly test it in your mind because the changes are small. Even if you only have manual testers, it’s easier for them too. You roll out a change and say: 'Look, did anything break?' They check and reply: 'No, nothing is broken.' Because the tester knows where to look. You have one commit related to one piece of code. And this exploits specific behavior.

Here you certainly embellished.

(Dmitry) I disagree here. There is a practice — test-driven development, which will help with this.

(Oleg) Well, I haven't reached that yet. The first illusion is that you need to write exactly 100% of tests or you shouldn't engage in Continuous Integration at all. This is false. These are two parallel practices. And they do not directly depend on each other. Your test coverage should be optimal. Optimal means that you confidently believe that the quality of the master branch after your commit allows you to confidently click the 'Deploy' button on a Friday evening, even if you've had a few drinks. How do you achieve this? Through reviews, through coverage, through good monitoring.

Good monitoring is indistinguishable from tests. If you run tests once on pre-prod, they check all your user scenarios only once. But if you run them in an endless loop, it becomes your deployed monitoring system that tests everything infinitely—whether it has crashed or not. In this case, the difference lies only in whether it's done once or repeatedly. A very good set of tests..., run infinitely, is monitoring. And proper monitoring should be like that.

And so how exactly you will achieve that state when you deploy on a Friday evening and go home is another question. Perhaps you are just a bold maverick.

Naasime tagasi veidi Continuous Integration'i juurde. Oleme põgenenud veidi teise keerulisse praktikasse.

Ja teine illusioon on see, et MVP-d tuleb kiiresti teha, seega katsetele pole seal üldse kohta. Asi ei ole nii. Nimelt, kui kirjutate MVP-s user story, siis selle arendamine võib toimuda kas lihtsalt kuulmise põhjal — kuulete, et on mingi user story ja jooksete seda kohe kodeerima — või TDD põhjal. Ja TDD puhul, nagu praktika näitab, ei kesta see kauem; testid on pigem kõrvaltoime. TDD praktika ei seisne testimises. Hoolimata sellest, et see on nimega Test Driven Development, ei ole seal tegemist tõeliselt testidega. See on pigem arhitektuuri lähenemine. See on lähenemine, kuidas kirjutada just seda, mida on vaja, ja mitte kirjutada seda, mida ei ole vaja. See praktika keskendab teie edasise mõtlemise iteratsioonile rakenduse arhitektuuri loomise osas.

Seepärast ei ole neid illusioone nii lihtne purustada. MVP ja testid ei vastandu teineteisele. Pigem vastupidi: kui teete MVP-d TDD praktika kohaselt, teete seda paremini ja kiiremini kui siis, kui teete seda lihtsalt ilma praktikata.

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

(Dmitri) Siin, kui paljud nimetavad MVP-d, on inimesed laisad, et kirjutada midagi normaalset. Ja need on ikkagi erinevad asjad. MVP-d ei tohiks muuta millekski halbaks ja mitte toimivaks.

Jah-jah, sa oled õigus.

Ja siis ühel hetkel on MVP tootmises.

Igaveseks.

Ja TDD kõlab väga harjumatult, kui kuuled, et kirjutad teste ja justkui teed rohkem tööd. See kõlab väga kummaliselt, kuid tõesti, see teeb asja kiiremini ja atraktiivsemalt. Kui kirjutate testi, mõtletem sellega juba palju, milline kood on ja kuidas see kutset saab, ning millist käitumist me sellelt ootame. Te ei ütle lihtsalt, et ma olen kirjutanud mingi funktsiooni ja see teeb midagi. Te mõtlete kõigepealt sellele, et tal on sellised tingimused, ja see kutsub teatud viisil esile. Te katate selle testidega ja sellega mõistate, millised on teie koodi sisemised liidesed. See mõjutab arhitektuuri väga palju. Teie kood muutub automaatselt modulaarsemaks, sest te üritate esmalt aru saada, kuidas te seda katsetate, ja alles seejärel kirjutate selle.

Mul on TDD lähenemisega nii, et mingil hetkel palkasin Ruby mentori, kui olin veel Ruby programmeerija. Ta ütles: „Teeme nii, et teed TDD järgi.” Ja ma mõtlesin: „Kurrat, nüüd tuleb jällegi midagi juurde kirjutada.” Lepisime kokku, et järgmise kahe nädala jooksul kirjutan kogu töötava koodi Pythonis TDD järgi. Kahe nädala pärast sain aru, et ma ei taha enam tagasi minna. Püüdes neid kahte nädalat igal pool rakendada, mõistsin, kui palju lihtsam on isegi lihtsalt mõelda. Aga see ei ole ilmselge, seega soovitan kõigil, et kui teil on tunne, et TDD – see on keeruline, pikk ja liig, proovige seda järgida vähemalt kaks nädalat. Mul piisab kahest, et seda mõista.

(Dmitri) Saame seda mõtet arendada infrastruktuuri ekspluateerimise vaatenurgast. Enne kui me midagi uut deployime, teeme jälgimise ning seejärel käivitame. Sel juhul muutub meie jälgimine tavaliseks testimiseks. Ja on olemas arendamine läbi jälgimise. Kuid enamik ütleb, et see on pikk, mul on laisk, ma tegin ajutise mustandi. Kui me saydime korraliku jälgimise, saame aru CI süsteemi olekust. Ja CI süsteemis on palju jälgimist. Me mõistame süsteemi seisundit, me teame, mis tal sees on. Ja arenduse käigus loome süsteemi, et see jõuaks soovitud olekusse.

Need praktikad on olnud tuntud juba ammu. Me arutasime seda umbes 4 aastat tagasi. Kuid viimase 4 aastaga pole praktiliselt midagi muutunud.

Kuid selle märkmega pakun ametliku arutelu lõpetamiseks.

video (sisestatud meediaelemendina, kuid mingil põhjusel ei tööta):

https://youtu.be/zZ3qXVN3Oic

Allikas: habr.com