De m\u00e9g mindig nem v\u00e1laszolt\u00e1l a k\u00e9rd\u00e9sre: \"A Jenkins sz\u00fcks\u00e9ges vagy nem sz\u00fcks\u00e9ges?\"<\/em><\/p>\n<\/p>\n
A Jenkins val\u00f3j\u00e1ban semmilyen esetben nem sz\u00fcks\u00e9ges. Ha komolyan vessz\u00fck, az eszk\u00f6z\u00f6k: Jenkins, Gitlab k\u00e9nyelmet fognak ny\u00fajtani. L\u00e1tni fogod, hogy a build elk\u00e9sz\u00fclt-e vagy sem. Seg\u00edthetnek neked, de a praktik\u00e1t nem adj\u00e1k. Csak egy kis k\u00f6r lesz: Ok, nem Ok. \u00c9s az is, ha \u00edrsz teszteket, mert ha nincsenek tesztek, az majdnem \u00e9rtelmetlen. Teh\u00e1t sz\u00fcks\u00e9ges, mert k\u00e9nyelmesebb, de \u00f6sszess\u00e9g\u00e9ben \u00e9lhetsz n\u00e9lk\u00fcle is, nem sokat vesz\u00edtesz. <\/p>\n
<\/p>\n
Teh\u00e1t, ha vannak praktik\u00e1id, akkor ez azt jelenti, hogy nincs sz\u00fcks\u00e9ged r\u00e1?<\/em><\/p>\n<\/p>\n
Teljesen igaz. Aj\u00e1nlom a Jez Humble-f\u00e9le tesztet. Ott van nekem egy vegyes \u00e9rz\u00e9sem az utols\u00f3 ponttal kapcsolatban. De alapvet\u0151en, ha h\u00e1rom dolog van: folyamatosan merge-elsz, teszteket futtatsz a master commitjaidon, gyorsan jav\u00edtod a buildet a masterben, akkor lehet, hogy nem is sz\u00fcks\u00e9ges m\u00e1s. <\/p>\n
<\/p>\n
M\u00edg v\u00e1runk a r\u00e9sztvev\u0151k k\u00e9rd\u00e9seire, van egy k\u00e9rd\u00e9sem. Most a term\u00e9k k\u00f3dj\u00e1r\u00f3l besz\u00e9lt\u00fcnk. Haszn\u00e1ltad-e infrastrukt\u00fara k\u00f3dra is? Ez ugyanaz a k\u00f3d, ugyanazok az elvek \u00e9s ugyanaz az \u00e9letciklus, vagy ott m\u00e1s \u00e9letciklusok \u00e9s elvek vannak? \u00c1ltal\u00e1ban, amikor mindenki a Continuous Integration \u00e9s Development-r\u0151l besz\u00e9l, elfelejtik, hogy van infrastrukt\u00fara k\u00f3d is. Az ut\u00f3bbi id\u0151ben egyre t\u00f6bb van bel\u0151le. \u00c9s sz\u00fcks\u00e9ges-e az \u00f6sszes ezek a szab\u00e1lyokat oda behozni?<\/em><\/p>\n<\/p>\n
Nem arr\u00f3l van sz\u00f3, hogy sz\u00fcks\u00e9ges, hanem hogy nagyszer\u0171 lenne, mert pontosan \u00edgy megk\u00f6nny\u00edten\u00e9 az \u00e9letet. Ahogy elkezd\u00fcnk k\u00f3ddal dolgozni, nem bash szkriptekkel, hanem norm\u00e1lis k\u00f3ddal.<\/p>\n
<\/p>\n
\u00c1llj, \u00e1llj, a bash szkript is k\u00f3d. Ne bolygassd a r\u00e9gi szerelmemet.<\/em> <\/p>\n<\/p>\n
Rendben, nem fogom taposni az eml\u00e9keidet. Szem\u00e9lyesen ellenszenvvel vagyok a bash ir\u00e1nt. Cs\u00fany\u00e1n \u00e9s f\u00e9lelmetesen t\u00f6rik \u00f6ssze \u00e1lland\u00f3an. R\u00e1ad\u00e1sul gyakran impr\u00e9dik\u00e1lisan, ez\u00e9rt nem kedvelem. De rendben, tegy\u00fck fel, van egy k\u00f3dod bashben. Lehet, hogy t\u00e9nyleg nem \u00e9rtek hozz\u00e1, \u00e9s vannak norm\u00e1lis tesztel\u0151 keretrendszerek is benne. Egyszer\u0171en nem vagyok benne. \u00c9s ugyanazokat az el\u0151ny\u00f6ket kapjuk.<\/p>\n
<\/p>\n
Amint infrastruktur\u00e1t dolgozunk k\u00f3d form\u00e1j\u00e1ban, ugyanazokkal a probl\u00e9m\u00e1kkal tal\u00e1lkozunk, mint a fejleszt\u0151k. N\u00e9h\u00e1ny h\u00f3nappal ezel\u0151tt szembes\u00fcltem azzal, hogy egy koll\u00e9g\u00e1m 1000 soros pull requestet k\u00fcld\u00f6tt bashben. \u00c9s te n\u00e9gy \u00f3r\u00e1n \u00e1t elfoglalt vagy a fel\u00fclvizsg\u00e1lattal. Ugyanazok a probl\u00e9m\u00e1k mer\u00fclnek fel. Ez m\u00e9g mindig k\u00f3d. \u00c9s m\u00e9g mindig k\u00f6z\u00f6s munka. Benne ragadunk a pull requestekn\u00e9l \u00e9s a bash mergen \u00fctk\u00f6z\u00e9sek megold\u00e1s\u00e1n\u00e1l, p\u00e9ld\u00e1ul. <\/p>\n
<\/p>\n
Mostan\u00e1ban nagyon akt\u00edvan figyelem ezt a dolgot a lehet\u0151 legszebb infrastruktur\u00e1lis programoz\u00e1sban. Jelenleg Pulumi-t hoztam be az infrastrukt\u00far\u00e1ba. Ez tiszta programoz\u00e1s. Itt m\u00e9g szebb, mert szinte ugyanazokat a programoz\u00e1si nyelv lehet\u0151s\u00e9geit haszn\u00e1lom, pl. ugyanazzal az if-el gy\u00f6ny\u00f6r\u0171 toggle-okat k\u00e9sz\u00edtettem, \u00e9s minden rendben van. Azaz a v\u00e1ltoz\u00e1som m\u00e1r a masterbe ker\u00fclt. Mindenki l\u00e1tja. M\u00e1s m\u00e9rn\u00f6k\u00f6k tudom\u00e1sul vett\u00e9k. M\u00e1r hat\u00e1ssal volt valamire. De ez nem minden infrastrukt\u00far\u00e1hoz kapcsol\u00f3dik. P\u00e9ld\u00e1ul az \u00e9n tesztk\u00f6rnyezeteimhez aktiv\u00e1l\u00f3dott. Ez\u00e9rt v\u00e1laszolva a k\u00e9rd\u00e9sedre, sz\u00fcks\u00e9ges. Ez nek\u00fcnk, mint k\u00f3dot haszn\u00e1l\u00f3 m\u00e9rn\u00f6k\u00f6knek, ugyan\u00fagy megk\u00f6nny\u00edti az \u00e9let\u00fcnket. <\/p>\n
<\/p>\n
Van m\u00e9g valakinek k\u00e9rd\u00e9se?<\/em> <\/p>\n<\/p>\n
Van egy k\u00e9rd\u00e9sem. Szeretn\u00e9m folytatni a vit\u00e1t Oleggel. \u00c1ltal\u00e1ban azt gondolom, hogy igazad van, ha egy feladat egy h\u00f3nap alatt k\u00e9sz\u00fcl el, akkor probl\u00e9m\u00e1d van az architekt\u00far\u00e1val, r\u00e9szletes elemz\u00e9ssel, dekompoz\u00edci\u00f3val, tervez\u00e9ssel stb. De van egy olyan \u00e9rz\u00e9sem, hogy ha megpr\u00f3b\u00e1lsz a Folyamatos Integr\u00e1ci\u00f3 szerint \u00e9lni, akkor elkezdesz jav\u00edtani a tervez\u00e9si f\u00e1jdalmakkal, mert m\u00e1sfel\u00e9 nem tudsz menek\u00fclni. <\/p>\n
<\/p>\n
(Oleg) Igen, \u00edgy van. A munkaig\u00e9ny szempontj\u00e1b\u00f3l ez a gyakorlat \u00f6sszehasonl\u00edthat\u00f3 b\u00e1rmely m\u00e1s komoly gyakorlattal, amely megv\u00e1ltoztatja a kult\u00far\u00e1t. A legnehezebb az akad\u00e1lyok lek\u00fczd\u00e9se: k\u00fcl\u00f6n\u00f6sen a rossz szok\u00e1sok. Ha a gyakorlat bevezet\u00e9s\u00e9hez komoly habitusv\u00e1ltoz\u00e1sokra van sz\u00fcks\u00e9g a k\u00f6r\u00fcl\u00f6tted l\u00e9v\u0151kt\u0151l: fejleszt\u0151kt\u0151l, vezet\u0151s\u00e9gt\u0151l, termel\u00e9si menedzserekt\u0151l, meglepet\u00e9sek v\u00e1rnak r\u00e1d.<\/em> <\/p>\n<\/p>\n
Milyen meglepet\u00e9sek ad\u00f3dhatnak? Tegy\u00fck fel, hogy \u00fagy d\u00f6nt\u00f6tt\u00e9l, gyakrabban fogsz integr\u00e1lni. \u00c9s az integr\u00e1ci\u00f3hoz kapcsol\u00f3dik m\u00e9g n\u00e9h\u00e1ny dolog, p\u00e9ld\u00e1ul artefaktumok. A c\u00e9gedben p\u00e9ld\u00e1ul van egy politika, hogy minden artefaktumot valami m\u00f3don nyilv\u00e1n kell tartani egy artefaktumrakt\u00e1roz\u00e1si rendszerben. Ennek pedig van egy id\u0151ig\u00e9nye. Az embernek r\u00e1 kell b\u00f3lintania, hogy \u0151, mint kiad\u00e1ssal foglalkoz\u00f3 menedzser, tesztelte azt az artefaktumot, hogy alkalmas legyen a production rendszerbe val\u00f3 kihelyez\u00e9shez. Ha ez 5-10-15 percet vesz ig\u00e9nybe, de hetente egyszer kihelyezel, akkor hetente f\u00e9l \u00f3r\u00e1t r\u00e1sz\u00e1nni \u2013 ez nem sz\u00e1m\u00edt nagy terhel\u00e9snek.<\/em> <\/p>\n<\/p>\n
Ha naponta 10 alkalommal v\u00e9gzel folyamatos integr\u00e1ci\u00f3t, akkor ezt a 10-et meg kell szorozni 30 perccel. \u00c9s ez meghaladja ennek a kiad\u00e1si menedzsernek a munkaid\u0151keret\u00e9t. Egyszer\u0171en elf\u00e1rad ebben. Vannak \u00e1lland\u00f3 k\u00f6lts\u00e9gek egyes gyakorlatokra. \u00c9s ennyi.<\/em> <\/p>\n<\/p>\n
Vagy t\u00f6r\u00f6ln\u00f6d kell ezt a szab\u00e1lyt, hogy ne foglalkozz ilyen h\u00fclyes\u00e9gekkel, azaz nem rendelkezel k\u00e9zzel valamif\u00e9le megfelel\u0151s\u00e9gr\u0151l. Teljes m\u00e9rt\u00e9kben egy automatiz\u00e1lt k\u00e9szs\u00e9gtesztre b\u00edzod magad.<\/em> <\/p>\n<\/p>\n
Ha sz\u00fcks\u00e9ged van valakit\u0151l egy igazol\u00e1sra, hogy a f\u0151n\u00f6k al\u00e1\u00edrja, \u00e9s nem mersz a production rendszerbe menni an\u00e9lk\u00fcl, hogy Vasja azt mondta volna, hogy enged\u00e9lyezi, stb. \u2013 mindenf\u00e9le z\u0171r megakad\u00e1lyozza a gyakorlatokat. Mert ha vannak kapcsol\u00f3d\u00f3 aktivit\u00e1sok, mint valamilyen ad\u00f3, akkor minden 100-szor nagyobb\u00e1 v\u00e1lik. Ez\u00e9rt a v\u00e1ltoz\u00e1s nem mindenkinek \u00f6r\u00f6mteli. Mert az emberek szok\u00e1sait neh\u00e9z megv\u00e1ltoztatni.<\/em> <\/p>\n<\/p>\n
Amikor az ember megszokott munk\u00e1t v\u00e9gez, azt gyakorlatilag nem gondolkodva teszi. A kognit\u00edv terhel\u00e9se nulla. Csak elv\u00e9gzi a feladatokat, m\u00e1r van a fej\u00e9ben egy ellen\u0151rz\u0151 lista, ezerszer csin\u00e1lta m\u00e1r. \u00c9s amint j\u00f6ssz \u00e9s mondod neki: \u201eT\u00f6r\u00f6lj\u00fck ezt a gyakorlatot, \u00e9s h\u00e9tf\u0151t\u0151l vezess\u00fcnk be egy \u00fajat\u201d, ez hatalmas kognit\u00edv terhel\u00e9st okoz sz\u00e1m\u00e1ra. R\u00e1ad\u00e1sul ez mindenkire egyszerre hat.<\/em> <\/p>\n<\/p>\n
Ez\u00e9rt a legegyszer\u0171bb, igaz, ezt a luxust nem mindenki engedheti meg mag\u00e1nak, de \u00e9n mindig \u00edgy cselekszem. Amikor elindul egy \u00faj projekt, akkor \u00e1ltal\u00e1ban az \u00f6sszes kipr\u00f3b\u00e1latlan gyakorlat azonnal ebbe a projektbe ker\u00fcl. Am\u00edg a projekt fiatal, nem kock\u00e1ztatunk t\u00fal sokat. A prod m\u00e9g nincs k\u00e9sz, \u00edgy nincs mit romba d\u00f6nteni. Ez\u00e9rt edz\u00e9sk\u00e9nt is lehet haszn\u00e1lni. Ez a megk\u00f6zel\u00edt\u00e9s m\u0171k\u00f6dik. De nem minden c\u00e9gnek van lehet\u0151s\u00e9ge gyakran ilyen projekteket ind\u00edtani. B\u00e1r ez is kicsit furcsa, mert most folyik a digit\u00e1lis transzform\u00e1ci\u00f3, mindenkinek k\u00eds\u00e9rleteznie kell, hogy l\u00e9p\u00e9st tartson a versenyt\u00e1rsakkal.<\/em> <\/p>\n<\/p>\n
Itt abba \u00fctk\u00f6z\u00f6l, hogy el\u0151sz\u00f6r meg kell \u00e9rtened, mit is kell tenni. A vil\u00e1g nem t\u00f6k\u00e9letes, a prod sem t\u00f6k\u00e9letes. <\/p>\n
<\/p>\n
Igen, ezek a dolgok \u00f6sszef\u00fcggnek.<\/em><\/p>\n<\/p>\n
A v\u00e1llalkoz\u00e1soknak sem mindig van tudom\u00e1suk arr\u00f3l, hogy hova kellene haladniuk. <\/p>\n
<\/p>\n
Van olyan helyzet, amikor semmilyen v\u00e1ltoz\u00e1s nem lehets\u00e9ges. Ez a helyzet akkor \u00e1ll el\u0151, amikor a csapatra nagyobb nyom\u00e1s nehezedik. A csapat m\u00e1r el\u00e9gg\u00e9 ki\u00e9gett. Nincs idej\u00fck k\u00eds\u00e9rletezni. Reggelt\u0151l estig \u00faj funkci\u00f3kat fejlesztenek. \u00c9s a vezet\u00e9s nem el\u00e9gedett a funkci\u00f3kkal, egyre t\u00f6bbet k\u00f6vetelnek. Ilyen helyzetben val\u00f3j\u00e1ban semmif\u00e9le v\u00e1ltoz\u00e1s nem lehets\u00e9ges. Csak annyit tudnak mondani a csapatnak, hogy holnap \u00fagy dolgozunk, mint tegnap, csak egy kicsit t\u00f6bb funkci\u00f3t kell k\u00e9sz\u00edteni. Semmilyen gyakorlatra \u00e1tt\u00e9rni ebben az \u00e9rtelemben nem lehets\u00e9ges. Ez egy klasszikus helyzet, amikor nincs id\u0151 a balta \u00e9lez\u00e9s\u00e9re, f\u00e1t kell v\u00e1gni, ez\u00e9rt tompa balt\u00e1val v\u00e1gnak. Itt nincsenek egyszer\u0171 tan\u00e1csok.<\/em> <\/p>\n<\/p>\n
(Dmitrij) Felolvasom a pontos\u00edt\u00e1st a chatr\u00f3l: \u201eDe nagy tesztlefedetts\u00e9gre van sz\u00fcks\u00e9g k\u00fcl\u00f6nb\u00f6z\u0151 szinteken. Mennyi id\u0151t sz\u00e1nnak a tesztel\u00e9sre? Valahogy t\u00fal dr\u00e1ga, sok id\u0151t elvesz.\u201d<\/em><\/p>\n<\/p>\n
(Oleg) Ez a klasszikus t\u00e9vhit. El\u00e9g tesztnek kell lennie ahhoz, hogy \u00f6nbizalommal rendelkezzen. A Continuous Integration nem olyan dolog, ahol el\u0151sz\u00f6r 100%-os teszt k\u00f6vetkezik, \u00e9s csak ut\u00e1na kezded el alkalmazni ezt a gyakorlatot. A Continuous Integration cs\u00f6kkenti a kognit\u00edv terhel\u00e9st az\u00e1ltal, hogy minden egyes v\u00e1ltoztat\u00e1s, amit a szemed l\u00e1t, olyan nyilv\u00e1nval\u00f3, hogy meg\u00e9rted \u2013 elt\u00f6rik-e valamit vagy sem, m\u00e9g tesztel\u00e9s n\u00e9lk\u00fcl is. Fejben gyorsan tesztelheted, mert kicsi a v\u00e1ltoz\u00e1s. M\u00e9g ha csak manu\u00e1lis tesztel\u0151k is vannak, nekik is k\u00f6nnyebb. Kiadtad, \u00e9s mondtad: \"N\u00e9zd, nem t\u00f6r\u00f6tt el semmi?\". Ellen\u0151rizt\u00e9k, \u00e9s azt mondt\u00e1k: \"Nem, semmi nem t\u00f6r\u00f6tt el\". Mert a tesztel\u0151 tudja, hova n\u00e9zzen. Van egy commit, amely egy k\u00f3dfoszl\u00e1nyhoz kapcsol\u00f3dik. \u00c9s ez konkr\u00e9t viselked\u00e9st produk\u00e1l.<\/em><\/p>\n<\/p>\n
Itt persze kicsit sz\u00e9p\u00edtett\u00e9l. <\/p>\n
<\/p>\n
(Dmitry) Itt nem \u00e9rtek egyet. Van egy gyakorlat \u2013 a tesztel\u00e9s \u00e1ltali fejleszt\u00e9s, ami \u00e9ppen ett\u0151l meg fog menteni.<\/em> <\/p>\n<\/p>\n
(Oleg) Igen, id\u00e1ig m\u00e9g nem jutottam el. Az els\u0151 ill\u00fazi\u00f3 az, hogy 100%-os tesztet kell \u00edrni, vagy egy\u00e1ltal\u00e1n nem kell foglalkozni a Continuous Integration-nel. Ez nem igaz. Ez k\u00e9t p\u00e1rhuzamos gyakorlat. \u00c9s k\u00f6zvetlen\u00fcl nem f\u00fcggenek egym\u00e1st\u00f3l. A tesztlefedetts\u00e9gednek optim\u00e1lisnak kell lennie. Az optim\u00e1lis azt jelenti, hogy magabiztos vagy abban, hogy a mestered min\u0151s\u00e9ge, amely a commit ut\u00e1n maradt, lehet\u0151v\u00e9 teszi, hogy magabiztosan nyomd meg a \"Deploy\" gombot p\u00e9ntek este, r\u00e9szeg \u00e1llapotban. Hogyan \u00e9red ezt el? \u00c1tn\u00e9z\u00e9sekkel, lefedetts\u00e9ggel, j\u00f3 monitoroz\u00e1ssal.<\/em> <\/p>\n<\/p>\n
A j\u00f3 monitoroz\u00e1s nem k\u00fcl\u00f6nb\u00f6zik a tesztekt\u0151l. Ha a teszteket egyszer futtatod a pre prod-on, akkor azok egyszer ellen\u0151rzik az \u00f6sszes felhaszn\u00e1l\u00f3i szcen\u00e1ri\u00f3t, \u00e9s ennyi. De ha v\u00e9gtelen ciklusban futtatod \u0151ket, akkor ez a kib\u0151v\u00edtett monitoroz\u00e1si rendszered, ami v\u00e9gtelen\u00fcl mindent tesztel \u2013 \u00f6sszeomlott-e vagy sem. Ebben az esetben a k\u00fcl\u00f6nbs\u00e9g csak az egyszeri vagy t\u00f6bbsz\u00f6ri futtat\u00e1s. Egy nagyon j\u00f3 tesztk\u00e9szlet\u2026, amelyet v\u00e9gtelen\u00fcl futtatsz, ez a monitoroz\u00e1s. \u00c9s a helyes monitoroz\u00e1snak pontosan ilyennek kell lennie.<\/em> <\/p>\n<\/p>\n
\u00c9s ez\u00e9rt, hogyan \u00e9red el ezt az \u00e1llapotot, amikor p\u00e9ntek este ki tudsz telep\u00edteni, \u00e9s hazamehetsz, az egy m\u00e1sik k\u00e9rd\u00e9s. Lehet, hogy egyszer\u0171en mer\u00e9sz vagy.<\/em> <\/p>\n<\/p>\n
N\u00e9zz\u00fcnk vissza kicsit a Continuous Integration-re. Kiss\u00e9 elt\u00e9rt\u00fcnk egy olyan \u00f6sszetett gyakorlatra. <\/p>\n
<\/p>\n
A m\u00e1sodik ill\u00fazi\u00f3 pedig az, hogy az MVP-t gyorsan kell elk\u00e9sz\u00edteni, ez\u00e9rt ott a tesztek egy\u00e1ltal\u00e1n nem sz\u00fcks\u00e9gesek. Ez nem eg\u00e9szen \u00edgy van. Az a helyzet, hogy amikor MVP-t \u00edrsz, a user story-t vagy \u00fagy fejleszted, hogy hallottad, van egy user story \u00e9s azonnal neki\u00e1llsz k\u00f3dolni, vagy TDD alapj\u00e1n dolgozol. \u00c9s a TDD szerint, ahogy a gyakorlat mutatja, nem is tart tov\u00e1bb, azaz a tesztek mell\u00e9kterm\u00e9kek. A TDD gyakorlata nem arr\u00f3l sz\u00f3l, hogy tesztelj\u00fcnk. Annak ellen\u00e9re, hogy Test Driven Development-nek h\u00edvj\u00e1k, itt val\u00f3j\u00e1ban nem a tesztekr\u0151l van sz\u00f3. Ez ink\u00e1bb egy architektur\u00e1lis megk\u00f6zel\u00edt\u00e9s. Ez az a megk\u00f6zel\u00edt\u00e9s, hogyan \u00edrjuk azt, amire sz\u00fcks\u00e9g van, \u00e9s ne \u00edrjunk olyat, amire nincs sz\u00fcks\u00e9g. Ez a gyakorlat a figyelem \u00f6sszpontos\u00edt\u00e1s\u00e1ra vonatkozik a gondolatod k\u00f6vetkez\u0151 iter\u00e1ci\u00f3j\u00e1ra az alkalmaz\u00e1s architekt\u00far\u00e1j\u00e1nak l\u00e9trehoz\u00e1sa sor\u00e1n.<\/em> <\/p>\n<\/p>\n
Ez\u00e9rt ezeket az ill\u00fazi\u00f3kat nem olyan egyszer\u0171 megsz\u00fcntetni. Az MVP \u00e9s a tesztek nem z\u00e1rj\u00e1k ki egym\u00e1st. Ink\u00e1bb ellenkez\u0151leg, ha az MVP-t TDD gyakorlat szerint k\u00e9sz\u00edted, akkor jobban \u00e9s gyorsabban k\u00e9sz\u00fcl el, mint ha egy\u00e1ltal\u00e1n nem alkalmazn\u00e1d a gyakorlatot, hanem csak \u00fagy, ahogy esik.<\/em><\/p>\n<\/p>\n
Ez egy nagyon nem nyilv\u00e1nval\u00f3 \u00e9s \u00f6sszetett gondolat. Amikor hallod, hogy most m\u00e9g teszteket is \u00edrok, \u00e9s \u00edgy gyorsabban elv\u00e9gzek valamit, ez teljesen \u00e9sszer\u0171tlen\u00fcl hangzik. <\/p>\n
<\/p>\n
(Dmitrij) Itt sokan, amikor MVP-t emlegetnek, a n\u00e9p lustas\u00e1ga miatt nem akarnak norm\u00e1lisan \u00edrni. \u00c9s ezek m\u00e9gis k\u00fcl\u00f6nb\u00f6z\u0151 dolgok. Az MVP-t ne v\u00e1ltoztassuk valami rossz dologg\u00e1, ami nem m\u0171k\u00f6dik.<\/em> <\/p>\n<\/p>\n
Igen, igazad van.<\/p>\n
<\/p>\n
Azt\u00e1n hirtelen az MVP a produkci\u00f3s k\u00f6rnyezetbe.<\/em><\/p>\n<\/p>\n
\u00d6r\u00f6kre. <\/p>\n
<\/p>\n
A TDD nagyon szokatlanul hangzik, amikor hallod, hogy tesztet \u00edrsz, \u00e9s l\u00e1tsz\u00f3lag t\u00f6bb munk\u00e1t v\u00e9gzel. Ez nagyon furcs\u00e1n hangzik, de val\u00f3j\u00e1ban \u00edgy gyorsabb \u00e9s szebb is. Amikor \u00edrsz egy tesztet, m\u00e1r a fejedben sokat gondolsz arra, milyen k\u00f3dot \u00edrsz, \u00e9s hogyan fogj\u00e1k azt h\u00edvni, valamint milyen viselked\u00e9st v\u00e1runk t\u0151le. Nem csak azt mondod, hogy \u00edrtam egy funkci\u00f3t, \u00e9s az valamit csin\u00e1l. El\u0151sz\u00f6r \u00e1tgondolod, hogy ezek a felt\u00e9telek vannak, \u00edgy fognak h\u00edvni. Ezt te tesztekkel feded le, \u00e9s ebb\u0151l meg\u00e9rted, hogyan fognak kin\u00e9zni a k\u00f3dod bels\u0151 interf\u00e9szei. Ez nagyon er\u0151sen hat az architekt\u00far\u00e1ra. A k\u00f3dod automatikusan modul\u00e1risabb\u00e1 v\u00e1lik, mert el\u0151sz\u00f6r pr\u00f3b\u00e1lod meg\u00e9rteni, hogyan fogod azt tesztelni, \u00e9s csak ut\u00e1na \u00edrod meg. <\/p>\n
<\/p>\n
N\u00e1lam a TDD \u00fagy alakult, hogy egy id\u0151ben egy Ruby mentort fogadtam, mikor m\u00e9g Ruby programoz\u00f3 voltam. Azt mondja: \u201eCsin\u00e1lj TDD-t\u201d. \u00c9n meg gondoltam: \u201eJaj, most m\u00e9g valamit pluszban kellene \u00edrnom\u201d. Meg\u00e1llapodtunk, hogy k\u00e9t h\u00e9t alatt minden munka k\u00f3dot Pythonban TDD alatt \u00edrok. K\u00e9t h\u00e9t m\u00falva r\u00e1j\u00f6ttem, hogy nem akarok visszat\u00e9rni. K\u00e9t h\u00e9t pr\u00f3b\u00e1lkoz\u00e1s ut\u00e1n, hogy ezt mindenhol alkalmazzam, \u00e9szrevettem, hogy mennyivel k\u00f6nnyebb m\u00e1r csak gondolkodni. De ez nem nyilv\u00e1nval\u00f3, ez\u00e9rt mindenkinek azt javaslom, hogy ha \u00fagy \u00e9rzi, a TDD neh\u00e9z, hosszadalmas \u00e9s felesleges, pr\u00f3b\u00e1lja meg k\u00e9t h\u00e9tig k\u00f6vetni. Nekem ez elegend\u0151 volt.<\/p>\n
<\/p>\n
(Dmitrij) Ezt a gondolatot az infrastrukt\u00fara \u00fczemeltet\u00e9s\u00e9nek szempontj\u00e1b\u00f3l is kifejthetj\u00fck. Miel\u0151tt valami \u00fajat ind\u00edtunk, monitorozunk, majd ind\u00edtunk. Ebben az esetben a monitoroz\u00e1s norm\u00e1lis tesztel\u00e9s mellett zajlik. \u00c9s a monitoroz\u00e1s \u00e1ltal t\u00f6rt\u00e9nik a fejleszt\u00e9s. De szinte mindenki azt mondja, hogy ez hosszadalmas, lusta vagyok, csin\u00e1ltam egy ideiglenes v\u00e1zlatot. Ha norm\u00e1lisan monitoroztunk, meg\u00e9rtj\u00fck a CI rendszer \u00e1llapot\u00e1t. A CI rendszerben sok a monitoroz\u00e1s. Meg\u00e9rtj\u00fck a rendszer \u00e1llapot\u00e1t, tudjuk, mi folyik benne. A fejleszt\u00e9s sor\u00e1n \u00e9ppen azt csin\u00e1ljuk, hogy a rendszer eljusson a sz\u00fcks\u00e9ges \u00e1llapotba.<\/em> <\/p>\n<\/p>\n
Ezek a gyakorlatok r\u00e9g\u00f3ta ismertek. K\u00f6r\u00fclbel\u00fcl n\u00e9gy \u00e9ve besz\u00e9lt\u00fcnk err\u0151l. De n\u00e9gy \u00e9v alatt szinte semmi sem v\u00e1ltozott.<\/em> <\/p>\n<\/p>\n
De ezen a megjegyz\u00e9sen javaslom, hogy z\u00e1rjuk le a hivatalos vit\u00e1t.<\/em><\/p>\n<\/p>\n
Vide\u00f3 (be\u00e1gyazva mint m\u00e9diaelem, de valami\u00e9rt nem m\u0171k\u00f6dik):<\/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
![\"A](\"\/wp-content\/uploads\/2020\/09\/ed8a32ae63b8dccfc8b4893ab27f1527.jpg\")
<\/p>\n