Arutame, miks CI tööriistad ja CI on täiesti erinevad asjad.
Millist valu on CI mõeldud lahendama, kust tuli idee, millised on viimased kinnitused selle toimimise kohta, kuidas aru saada, et sul on praktika, mitte lihtsalt Jenkins installitud.
Idee teha aruanne pideva integratsiooni kohta tekkis aasta tagasi, kui käisin intervjuudel ja tööd otsimas. Rääkisin 10-15 ettevõttega, ainult üks neist suutis selgelt vastata, mis on CI, ja selgitada, kuidas nad said aru, et neil seda pole. Ülejäänud rääkisid Jenkinsist arusaamatut jama :) Noh, meil on Jenkins, see ehitab, CI! Raporti käigus püüan selgitada, mis on pidev integreerimine ja miks on Jenkinsil ja sarnastel tööriistadel sellega väga nõrk seos.
Mis siis tavaliselt meelde tuleb, kui kuulete sõna CI? Enamik inimesi mõtleb Jenkinsile, Gitlab CI-le, Travisele jne.
Isegi kui me seda googeldame, annab see meile need tööriistad.
Kui olete küsimisega tuttav, ütlevad nad teile kohe pärast tööriistade loetlemist, et CI on siis, kui koostate ja käivitate kohustuse tõmbamistaotluse teste.
Pidev integreerimine ei tähenda tööriistu, mitte filiaali testidega komplekte! Pidev integreerimine on uue koodi väga sagedane integreerimine ja selle kasutamiseks pole üldse vaja Jenkinsi, GitLabi jne.
Enne kui mõtleme välja, milline täisväärtuslik CI välja näeb, sukeldume esmalt nende inimeste konteksti, kes selle välja mõtlesid ja tunneme valu, mida nad lahendada püüdsid.
Ja nad lahendasid ühise meeskonnatöö valu!
Vaatame näiteid raskustest, millega arendajad meeskonnatöös arenemisel kokku puutuvad. Siin on meil projekt, giti põhiharu ja kaks arendajat.
Ja nad läksid tööle, nagu kõik olid juba ammu harjunud. Võtsime ülesande suures plaanis, lõime funktsiooniharu ja kirjutasime koodi.
Üks lõpetas funktsiooni kiiremini ja ühendas selle põhiprogrammiga.
Teine vajas rohkem aega, see sulas hiljem kokku ja lõppes konfliktiga. Nüüd kulutab arendaja selle asemel, et kirjutada ettevõttele vajalikke funktsioone, oma aega ja energiat konfliktide lahendamisele.
Mida keerulisem on ühendada oma funktsiooni ühise meistriga, seda rohkem aega kulutame sellele. Ja ma näitasin seda üsna lihtsa näitega. See on näide, kus arendajaid on ainult 2. Kujutage ette, kui ühte hoidlasse kirjutab ettevõttes 10 või 15 või 100 inimest. Sa lähed hulluks, et kõiki neid konflikte lahendada.
On veidi teistsugune juhtum. Meil on meister ja mõned arendajad midagi tegemas.
Nad lõid oksa.
Üks suri, kõik oli korras, sai ülesandest läbi.
Teine arendaja andis vahepeal oma ülesande üle. Oletame, et ta saatis selle ülevaatamiseks. Paljudel ettevõtetel on tava, mida nimetatakse läbivaatamiseks. Ühest küljest on see praktika hea ja kasulik, teisalt aga pidurdab meid mitmel viisil. Me ei hakka sellesse laskuma, kuid siin on suurepärane näide sellest, milleni võib halb ülevaatelugu viia. Olete esitanud tõmbetaotluse ülevaatamiseks. Arendajal pole enam midagi teha. Mida ta tegema hakkab? Ta hakkab võtma muid ülesandeid.
Selle aja jooksul tegi teine arendaja midagi muud.
Esimene täitis kolmanda ülesande.
Ja mõne aja pärast testiti tema arvustust ja ta püüab leppida. Mis siis toimub? See tabab tohutul hulgal konflikte. Miks? Sest kuigi tema tõmbamistaotlus ülevaatuses rippus, oli palju asju koodis juba muutunud.
Lisaks konfliktidega loole on lugu suhtlusega. Sel ajal, kui teie lõim on ülevaatuses, kui see midagi ootab, kui töötate funktsiooni kallal pikka aega, lõpetate teie teenuse koodibaasis veel muutuvate asjade jälgimise. Võib-olla lahendati see, mida proovite praegu lahendada, juba eile ja võite võtta mõne meetodi ja seda uuesti kasutada. Kuid te ei näe seda, sest töötate alati vananenud haruga. Ja see aegunud haru toob alati kaasa selle, et peate ühendamise konflikti lahendama.
Selgub, et kui töötame meeskonnana, st hoidlas ei tuhni mitte üks inimene, vaid 5-10 inimest, siis mida kauem me oma koodi masterile ei lisa, seda rohkem kannatame, sest lõpuks vajame. midagi siis ühendage see. Ja mida rohkem konflikte meil on ja mida vanema versiooniga me töötame, seda rohkem on meil probleeme.
Midagi koos teha on valus! Me jääme alati üksteise teele.
Seda probleemi märgati rohkem kui 20 aastat tagasi. Leidsin esimese mainimise äärmusliku programmeerimise pideva integreerimise praktikast.
Extreme Programming on esimene vilgas raamistik. Leht ilmus 96. aastal. Ja idee oli kasutada mingisuguseid programmeerimispraktikaid, planeerimist ja muud, et arendus oleks võimalikult paindlik, et saaksime kiiresti reageerida klientide muutustele või nõudmistele. Ja sellega hakkasid nad silmitsi seisma 24 aastat tagasi, et kui sa teed midagi väga kaua ja kõrvalt, siis sa kulutad sellele rohkem aega, sest sul on konflikte.
Nüüd analüüsime fraasi "pidev integratsioon" eraldi. Kui tõlgime selle otse, saame pideva integratsiooni. Kuid kui pidev see on, pole väga selge; see on väga katkendlik. Kuid see, kui palju see on integreeritud, pole samuti väga ilmne.
Ja sellepärast annan teile nüüd tsitaate Extreme Programmingust. Ja me analüüsime mõlemat sõna eraldi.
Integratsioon – Nagu ma juba ütlesin, püüame tagada, et iga insener töötaks koodi uusima versiooniga, nii et ta püüab lisada oma koodi nii sageli kui võimalik ühisesse harusse, nii et need oleksid väikesed harud. Sest kui need on suured, siis võime kergesti nädalaks ajaks jänni jääda. See kehtib eriti siis, kui meil on pikk arendustsükkel, näiteks juga, kus arendaja läks kuuks ajaks ära, et mõnda tohutut funktsiooni kärpida. Ja ta jääb integratsioonifaasis väga pikaks ajaks kinni.
Integratsioon on see, kui me võtame oma haru ja integreerime selle masteriga, ühendame selle. Kui oleme transbase arendaja, on ülim variant, mille puhul püüame tagada, et kirjutaksime kohe masterile ilma täiendavate harudeta.
Üldiselt tähendab integreerimine koodi võtmist ja selle juhtseadmesse lohistamist.
Mida mõeldakse siin sõna "pidev" all, mida nimetatakse järjepidevuseks? Praktika eeldab, et arendaja püüab oma koodi võimalikult kiiresti integreerida. See on tema eesmärk mis tahes ülesande täitmisel - saada oma kood võimalikult kiiresti masterisse. Ideaalses maailmas teeksid arendajad seda iga paari tunni järel. See tähendab, et võtate väikese probleemi ja ühendate selle kapteniks. Kõik on hästi. See on see, mille poole te püüdlete. Ja seda tuleb teha pidevalt. Niipea, kui midagi teed, paned selle kohe meistrile.
Ja arendaja, kes midagi teeb, vastutab selle eest, mida ta tegi, et see toimiks ja midagi ei lõhuks. Siin tuleb tavaliselt välja testlugu. Tahame läbi viia mõned testid oma kohustuse ja liitmise kohta, et veenduda selle toimimises. Ja siin saab Jenkins teid aidata.
Aga lugudega: teeme muudatused väikeseks, laseme ülesannetel olla väikesed, teeme probleemi ja proovime seda kohe kuidagi masterisse põimida - siin ei aita ükski Jenkins. Sest Jenkins aitab teil ainult teste läbi viia.
Saate ilma nendeta hakkama. See ei tee sulle sugugi haiget. Sest harjutamise eesmärk on mõõta nii tihti kui võimalik, et mitte raisata tulevikus tohutult aega mingite konfliktide peale.
Kujutagem ette, et millegipärast oleme 2020. aastal ilma Internetita. Ja me töötame kohapeal. Meil ei ole Jenkinsit. See sobib. Võite siiski minna ja teha kohaliku filiaali. Sa kirjutasid sinna mingi koodi. Ülesande täitsime 3-4 tunniga. Lülitusime masterile, tegime git pulli ja ühendasime oma haru sinna. Valmis. Kui teete seda sageli, õnnitleme, teil on pidev integreerimine!
Millised on tänapäeva maailmas tõendid selle kohta, et selle peale tasub energiat kulutada? Sest üldiselt on see raske. Kui proovite niimoodi töötada, saate aru, et mõningane planeerimine on nüüd mõjutatud, peate pühendama rohkem aega ülesannete lagunemisele. Sest kui sa teed..., siis sa ei suuda kiiresti leppida ja vastavalt sellele satud hätta. Teil pole enam praktikat.
Ja see läheb kalliks. Pideva integratsiooni abil ei saa homsest kohe töötada. Teil kõigil kulub väga kaua aega, et sellega harjuda, kulub väga kaua aega, et harjuda ülesannete lagundamisega, kulub väga kaua aega, et harjuda ülevaatuse praktika uuesti tegemisega, kui see teil on . Sest meie eesmärk on, et see täna sulaks. Ja kui teete ülevaatuse kolme päeva jooksul, siis on teil probleeme ja pidev integreerimine ei tööta teie jaoks.
Kuid kas meil on praegu asjakohaseid tõendeid, mis ütlevad meile, et sellesse praktikasse investeerimine on mõttekas?
Esimene asi, mis mulle meelde tuli, oli State of DevOps. See on uuring, mida poisid on läbi viinud 7 aastat. Nüüd teevad nad seda iseseisva organisatsioonina, kuid Google'i all.
Ja nende 2018. aasta uuring näitas korrelatsiooni ettevõtete vahel, kes üritavad kasutada lühiajalisi harusid, mis integreeruvad kiiresti, integreeruvad sageli ja millel on paremad IT-näitajad.
Mis need näitajad on? Need on 4 mõõdikut, mida nad küsitlustes võtavad kõigilt ettevõtetelt: juurutamise sagedus, muudatuste tegemise aeg, teenuse taastamise aeg, muudatuste tõrgete määr.
Ja esiteks on see korrelatsioon, me teame, et sageli mõõtvatel ettevõtetel on palju paremad mõõdikud. Ja neil on ettevõtted jaotatud mitmesse kategooriasse: need on aeglased ettevõtted, mis toodavad midagi aeglaselt, keskmise jõudlusega, kõrge jõudlusega ja eliit. Eliit on Netflix, Amazon, mis on ülikiired, teevad kõike kiiresti, kaunilt ja tõhusalt.
Teine lugu, mis juhtus vaid kuu aega tagasi. Tehnoloogiaradaril on Gitflow kohta suurepärane artikkel. Gitflow erineb kõigist teistest selle poolest, et selle oksad on pikaealised. On oksi, mis elavad pikka aega, ja oksi, mis elavad ka pikka aega. See tehnoloogiaradari praktika on kolinud HOLD-i. Miks? Sest inimesed seisavad silmitsi integratsioonivaluga.
Kui teie oks elab väga kaua, jääb see kinni, läheb mäda ja me hakkame rohkem aega kulutama, et seda muuta.
Ja hiljuti ütles Gitflow autor, et kui teie eesmärk on pidev integreerimine, kui teie eesmärk on see, et soovite võimalikult sageli rullida, on Gitflow halb mõte. Eraldi lisas ta artiklile, et kui sul on tagaprogramm, kus saad selle poole püüelda, siis on Gitflow sinu jaoks üleliigne, sest Gitflow pidurdab sind, Gitflow tekitab sulle integratsiooniga probleeme.
See ei tähenda, et Gitflow on halb ja seda ei tohiks kasutada. See on mõeldud muudeks puhkudeks. Näiteks kui teil on vaja toetada teenuse või rakenduse mitut versiooni, st kui vajate tuge pikka aega.
Aga kui rääkida inimestega, kes selliseid teenuseid toetavad, siis kuulete palju valu sellest, et see versioon oli 3.2, mis oli 4 kuud tagasi, aga seda parandust sellesse ei lisatud ja nüüd, et seda teha, peate tegema hunniku muudatusi. Ja nüüd on nad jälle ummikus ja nüüd on nad nädal aega ringi askeldanud, proovides mõnda uut funktsiooni rakendada.
Nagu Aleksander Kovalev vestluses õigesti märkis, ei ole korrelatsioon sama mis põhjuslik seos. See on tõsi. See tähendab, et puudub otsene seos, et kui teil on pidev integreerimine, on kõik mõõdikud suurepärased. Kuid on positiivne korrelatsioon, et kui üks on üks, siis tõenäoliselt on ka teine. Mitte tõsiasi, aga suure tõenäosusega. See on lihtsalt korrelatsioon.
Tundub, et me juba teeme midagi, tundub, et me juba ühineme, aga kuidas me saame aru, et meil on veel Pidev Integratsioon, et me ühineme üsna sageli?
Jez Humble on raamatute Handbook, Accelerate, Continuous Delivery veebisaidi ja raamatu Continuous Delivery autor. Ta pakub seda testi:
- Inseneri kood jõuab kaptenini iga päev.
- Iga kohustuse puhul käivitate ühikutestid.
- Meistri ehitus kukkus, see sai korda umbes 10 minutiga.
Ta soovitab kasutada sellist testi, et veenduda, kas teil on piisavalt praktikat.
Minu arvates on see viimane veidi vastuoluline. See tähendab, et kui saate selle 10 minutiga parandada, siis on teil pidev integreerimine, see kõlab minu arvates veidi kummaliselt, kuid see on mõistlik. Miks? Sest kui sa külmutad sageli, tähendab see, et sinu muutused on väikesed. Kui väike muudatus tähendab, et teie põhiversioon on katki, leiate näite kiiresti, kuna muudatus on väike. Siin oli teil väike liitmine, 20-30 rida selles muutus. Ja vastavalt saate kiiresti aru, mis oli põhjus, sest muutused on väikesed, teil on probleemi otsimiseks väga väike ala.
Ja isegi kui meie prod laguneb pärast vabastamist, siis kui meil on pideva integratsiooni praktika, on meil palju lihtsam tegutseda, sest muutused on väikesed. Jah, see mõjutab planeerimist. See teeb haiget. Ja ilmselt on selles praktikas kõige keerulisem harjuda ülesannete lammutamisega ehk kuidas seda teha nii, et saaksid midagi võtta ja mõne tunniga ära teha ning samal ajal ka ülevaatuse läbida, kui sul on üks. Ülevaatamine on omaette valu.
Ühiktestid on lihtsalt abiline, mis aitab teil mõista, kas teie integreerimine õnnestus ja kas midagi ei olnud katki. Minu arvates pole see ka täiesti kohustuslik, sest see pole praktika mõte.
See on pidev sissejuhatus pidevale integratsioonile. See on kõik, mis selle praktikaga kaasneb. Olen küsimusteks valmis.
Teen uuesti lühidalt kokkuvõtte:
- Pidev integreerimine ei ole Jenkins, see pole Gitlab.
- See ei ole tööriist, see on tava, et me liidame oma koodi nii tihti kui võimalik masterisse.
- Teeme seda selleks, et tulevikus vältida tohutut valu, mis tekib ühinemistega ehk kogeme praegu veidi valu, et mitte edaspidi rohkem kogeda. See on kogu asja mõte.
- Küljel on side koodi kaudu, kuid ma näen seda väga harva, kuid see on ka see, mille jaoks see on mõeldud.
küsimused
Mida teha lagunemata ülesannetega?
Lagundada. Milles on probleem? Kas saate tuua näite, et ülesanne on olemas ja seda ei lagundata?
On ülesandeid, mida ei saa lahti sõnast “täiesti”, näiteks selliseid, mis nõuavad väga sügavat asjatundlikkust ja mida saab tegelikult lahendada kuu aja jooksul, et saavutada mingi seeditav tulemus.
Kui ma teist õigesti aru saan, siis on mingi suur ja keeruline ülesanne, mille tulemust saab näha alles kuu aja pärast?
Jah see on õige. Jah, tulemust on võimalik hinnata mitte varem kui kuu aja pärast.
Hästi. Üldiselt pole see probleem. Miks? Sest antud juhul, kui me räägime okstest, ei räägi me mingi tunnusega oksast. Funktsioonid võivad olla suured ja keerulised. Need võivad mõjutada suurt hulka komponente. Ja võib-olla ei saa me neid täielikult ühes harus teha. See sobib. Peame selle loo lihtsalt katkestama. Kui funktsioon pole täielikult valmis, ei tähenda see, et mõnda selle koodi osa ei saaks ühendada. Lisasite näiteks migratsiooni ja funktsiooni sees on mõned etapid. Oletame, et teil on etapp – tehke migratsioon, lisage uus meetod. Ja neid asju saab juba iga päev mõõta.
Hästi. Mis mõte sellel siis on?
Mis mõtet on iga päev väikseid asju tappa?
Jah.
Kui nad midagi lõhuvad, näete seda kohe. Kui teil on väike tükk, mis on midagi katki teinud, on teil lihtsam seda parandada. Asi on selles, et väikese tüki liitmine praegu on palju lihtsam kui mõne suure asja liitmine mõne nädala pärast. Ja kolmas punkt on see, et teised insenerid töötavad koodi praeguse versiooniga. Nad näevad, et siia on lisatud mõned migratsioonid ja siis on ilmunud mingi meetod, mida nad võivad samuti kasutada. Kõik näevad, mis teie koodis toimub. Nende kolme asja jaoks harjutatakse.
Täname, teema on suletud!
(Oleg Soroka) Kas tohin lisada? Sa ütlesid kõik õigesti, tahan lisada vaid ühe fraasi.
Так.
Pideva integreerimisega liidetakse kood ühiseks haruks mitte siis, kui funktsioon on täielikult valmis, vaid siis, kui ehitamine lõpetab purunemise. Ja võite julgelt pühenduda meisterdamisele nii mitu korda päevas, kui soovite. Teine aspekt on see, et kui sa mingil põhjusel ei saa igakuist ülesannet vähemalt kolmeks päevaks ülesanneteks jaotada, ma olen umbes kolm tundi vait, siis on sul suur probleem. Ja asjaolu, et teil pole pidevat integratsiooni, on nendest probleemidest vähim. See tähendab, et teil on probleeme arhitektuuri ja nullinseneripraktikaga. Sest isegi kui see on uurimustöö, siis igal juhul tuleb see sõnastada hüpoteeside või tsükli vormis.
Rääkisime neljast mõõdikust, mis eristavad edukaid ettevõtteid mahajäänutest. Peame veel elama, et neid nelja mõõdikut näha. Kui teie keskmise ülesande täitmiseks kulub kuu, keskenduksin kõigepealt sellele mõõdikule. Ma vähendaksin seda kõigepealt 4 päevani. Ja peale seda hakkasin mõtlema Continuousi peale.
Kas ma sain õigesti aru, et arvate, et üldiselt pole mõtet inseneripraktikatesse investeerida, kui mõne ülesande täitmiseks kulub kuu aega?
Teil on pidev integratsioon. Ja seal on selline teema, et 10 minutiga saab kas paranduse parandada või tagasi kerida. Kujutage ette, et rullisite selle välja. Lisaks on teil isegi pidev juurutamine, rullusite selle välja ja alles siis märkasite, et midagi läks valesti. Ja peate selle tagasi kerima, kuid olete oma andmebaasi juba üle viinud. Sul on juba järgmise versiooni andmebaasi skeem olemas, pealegi oli sul ka mingi varukoopia ning sinna olid ka andmed kirjas.
Ja mis alternatiiv teil on? Kui keerate koodi tagasi, ei saa see enam selle värskendatud andmebaasiga töötada.
Alus liigub ainult edasi, jah.
Inimesed, kellel on kehvad inseneritavad, pole tõenäoliselt lugenud ka paksu raamatut.... Mida teha varukoopiaga? Kui taastate varukoopiast, tähendab see, et kaotate selle hetke jooksul kogutud andmed. Näiteks töötasime andmebaasi uue versiooniga kolm tundi, kasutajad registreerusid sinna. Keeldute vanast varukoopiast, kuna skeem ei tööta uue versiooniga, seega olete need kasutajad kaotanud. Ja nad on rahulolematud, vannuvad.
Pidevat integreerimist ja pidevat tarnimist toetavate tavade täieliku valiku valdamiseks ei piisa ainult kirjutamise õppimisest.... Esiteks võib neid olla palju, see on ebapraktiline. Lisaks on palju muid tavasid, nagu teaduslik. Selline praktika on olemas, GitHub populariseeris seda omal ajal. See on siis, kui teil töötab korraga nii vana kood kui ka uus kood. See on siis, kui loote lõpetamata funktsiooni, kuid see võib tagastada teatud väärtuse: kas funktsioonina või Rest API-na. Käivitate nii uue kui ka vana koodi ja võrdlete nende vahelist erinevust. Ja kui on erinevus, siis logige see sündmus. Nii teate, et teil on uus funktsioon, mis on valmis kasutusele võtma vana asemel, kui teil pole teatud aja jooksul nende kahe vahel lahknevusi olnud.
Selliseid praktikaid on sadu. Soovitaksin alustada transbase arendamisega. Ta ei ole 100% pideval integratsioonil, kuid tavad on samad, üks ei saa ilma teiseta hästi elada.
Kas tõite näitena transbaaside arendamise, kus näete praktikaid, või soovitate inimestel hakata kasutama transbaaside arendamist?
Vaadake, sest nad ei saa seda kasutada. Nende kasutamiseks peate palju lugema. Ja kui inimene küsib: "Mida teha funktsiooniga, mis võtab kuu aega, tähendab see, et ta pole transbase arenduse kohta lugenud." Ma ei soovitaks seda veel. Soovitaksin keskenduda ainult teemale, kuidas suuri ülesandeid arhitektuurselt õigesti väiksemateks jaotada. See on lagunemise olemus.
Lagundamine on üks arhitekti töövahendeid. Esmalt teeme analüüsi, siis dekompositsiooni, siis sünteesi ja siis integreerimise. Ja nii läheb meil kõik korda. Ja me peame ikkagi lagunemise kaudu kasvama pideva integratsioonini. Küsimused tekivad esimeses etapis ja me räägime juba neljandast etapist, st mida sagedamini integratsiooni teeme, seda parem. Seda on veel liiga vara teha; tore oleks kõigepealt oma monoliit maha lõigata.
Mõnele skeemile peate joonistama hulga nooli ja ruute. Ei saa öelda, et nüüd näitan uue rakenduse arhitektuurset skeemi ja näitan ühte ruutu, mille sees on rakenduse jaoks roheline nupp. Igal juhul tuleb ruute ja nooli rohkem. Igal diagrammil, mida nägin, oli rohkem kui üks. Ja lagunemine, isegi graafilise esituse tasemel, juba toimub. Seetõttu saab ruudud iseseisvaks muuta. Kui ei, siis on mul arhitektile suured küsimused.
Vestlusest tuleb küsimus: "Kui ülevaatus on kohustuslik ja võtab kaua aega, võib-olla päeva või rohkem?"
Teil on harjutamisega probleeme. Ülevaatus ei tohiks kesta päeva või kauem. See on sama lugu eelmise küsimusega, ainult veidi pehmem. Kui ülevaatamine kestab päeva, siis tõenäoliselt toimub see ülevaatus mõne väga suure muutuse juures. See tähendab, et seda tuleb väiksemaks muuta. Transbase arenduses, mida Oleg soovitas, on lugu nimega pidev ülevaade. Tema idee seisneb selles, et me teeme sellise väikese tõmbetaotluse meelega, sest püüame pidevalt ja vähehaaval sulanduda. Ja nii muudab tõmbamistaotlus ühte abstraktsiooni või 10 rida. Tänu sellele ülevaatele kulub meil selleks paar minutit.
Kui ülevaatamiseks kulub päev või rohkem, on midagi valesti. Esiteks võib teil tekkida probleeme arhitektuuriga. Või on see suur koodijupp, näiteks 1 rida. Või on teie arhitektuur nii keeruline, et inimene ei saa sellest aru. See on veidi kõrvaline probleem, kuid see tuleb ka lahendada. Võib-olla pole ülevaatamist üldse vaja. Peame ka sellele mõtlema. Ülevaatamine on asi, mis aeglustab. Sellel on üldiselt oma eelised, kuid peate mõistma, miks te seda teete. Kas see on teie viis kiiresti teavet edastada, kas see on viis, kuidas saate kehtestada sisemiselt mingeid standardeid või mis? Miks sa seda vajad? Sest ülevaatus tuleb teha kas väga kiiresti või üldse ära jätta. See on nagu transbase deveploment - lugu on väga ilus, kuid ainult küpsetele meestele.
Seoses nelja mõõdikuga soovitaksin need siiski eemaldada, et mõista, milleni see viib. Vaata numbreid, vaata pilti, kui halvasti kõik on.
(Dmitry) Olen valmis teiega sellel teemal arutelu alustama. Numbrid ja mõõdikud on kõik suurepärased, tavad on suurepärased. Kuid peate mõistma, kas ettevõte seda vajab. On ettevõtteid, kes ei vaja sellist muutuste kiirust. Tean ettevõtteid, kus iga 15 minuti tagant muudatusi teha ei saa. Ja mitte sellepärast, et nad on nii halvad. See on selline elutsükkel. Ja filiaalide funktsiooni, lülitusfunktsiooni muutmiseks vajate sügavaid teadmisi.
See on keeruline. Kui soovite lülitusfunktsiooni lugu üksikasjalikumalt lugeda, soovitan seda väga . Ja seal on suurepärane artikkel Martin Fowlerilt lülitusfunktsioonide kohta: millised tüübid on olemas, elutsüklid jne. Lülitusfunktsioon on keeruline.
Ja te pole ikka veel vastanud küsimusele: "Kas Jenkinsit on vaja või mitte?"
Jenkinsit pole igal juhul tegelikult vaja. Tõsiselt, tööriistad: Jenkins, Gitlab pakuvad teile mugavust. Näete, et koost on kokku pandud või kokku panemata. Nad võivad teid aidata, kuid nad ei anna teile praktikat. Nad saavad teile anda ainult ringi – Ok, mitte Ok. Ja siis, kui kirjutada ka teste, sest kui teste pole, siis on see peaaegu mõttetu. Seetõttu on seda vaja, sest see on mugavam, kuid üldiselt saate ilma selleta elada, te ei kaota palju.
See tähendab, et kui teil on tavasid, kas see tähendab, et te ei vaja seda?
See on õige. Soovitan Jez Humble'i testi. Seal suhtun viimasesse punkti ambivalentselt. Aga üldiselt on nii, et kui sul on kolm asja, liidad pidevalt kokku, teed masteris committe teste, parandad masteris ehituse kiiresti ära, siis ehk polegi muud vaja.
Ootame osalejate küsimusi, on mul küsimus. Rääkisime just tootekoodist. Kas olete seda infrastruktuuri koodi jaoks kasutanud? Kas see on sama kood, kas sellel on samad põhimõtted ja sama elutsükkel või on erinevad elutsüklid ja põhimõtted? Tavaliselt, kui kõik räägivad pidevast integratsioonist ja arendamisest, unustavad kõik ära, et on olemas ka taristukood. Ja viimasel ajal on seda aina juurde tulnud. Ja kas kõik need reeglid tuleks sinna tuua?
Isegi mitte seda, et see peaks olema, see oleks suurepärane, sest see teeks elu samamoodi lihtsamaks. Niipea, kui töötame koodiga, mitte bash-skriptidega, vaid meil on tavaline kood.
Stop, stop, bash-skript on samuti kood. Ära puuduta mu vana armastust.
Olgu, ma ei tallata su mälestusi jalge alla. Mulle isiklikult ei meeldi bash. See katkeb kogu aeg kole ja hirmus. Ja see puruneb sageli ettearvamatult, mistõttu see mulle ei meeldi. Aga olgu, oletame, et teil on bash-kood. Võib-olla ma tõesti ei saa aru ja seal on tavalised testimisraamistikud. Ma lihtsalt ei ole kursis. Ja me saame samad eelised.
Niipea, kui töötame infrastruktuuri kui koodiga, tekivad kõik samad probleemid nagu arendajad. Paar kuud tagasi puutusin kokku olukorraga, kus kolleeg saatis mulle tõmbetaotluse 1 rea jaoks bashis. Ja veedate 000 tundi ülevaates. Samad probleemid tekivad. See on ikka kood. Ja see on ikkagi koostöö. Me takerdume tõmbamistaotlusega ja jääme jänni sellesse, et lahendame näiteks samu liitmiskonflikte samas bashis.
Vaatan nüüd väga aktiivselt kogu seda asja kõige ilusama infra programmeerimise pealt. Olen nüüd Pulumi taristusse toonud. See on programmeerimine selle puhtaimal kujul. Seal on see veelgi toredam, sest mul on kõik programmeerimiskeele võimalused, st tegin samade if-idega ilusa lüliti ja kõik on korras. See tähendab, et minu muutus on juba meistris. Kõik näevad teda juba praegu. Teised insenerid teavad sellest. See on seal juba midagi mõjutanud. Kuid see ei olnud kõigi infrastruktuuride jaoks lubatud. See lülitus sisse näiteks minu katsestendi jaoks. Seetõttu on teie küsimusele uuesti vastamiseks vajalik. See teeb meie kui koodiga töötavate inseneride elu samamoodi lihtsamaks.
Kui kellelgi on veel küsimusi?
Mul on küsimus. Tahan jätkata arutelu Olegiga. Üldiselt arvan, et sul on õigus, et kui mingi ülesande täitmine võtab kuu aega, siis sul on probleem arhitektuuriga, sul on probleem analüüsi, dekomponeerimise, planeerimisega jne. Aga mul on tunne, et kui sa alustad proovides elada Continuous Integration järgi, siis hakkad valu planeerimisega korrigeerima, sest mujal sa sellest ei pääse.
(Oleg) Jah, see on õige. See tava on pingutuselt võrreldav mis tahes muu tõsise kultuurimuutva praktikaga. Kõige raskem on üle saada harjumustest, eriti halbadest harjumustest. Ja kui selle praktika rakendamiseks on vaja tõsist muutust ümbritsevate inimeste harjumustes: arendajad, juhtkond, tootmisjuht, siis ootavad teid üllatused.
Milliseid üllatusi võiks tulla? Oletame, et otsustate, et lõimute sagedamini. Ja teil on integratsiooniga seotud muid asju, näiteks artefaktid. Ja näiteks teie ettevõttes on poliitika, et iga artefakt peab olema mingil moel artefakti hoiustamise süsteemis. Ja see võtab natuke aega. Isik peab märkima ruudu, et ta on väljalaskehaldurina seda artefakti testinud, et veenduda, et see on tootmises väljastamiseks valmis. Kui kulub 5-10-15 minutit, aga küljendamist teed kord nädalas, siis kord nädalas poole tunni kulutamine on väike maks.
Kui teete pidevat integreerimist 10 korda päevas, tuleb 10 korda korrutada 30 minutiga. Ja see ületab selle väljalaskehalduri tööaja. Ta lihtsalt väsib selle tegemisest. Mõne praktika puhul on püsikulud. See on kõik.
Ja peate selle reegli kas tühistama, et te enam sellist prügi ei teeks, st te ei määra käsitsi kraadi, mis vastab millelegi. Toetute täielikult mõnele automatiseeritud valmisolekutestide komplektile.
Ja kui teil on vaja kelleltki tõendeid, et ülemus sellele alla kirjutaks ja te ei satu tootmisse ilma, et Vasya ütleks, et ta lubab jne - kogu see jama jääb praktiku teele. Sest kui mingid tegevused on seotud maksuga, siis kõik kasvab 100 korda. Seetõttu ei võeta vahetust sageli kõik rõõmuga vastu. Sest inimeste harjumusi on raske muuta.
Kui inimene teeb oma tavapärast tööd, teeb ta seda peaaegu mõtlemata. Tema kognitiivne koormus on null. Ta lihtsalt mängib sellega ringi, tal on juba peas kontrollnimekiri, ta on seda tuhat korda teinud. Ja niipea, kui tulete talle ütlema: "Tühistame selle praktika ja alustame esmaspäevast uuega", muutub see tema jaoks võimsaks kognitiivseks koormuseks. Ja see tuleb kõigile korraga.
Seetõttu on kõige lihtsam, kuigi mitte igaüks ei saa seda luksust endale lubada, kuid see on see, mida ma alati teen, see on järgmine. Kui algab uus projekt, siis tavaliselt topitakse kõik testimata praktikad kohe sellesse projekti. Kuigi projekt on noor, ei riski me tegelikult millegagi. Prodi veel pole, pole midagi hävitada. Seetõttu saab seda kasutada treeninguna. See lähenemine toimib. Kuid kõigil ettevõtetel pole võimalust selliseid projekte sageli alustada. Kuigi see on ka veidi kummaline, sest nüüd toimub täielik digitaalne transformatsioon, peavad kõik katseid tegema, et konkurentidega sammu pidada.
Siin jõuate järeldusele, et kõigepealt peate mõistma, mida peate tegema. Maailm ei ole ideaalne ja prod pole ka ideaalne.
Jah, need asjad on omavahel seotud.
Ka ettevõtted ei saa alati aru, et nad peavad seda teed minema.
Tekib olukord, kus muutused pole üldse võimalikud. See on olukord, kus meeskonnal on suurem surve. Meeskond on juba üsna läbi põlenud. Tal pole eksperimentide jaoks vaba aega. Nad töötavad funktsioonide kallal hommikust õhtuni. Ja haldamisel on järjest vähem funktsioone. Üha rohkem nõutakse. Sellises olukorras ei ole muudatused üldse võimalikud. Meeskonnale võib vaid öelda, et homme teeme sama, mis eile, tuleb vaid veidi rohkem funktsioone teha. Selles mõttes ei ole üleminek ühelegi praktikale võimalik. See on klassikaline olukord, kui pole aega kirvest teritada, puid on vaja maha võtta, nii et nad lõikavad seda nüri kirvega. Siin pole lihtsaid näpunäiteid.
(Dmitry) Loen vestlusest ette selgituse: „Kuid me vajame erinevatel tasanditel palju testide katvust. Kui palju aega testidele eraldatakse? See on natuke kallis ja võtab palju aega."
(Oleg) See on klassikaline eksiarvamus. Teste peaks olema piisavalt, et oleksite enesekindel. Pidev integreerimine ei ole asi, kus enne tehakse 100% testid ja alles siis hakatakse seda praktikat rakendama. Pidev integratsioon vähendab teie kognitiivset koormust, kuna kõik muutused, mida oma silmaga näete, on nii ilmsed, et saate isegi ilma testideta aru, kas see rikub midagi või mitte. Saate seda kiiresti oma peas testida, sest muutused on väikesed. Isegi kui teil on ainult käsitsi testijad, on see ka nende jaoks lihtsam. Veeresid välja ja ütlesid: "Vaata, kas midagi on katki?" Nad kontrollisid ja ütlesid: "Ei, midagi pole katki." Sest testija teab, kust otsida. Teil on ühe koodijupiga seotud üks kohustus. Ja seda kasutatakse konkreetse käitumisega ära.
Siin sa muidugi kaunistatud.
(Dmitry) Ma ei ole sellega nõus. On olemas praktika - testipõhine arendus, mis päästab teid sellest.
(Oleg) Noh, ma pole veel selleni jõudnud. Esimene illusioon on see, et peate kirjutama 100% testidest või te ei pea üldse tegema pidevat integreerimist. See ei ole tõsi. Need on kaks paralleelset praktikat. Ja nad ei ole otseselt sõltuvad. Teie testi katvus peaks olema optimaalne. Optimaalne - see tähendab, et olete ise kindel, et kapteni kvaliteet, millesse teie peremees pärast kohustust jäi, võimaldab teil purjus reede õhtul enesekindlalt vajutada nuppu „Aseta”. Kuidas te seda saavutate? Läbivaatamise, katvuse, hea jälgimise kaudu.
Hea jälgimine on testidest eristamatu. Kui käivitate testid üks kord eeltoode, kontrollivad nad kõik teie kasutajaskriptid üks kord ja ongi kõik. Ja kui käivitate need lõputus tsüklis, siis see on teie juurutatud jälgimissüsteem, mis testib lõputult kõike – kas see jooksis kokku või mitte. Sel juhul on vahe vaid selles, kas seda tehakse üks või kaks korda. Väga hea komplekt teste... kestab lõputult, see on jälgimine. Ja õige jälgimine peaks olema selline.
Ja seetõttu, kuidas täpselt selle oleku saavutate, kui end reede õhtul valmis seada ja koju lähete, on teine küsimus. Võib-olla oled sa lihtsalt julge pätt.
Tuleme veidi tagasi pideva integratsiooni juurde. Põgenesime veidi teistsuguse keerulise praktika juurde.
Ja teine illusioon on see, et MVP tuleb nende sõnul kiiresti teha, nii et teste pole seal üldse vaja. Kindlasti mitte sel viisil. Fakt on see, et MVP-s kasutajalugu kirjutades saate seda kas palli peal arendada, see tähendab, et kuulsite, et seal on mingi kasutajalugu ja jooksite seda kohe kodeerima, või saate töötada TDD abil. Ja vastavalt TDD-le, nagu näitab praktika, ei võta see kauem aega, st testid on kõrvalmõju. TDD praktika ei seisne testimises. Hoolimata sellest, mida nimetatakse testipõhiseks arendamiseks, ei ole see üldse seotud testidega. See on ka pigem arhitektuurne lähenemine. See on lähenemine, kuidas kirjutada täpselt seda, mida vaja, ja mitte kirjutada seda, mida pole vaja. See on tava keskenduda oma mõtlemise järgmisele iteratsioonile rakenduse arhitektuuri loomisel.
Seetõttu pole neist illusioonidest nii lihtne vabaneda. MVP ja testid ei ole vastuolus. Isegi, pigem vastupidi, kui teete MVP-d TDD praktikaga, siis teete seda paremini ja kiiremini kui siis, kui teete seda üldse ilma harjutamata, vaid palli peal.
See on väga ebaselge ja keeruline idee. Kui kuuled, et nüüd hakkan rohkem teste kirjutama ja samas midagi kiiremini tegema, siis kõlab täiesti ebaadekvaatselt.
(Dmitry) Paljud inimesed siin, kui nad helistavad MVP-le, on liiga laisad, et midagi normaalset kirjutada. Ja need on ikka erinevad asjad. Pole vaja muuta MVP-d halvaks asjaks, mis ei tööta.
Jah, jah, sul on õigus.
Ja siis järsku MVP tootmises.
Igavesti.
Ja TDD kõlab väga ebatavaliselt, kui kuulete, et kirjutate teste ja näib, et teete rohkem tööd. Kõlab väga kummaliselt, aga tegelikult tuleb niimoodi kiiremini ja ilusam välja. Testi kirjutades mõtled juba oma peas palju sellele, mis koodi ja kuidas kutsutakse ning millist käitumist me sellelt ootame. Sa ei ütle lihtsalt, et kirjutasin mingi funktsiooni ja see teeb midagi. Alguses mõtlesid, et tal on sellised ja sellised tingimused, teda kutsutakse nii ja naa. Katte selle testidega ja sellest saate aru, kuidas teie liidesed teie koodi sees välja näevad. Sellel on suur mõju arhitektuurile. Teie kood muutub automaatselt modulaarsemaks, kuna proovite kõigepealt aru saada, kuidas seda testida, ja alles siis kirjutate selle.
Minuga juhtus TDD-ga see, et mingil hetkel palkasin Ruby mentori, kui olin veel Ruby programmeerija. Ja ta ütleb: "Teeme seda vastavalt TDD-le." Mõtlesin: "Kurat, ma pean nüüd midagi lisa kirjutama." Ja leppisime kokku, et kahe nädala jooksul kirjutan kogu töötava koodi Pythonis, kasutades TDD-d. Kahe nädala pärast sain aru, et ma ei taha tagasi minna. Pärast seda, kui olete kaks nädalat püüdnud seda kõikjal rakendada, mõistate, kui palju lihtsamaks on teil isegi lihtsalt mõelda. Kuid see pole ilmselge, seega soovitan kõigil, et kui teil on tunne, et TDD on raske, aeganõudev ja mittevajalik, proovige seda pidada vaid kaks nädalat. Minu jaoks piisas kahest.
(Dmitry) Saame seda ideed infrastruktuuri toimimise seisukohast laiendada. Enne millegi uue käivitamist teostame järelevalvet ja seejärel käivitame. Sel juhul muutub jälgimine meie jaoks tavapäraseks testimiseks. Ja jälgimise kaudu toimub areng. Kuid peaaegu kõik ütlevad, et see on pikk, ma olen laisk, tegin ajutise mustandi. Kui oleme teinud tavapärast jälgimist, mõistame CI-süsteemi olekut. Ja CI-süsteemil on palju jälgimist. Me mõistame süsteemi olekut, mõistame, mis selle sees on. Ja arenduse käigus muudame lihtsalt süsteemi selliseks, et see jõuaks soovitud olekusse.
Need tavad on tuntud juba pikka aega. Arutasime seda umbes 4 aastat tagasi. Kuid 4 aastaga pole praktiliselt midagi muutunud.
Kuid sellega seoses teen ettepaneku ametlik arutelu lõpetada.
Video (sisestatud meediaelemendina, kuid mingil põhjusel ei tööta):
Allikas: www.habr.com