Ja sa ikkagi ei vastanud k\u00fcsimusele: \"Kas Jenkins on vajalik v\u00f5i mitte?\"<\/em><\/p>\n<\/p>\n
Jenkins ei ole tegelikult \u00fchelgi juhul vajalik. Kui t\u00f5siselt r\u00e4\u00e4kida, siis t\u00f6\u00f6riistad: Jenkins, Gitlab toovad teile mugavust. Te n\u00e4ete, kas kogumine \u00f5nnestus v\u00f5i mitte. Need v\u00f5ivad teid aidata, kuid nad ei tule teiega praktikat. Nad v\u00f5ivad anda teile lihtsalt ringi \u2013 Ok, ei Ok. Ja seda juhul, kui te kirjutate veel teste, sest kui teste ei ole, siis on see peaaegu m\u00f5ttetu. Seet\u00f5ttu on see vajalik, kuna see on mugavam, kuid \u00fcldiselt on v\u00f5imalik ka ilma selleta elada, kaotate mitte palju. <\/p>\n
<\/p>\n
St. kui teil on praktika, siis ei ole see teile vajalik?<\/em><\/p>\n<\/p>\n
T\u00e4pselt. Soovitan Jez Humble'i testi. Seal mul on viimase punkti suhtes kahetised tunded. Kuid \u00fcldiselt, kui teil on kolm asja, te liidate pidevalt, k\u00e4itate teste commitide peal masteris, kiiresti parandate buildi masteris, siis v\u00f5ib-olla ei ole teil rohkem midagi vaja. <\/p>\n
<\/p>\n
Kuna me ootame osalejatelt k\u00fcsimusi, on mul k\u00fcsimus. Me r\u00e4\u00e4kisime praegu toote koodist. Kas oled kasutanud seda infrastruktuuri koodi jaoks. Kas see on sama kood, sellel on samad printsiibid ja sama eluts\u00fckkel, v\u00f5i on seal teised eluts\u00fcklid ja printsiibid? Tavaliselt, kui k\u00f5ik r\u00e4\u00e4givad pidevast integreerimisest ja arendamisest, unustatakse, et on ka infrastruktuuri kood. Ja viimasel ajal on seda \u00fcha rohkem ja rohkem. Kas peaksime seal rakendama neid reegleid?<\/em><\/p>\n<\/p>\n
Isegi mitte, et peaks, vaid see oleks suurep\u00e4rane, kuna see lihtsustab elu. Kuni me t\u00f6\u00f6tame koodiga, mitte bash-skriptidega, ja meil on korralik kood.<\/p>\n
<\/p>\n
Peatus-peatuse, bash-skript \u2013 see on samuti kood. \u00c4ra puutu minu vana armastust.<\/em> <\/p>\n<\/p>\n
Hea, ma ei hakka sinu m\u00e4lestusi tallama. Mul on bashi vastu isiklik vastumeelsus. See laguneb rumalalt ja hirmu\u00e4ratavalt kogu aeg. Ja see laguneb sageli ettearvamatult, seega ei meeldi see mulle. Aga oletame, et sul on bashis kood. V\u00f5ib-olla ma t\u00f5esti ei tea ja seal on normaalsed testimisraamistike. Ma lihtsalt ei ole kursis. Ja me saame samu plusse.<\/p>\n
<\/p>\n
Niipea kui me t\u00f6\u00f6tame infrastruktuuriga nagu koodiga, saame k\u00f5ik samad probleemid nagu arendajad. M\u00f5ni kuu tagasi sattusin olukorda, kus kolleeg saatis mulle 1 000 rida bashi pull requesti. Ja sa j\u00e4\u00e4d 4 tunniks seda \u00fcle vaatama. Probleemid on samad. See on ikka veel kood. Ja ikka veel koost\u00f6\u00f6. Me j\u00e4\u00e4me kinni pull requesti ja j\u00e4\u00e4me kinni bashi sama merge-konfliktide lahendamisse. <\/p>\n
<\/p>\n
Ma vaatan praegu v\u00e4ga aktiivselt kogu seda asja maksimaalselt ilusa infrastruktuuri programmeerimise suunas. Olen praegu infrastruktuuri t\u00f5mmanud Pulumi. See on puhtalt programmeerimine. Seal on see veelgi ilusam, sest mul on k\u00f5ik programmeerimiskeele v\u00f5imalused, st ma tegin sama IF-idega ilusaid toggle-sid ja k\u00f5ik on h\u00e4sti. Nimelt, mu muudatus on juba masteris. Seda n\u00e4evad juba k\u00f5ik. Teised insenerid on sellest kursis. See on juba millegile m\u00f5jutanud. Kuid samas ei aktiveeritud see k\u00f5igile infrastruktuuridele. See aktiveeriti n\u00e4iteks minu testkeskkondade jaoks. Seet\u00f5ttu, vastates sinu k\u00fcsimusele veel kord, see on vajalik. See muudab meie elu inseneridena, kes t\u00f6\u00f6tavad koodiga, kindlasti lihtsamaks. <\/p>\n
<\/p>\n
Kas kellelgi on veel k\u00fcsimusi?<\/em> <\/p>\n<\/p>\n
Mul on k\u00fcsimus. Soovin j\u00e4tkata arutelu Olegiga. \u00dcldiselt arvan, et sa oled \u00f5ige, et kui \u00fclesanne v\u00f5tab sul kuu aega, siis sul on arhitektuuri probleem, sul on anal\u00fc\u00fcsi, dekompositsiooni, planeerimise jne probleem. Aga mul on selline tunne, et kui sa hakkad proovima elada Continuous Integration j\u00e4rgi, siis hakkad sa planeerimisega seotud probleeme parandama, sest sa ei p\u00e4\u00e4se sellest enam kuskile. <\/p>\n
<\/p>\n
(Oleg) Jah, k\u00f5ik on nii. Selle praktika t\u00f6\u00f6maht on v\u00f5rreldav mis tahes muu t\u00f5sise praktikaga, mis muudab kultuuri. K\u00f5ige raskem takistuste \u00fcletamine on harjumused, eriti halvad harjumused. Ja kui selle praktika rakendamiseks on vaja t\u00f5sist harjumuste muutmist \u00fcmbritsevate inimeste seas: arendajad, juhtkond, tootmisjuht, siis ootavad teid \u00fcllatused.<\/em> <\/p>\n<\/p>\n
Millised v\u00f5ivad olla \u00fcllatused? Oletame, et otsustasite, et hakkate sagedamini integreerima. Ja teie integreerimisele on seotud veel mingid asjad, n\u00e4iteks artefaktid. Teie ettev\u00f5ttes on n\u00e4iteks poliitika, et iga artefakt peab olema mingil moel arvesse v\u00f5etud mingis artefaktide ladustamise s\u00fcsteemis. Ja see v\u00f5tab aega. Inimene peab m\u00e4rkima, et ta, kui v\u00e4ljaandete haldur, on selle artefakti testinud valmisoleku osas tootmisse viimiseks. Kui see v\u00f5tab 5-10-15 minutit, aga samal ajal teete v\u00e4ljaandeid kord n\u00e4dalas, siis n\u00e4dalas pooltunnine ajakulu ei ole suur maksu.<\/em> <\/p>\n<\/p>\n
Kui teete pidevat integreerimist 10 korda p\u00e4evas, siis tuleb 10 korda korrutada 30 minutiga. Ja see \u00fcletab selle v\u00e4ljaandete halduri t\u00f6\u00f6aega. Ta lihtsalt v\u00e4sib selle tegemisest. Mingid praktikaid on pidevad kulud. Ja k\u00f5ik.<\/em> <\/p>\n<\/p>\n
Ja teil on vaja kas t\u00fchistada see reegel, et te ei tegele selliste asjadega, st et te ei m\u00e4\u00e4rata k\u00e4sitsi vastavust millegi suhtes. Te toetute t\u00e4ielikult mingitele automatiseeritud valmisoleku testide komplektidele.<\/em> <\/p>\n<\/p>\n
Ja kui teil on kellegilt t\u00f5end, et juht allkirjastab, ja te ei liiguta tootmisse, kui Vassja ei \u00fctle, et ta lubab jne \u2013 k\u00f5ik see jama takistab praktikaid. Sest kui mingid tegevused on maksuna seotud, siis k\u00f5ik k\u00fcmneid kordi suureneb. Seega ei ole toimetuse muudatus k\u00f5igile alati r\u00f5\u00f5m. Sest inimeste harjumusi on raske muuta.<\/em> <\/p>\n<\/p>\n
Kui inimene teeb harjumusp\u00e4rast t\u00f6\u00f6d, teeb ta seda praktiliselt mitte m\u00f5eldes. 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 \u00fctled talle: \u201e\u00c4rme tee seda praktikat ja alates esmasp\u00e4evast rakendame uut,\u201d siis muutub see tema jaoks suureks kognitiivseks koormuseks. Ja see koormus hakkab k\u00f5igile koheselt pihta.<\/em> <\/p>\n<\/p>\n
Seega on k\u00f5ige lihtsam, kuigi see luksus ei ole k\u00f5igile kergesti k\u00e4ttesaadav, kuid mina teen alati just nii. Kui k\u00e4ivitatakse uus projekt, siis torkavad k\u00f5ik 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\u00f5ttu saab seda kasutada treeninguna. Selline l\u00e4henemine t\u00f6\u00f6tab. Kuid mitte k\u00f5ik ettev\u00f5tted ei saa selliseid projekte sageli alustada. Kuigi see on ka veidi kummaline, kuna praegu toimub pidev digitaalne transformatsioon, peavad k\u00f5ik katsetusi k\u00e4ivitama, et konkurentidega sammu pidada.<\/em> <\/p>\n<\/p>\n
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. <\/p>\n
<\/p>\n
Jah, need asjad on omavahel seotud.<\/em><\/p>\n<\/p>\n
\u00c4ril pole ka alati arusaama, et nad peavad minema just sinna, kuhu peab. <\/p>\n
<\/p>\n
On olukord, kus ei ole mingid muudatused \u00fcldse v\u00f5imalikud. See on olukord, kus meeskonnale avaldatakse suuremat survet. Meeskond on juba \u00fcsna l\u00e4bip\u00f5lenud. Neil ei ole enam mingit reservaega katsetuste jaoks. Nad t\u00f6\u00f6tavad hommikust \u00f5htuni funktsioonide kallal. Ja juhtkonnale on funktsioonidest alati v\u00e4he. N\u00f5utakse \u00fcha rohkem ja rohkem. Sellises olukorras ei ole \u00fcldse mingid muudatused v\u00f5imalikud. Meeskonnale saab vaid \u00f6elda, et homme teeme t\u00e4pselt nii nagu eile, lihtsalt tuleb teha funktsioone natuke rohkem. Mingid \u00fcleminekud mingitesse praktikatesse selles m\u00f5ttes ei ole v\u00f5imalikud. See on klassikaline olukord, kus pole aega kirvest teritada, peab puid langetama, seega langetatakse tuima kirvega. Siin lihtsaid n\u00f5uandeid ei ole.<\/em> <\/p>\n<\/p>\n
(Dmitri) Loen v\u00e4lja t\u00e4psustuse vestlusest: \u201eAga vajavad suurt testimise katet erinevatel tasanditel. Kui palju aega p\u00fchendatakse testimisele? See on kuidagi kallis, v\u00f5tab palju aega.\u201d<\/em><\/p>\n<\/p>\n
(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\u2019s 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.<\/em><\/p>\n<\/p>\n
Here you certainly embellished. <\/p>\n
<\/p>\n
(Dmitry) I disagree here. There is a practice \u2014 test-driven development, which will help with this.<\/em> <\/p>\n<\/p>\n
(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.<\/em> <\/p>\n<\/p>\n
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\u2014whether 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.<\/em> <\/p>\n<\/p>\n
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.<\/em> <\/p>\n<\/p>\n
Naasime tagasi veidi Continuous Integration'i juurde. Oleme p\u00f5genenud veidi teise keerulisse praktikasse. <\/p>\n
<\/p>\n
Ja teine illusioon on see, et MVP-d tuleb kiiresti teha, seega katsetele pole seal \u00fcldse kohta. Asi ei ole nii. Nimelt, kui kirjutate MVP-s user story, siis selle arendamine v\u00f5ib toimuda kas lihtsalt kuulmise p\u00f5hjal \u2014 kuulete, et on mingi user story ja jooksete seda kohe kodeerima \u2014 v\u00f5i TDD p\u00f5hjal. Ja TDD puhul, nagu praktika n\u00e4itab, ei kesta see kauem; testid on pigem k\u00f5rvaltoime. TDD praktika ei seisne testimises. Hoolimata sellest, et see on nimega Test Driven Development, ei ole seal tegemist t\u00f5eliselt testidega. See on pigem arhitektuuri l\u00e4henemine. See on l\u00e4henemine, kuidas kirjutada just seda, mida on vaja, ja mitte kirjutada seda, mida ei ole vaja. See praktika keskendab teie edasise m\u00f5tlemise iteratsioonile rakenduse arhitektuuri loomise osas.<\/em> <\/p>\n<\/p>\n
Seep\u00e4rast 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.<\/em><\/p>\n<\/p>\n
See on v\u00e4ga ebaselge ja keeruline m\u00f5te. Kui kuulete, et n\u00fc\u00fcd hakkan ma kirjutama veel teste ja samal ajal teen midagi kiiremini, siis see k\u00f5lab t\u00e4iesti ebaadekvaatselt. <\/p>\n
<\/p>\n
(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.<\/em> <\/p>\n<\/p>\n
Jah-jah, sa oled \u00f5igus.<\/p>\n
<\/p>\n
Ja siis \u00fchel hetkel on MVP tootmises.<\/em><\/p>\n<\/p>\n
Igaveseks. <\/p>\n
<\/p>\n
Ja TDD k\u00f5lab v\u00e4ga harjumatult, kui kuuled, et kirjutad teste ja justkui teed rohkem t\u00f6\u00f6d. See k\u00f5lab v\u00e4ga kummaliselt, kuid t\u00f5esti, see teeb asja kiiremini ja atraktiivsemalt. Kui kirjutate testi, m\u00f5tletem sellega juba palju, milline kood on ja kuidas see kutset saab, ning millist k\u00e4itumist me sellelt ootame. Te ei \u00fctle lihtsalt, et ma olen kirjutanud mingi funktsiooni ja see teeb midagi. Te m\u00f5tlete k\u00f5igepealt sellele, et tal on sellised tingimused, ja see kutsub teatud viisil esile. Te katate selle testidega ja sellega m\u00f5istate, millised on teie koodi sisemised liidesed. See m\u00f5jutab arhitektuuri v\u00e4ga palju. Teie kood muutub automaatselt modulaarsemaks, sest te \u00fcritate esmalt aru saada, kuidas te seda katsetate, ja alles seej\u00e4rel kirjutate selle. <\/p>\n
<\/p>\n
Mul on TDD l\u00e4henemisega nii, et mingil hetkel palkasin Ruby mentori, kui olin veel Ruby programmeerija. Ta \u00fctles: \u201eTeeme nii, et teed TDD j\u00e4rgi.\u201d Ja ma m\u00f5tlesin: \u201eKurrat, n\u00fc\u00fcd tuleb j\u00e4llegi midagi juurde kirjutada.\u201d Lepisime kokku, et j\u00e4rgmise kahe n\u00e4dala jooksul kirjutan kogu t\u00f6\u00f6tava koodi Pythonis TDD j\u00e4rgi. Kahe n\u00e4dala p\u00e4rast sain aru, et ma ei taha enam tagasi minna. P\u00fc\u00fcdes neid kahte n\u00e4dalat igal pool rakendada, m\u00f5istsin, kui palju lihtsam on isegi lihtsalt m\u00f5elda. Aga see ei ole ilmselge, seega soovitan k\u00f5igil, et kui teil on tunne, et TDD \u2013 see on keeruline, pikk ja liig, proovige seda j\u00e4rgida v\u00e4hemalt kaks n\u00e4dalat. Mul piisab kahest, et seda m\u00f5ista.<\/p>\n
<\/p>\n
(Dmitri) Saame seda m\u00f5tet arendada infrastruktuuri ekspluateerimise vaatenurgast. Enne kui me midagi uut deployime, teeme j\u00e4lgimise ning seej\u00e4rel k\u00e4ivitame. Sel juhul muutub meie j\u00e4lgimine tavaliseks testimiseks. Ja on olemas arendamine l\u00e4bi j\u00e4lgimise. Kuid enamik \u00fctleb, et see on pikk, mul on laisk, ma tegin ajutise mustandi. Kui me saydime korraliku j\u00e4lgimise, saame aru CI s\u00fcsteemi olekust. Ja CI s\u00fcsteemis on palju j\u00e4lgimist. Me m\u00f5istame s\u00fcsteemi seisundit, me teame, mis tal sees on. Ja arenduse k\u00e4igus loome s\u00fcsteemi, et see j\u00f5uaks soovitud olekusse.<\/em> <\/p>\n<\/p>\n
Need praktikad on olnud tuntud juba ammu. Me arutasime seda umbes 4 aastat tagasi. Kuid viimase 4 aastaga pole praktiliselt midagi muutunud.<\/em> <\/p>\n<\/p>\n
Kuid selle m\u00e4rkmega pakun ametliku arutelu l\u00f5petamiseks.<\/em><\/p>\n<\/p>\n
video (sisestatud meediaelemendina, kuid mingil p\u00f5hjusel ei t\u00f6\u00f6ta):<\/p>\n
\nhttps:\/\/youtu.be\/zZ3qXVN3Oic<\/a><\/noindex> habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u041e\u0431\u0441\u0443\u0434\u0438\u043c \u043f\u043e\u0447\u0435\u043c\u0443 CI-\u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442\u044b \u0438 CI \u2013 \u044d\u0442\u043e \u0441\u043e\u0432\u0441\u0435\u043c \u043f\u0440\u043e \u0440\u0430\u0437\u043d\u043e\u0435. \u041a\u0430\u043a\u0443\u044e \u0431\u043e\u043b\u044c CI \u043f\u0440\u0438\u0437\u0432\u0430\u043d\u043e \u0440\u0435\u0448\u0438\u0442\u044c, \u043e\u0442\u043a\u0443\u0434\u0430 \u0432\u043e\u0437\u043d\u0438\u043a\u043b\u0430 \u0438\u0434\u0435\u044f, \u043a\u0430\u043a\u0438\u0435 \u043f\u043e\u0441\u043b\u0435\u0434\u043d\u0438\u0435 \u043f\u043e\u0434\u0442\u0432\u0435\u0440\u0436\u0434\u0435\u043d\u0438\u044f \u0447\u0442\u043e \u043e\u043d\u043e \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442, \u043a\u0430\u043a \u043f\u043e\u043d\u044f\u0442\u044c \u0447\u0442\u043e \u0443 \u0432\u0430\u0441 \u0435\u0441\u0442\u044c \u0438\u043c\u0435\u043d\u043d\u043e \u043f\u0440\u0430\u043a\u0442\u0438\u043a\u0430, \u0430 \u043d\u0435 \u043f\u0440\u043e\u0441\u0442\u043e \u0443\u0441\u0442\u0430\u043d\u043e\u0432\u043b\u0435\u043d\u043d\u044b\u0439 Jenkins. \u041c\u044b\u0441\u043b\u044c \u0441\u0434\u0435\u043b\u0430\u0442\u044c \u0434\u043e\u043a\u043b\u0430\u0434 \u043f\u0440\u043e Continuous Integration \u043f\u043e\u044f\u0432\u0438\u043b\u0430\u0441\u044c \u0435\u0449\u0435 \u0433\u043e\u0434 \u043d\u0430\u0437\u0430\u0434, \u043a\u043e\u0433\u0434\u0430 \u044f \u0445\u043e\u0434\u0438\u043b \u043f\u043e \u0441\u043e\u0431\u0435\u0441\u0435\u0434\u043e\u0432\u0430\u043d\u0438\u044f\u043c \u0438\u0441\u043a\u0430\u043b \u0440\u0430\u0431\u043e\u0442\u0443. \u041f\u043e\u043e\u0431\u0449\u0430\u043b\u0441\u044f […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":93886,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-93885","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"Continuous](\"\/wp-content\/uploads\/2020\/09\/ed8a32ae63b8dccfc8b4893ab27f1527.jpg\")
<\/p>\n