Le të flasim pse mjetet CI dhe CI janë krejtësisht të ndryshme.
Cilin problem duhet të zgjidhë CI, nga erdhi ideja, çfarë konfirmimesh të fundit ka që funksionon, si ta kuptoni që keni praktikë dhe jo thjesht një Jenkins të instaluar.
Ideja për të bërë një prezantim mbi Integrimin e vazhdueshëm lindi një vit më parë, kur isha duke bërë intervista për të gjetur punë. Kam biseduar me 10-15 kompani, nga të cilat vetëm një mundi të përgjigjej qartë se çfarë është CI dhe të shpjegonte si e kuptuan ata që nuk e kishin. Të tjerët thoshin gjëra të paqarta rreth Jenkinsit 🙂 Po, ne e kemi Jenkinsin, ai bën ndërtimet, CI! Për prezantimin do përpiqem të shpjegoj se çfarë është Integrimi i vazhdueshëm në të vërtetë dhe pse Jenkins dhe mjetet e ngjashme kanë një lidhje shumë të dobët me këtë.
Pra, çfarë i vjen zakonisht në mendje kur thoni CI? Shumicës së njerëzve do t'i vije në mendje Jenkins, Gitlab CI, Travis etj.
Edhe nëse e kërkojmë atë në Google, do të na dalin këto mjete.
Nëse pyesni njohuritë, menjëherë pas renditjes së mjeteve, ata do t'ju tregojnë se CI është kur ndodh një ndërtim dhe testi në Pull Request për një commit.
Integrimi i vazhdueshëm nuk është për mjetet, nuk është për ndërtimet me teste në degë! Integrimi i vazhdueshëm është një praktikë e integrimit shumë të shpeshtë të kodit të ri dhe për ta përdorur këtë as nuk është e nevojshme të krijoni Jenkins, GitLab etj.
Para se të kuptojmë si duket një CI i plotë, le të zhytim fillimisht në kontekstin e njerëzve që e shpikën këtë dhe ta ndjejmë dhimbjen që po përpiqeshin ta zgjidhnin.
Ata synonin një dhimbje të bashkëpunimit në ekip!
Le të shohim shembuj, me cilat vështirësi përballen zhvilluesit gjatë zhvillimit në ekip. Ja, kemi një projekt, degën master në git dhe dy zhvillues.
Dhe ata filluan të punonin siç kanë bërë të gjithë atëherë. Morën një detyrë në JIRA, krijuan një feature branch, dhe shkruan kod.
Njëri përfundoi karakteristikën më shpejt dhe e bashkoi me masterin.
Tjetri iu desh më shumë kohë, ai u bashkua më vonë dhe mori një konflikt. Tani, në vend që të shkruajë karakteristikat e nevojshme për biznesin, zhvilluesi po shpenzon kohën dhe energjinë e tij për të zgjidhur konfliktet.
Sa më e komplikuar të bashkosh karakteristikën tënd me masterin e përbashkët, aq më shumë kohë shpenzojmë për këtë. Dhe kjo është ende një shembull mjaft i thjeshtë. Ky është një shembull, ku zhvilluesit janë vetëm 2. Imagjino se si do të ishte po të ishin 10, 15 apo 100 njerëz në kompani që shkruajnë në një depozitë. Do të çmendesh për të zgjidhur të gjithë këto konflikte.
Ka një rast pak më ndryshe. Ne kemi masterin dhe disa zhvillues që po bëjnë diçka.
Ata krijuan nga një degë.
Njëri u bashkua, gjithçka shkoi mirë, dorëzoi detyrën.
Ndërkohë, zhvilluesi i dytë dorëzoi detyrën e tij. Supozoni se ai ia dha për shqyrtim. Në shumë kompani ekziston praktika e shqyrtimit. Në një anë, kjo është një praktikë e mirë dhe e dobishme; në anën tjetër, na ngadalëson në shumë mënyra. S’do të shkojmë thellë në këtë, por ja një shembull i shkëlqyer se çfarë mund të sjellë një histori e pasuksesshme me shqyrtimin. Ju i dërguat një kërkesë për bashkim për shqyrtim. Zhvilluesit nuk kanë gjë tjetër për të bërë. Çfarë fillon të bëjë? Fillon të marrë detyra tjera.
Në atë kohë, zhvilluesi i dytë gjithashtu bëri ndonjëherë diçka.
I pari përfundoi detyrën e tretë.
Dhe pas një kohe të gjatë, shqyrtimi i tij u provua dhe ai përpiqet të bashkohet. Çfarë ndodh? Ai kap një numër të madh konfliktesh. Pëse? Sepse ndërkohë që kërkesa e tij për bashkim ishte për shqyrtim, shumë gjëra ishin ndërruar në kod.
Përveç historisë së konflikteve, ka një histori për komunikimet. Ndërsa dega juaj është në shqyrtim, ndërsa ajo pret diçka, ndërsa ju po punoni gjatë për një karakteristikë, ju ndaloni së ndjekuri se çfarë tjetër ndryshon në bazën e kodit të shërbimit tuaj. Ndoshta, ajo që tani po përpiqeni të zgjidhni, është zgjidhur nga dje dhe mund të merrni dhe të ripërdorni ndonjë metodë. Por nuk do ta shihni këtë, sepse gjithmonë po punoni me një degë të vjetruar. Dhe kjo degë e vjetruar gjithmonë çon në situatën ku do t'ju duhet të zgjidhni një konflikt bashkimi.
Pra, rezulton se nëse ne punojmë si një ekip, pra, jo një njeri po bëhet në depo, por rreth 5-10 njerëz, aq më gjatë që ne nuk e shtojmë kodin tonë në master, aq më shumë vuajmë nga fakti se në fund duhet të bashkojmë diçka. Dhe sa më shumë konflikte kemi dhe sa më të vjetër e kemi versionin me të cilin punojmë, aq më shumë probleme do të kemi.
Të bësh diçka së bashku është e dhimbshme! Ne gjithmonë pengojmë njëri-tjetrin.
Ky kjo problem u vërejt 20 e më shumë vjet më parë. Referenca e parë për praktikën e Continuous Integration e kam gjetur në programim ekstremin.
Programimi ekstrem është framework-u i parë agile. Faqja doli në vitin 96. Dhe ishte ideja për të përdorur disa praktika programimi, planifikimi e kështu me radhë, që zhvillimi të ishte sa më fleksibël, që të mund të reagojmë më shpejt ndaj disa ndryshimeve, kërkesave nga klientët tanë. Dhe ata 24 vjet më parë filluan të përballeshin me këtë, që nëse bën diçka shumë gjatë e në anë, atëherë po humbasin më shumë kohë për shkak të konflikteve.
Tani do ta shqyrtojmë shprehjen "Continuous Integration" sipas fjalëve të veçanta. Nëse e përkthejmë drejtpërdrejt, del integrim i pandërprerë. Por sa është vërtetë pandërprerë nuk është shumë e qartë, ajo është mjaft e ndërprerë. Por sa është integrim gjithashtu nuk është shumë e dukshme.
Dhe për këtë po ju sjell tani citate nga programimi ekstrem. Dhe do t'i shqyrtojmë të dy fjalët veç e veç.
Integration — Siç e theksova, ne strehim që çdo inxhinier të punojë me versionin më të fundit të kodit, që ai të përpiqet të shtojë kodin e tij sa më shpesh në degën e përbashkët, që ato të jenë degë shumë të vogla. Sepse nëse ato janë të mëdha, mund të ngecim lehtësisht për një javë me konflikte të bashkimit. Sidomos nëse kemi një cikël të gjatë zhvillimi si waterfall, ku zhvilluesi është larguar për një muaj për të punuar një karakteristikë të madhe. Dhe ai gjatë integrimit do të ngecë për një kohë të gjatë.
Integration – është kur e marrim degën tonë dhe e integrojmë atë me master-in, ne e bashkojmë. Ka një variant ultimativ, kur ne e transbasojmë zhvilluesin, ku ne synojmë që të shkruajmë direkt në master pa degë të tepruara.
Në përgjithësi, integration – është të marrësh kodin tënd dhe ta sjellësh atë në master.
Çfarë nënkuptohet këtu me fjalën "continuous", çfarë quhet vazhdimësi? Prakika nënkupton që zhvilluesi përpiqet të integrojë kodin e tij sa më shpejt të jetë e mundur. Kjo është qëllimi i tij gjatë realizimit të çdo detyre – të bëjë në mënyrë që kodi i tij të shfaqet në master sa më shpejt. Në një botë ideale, zhvilluesit do ta bënin këtë çdo disa orë. Do të thotë, merrni një detyrë të vogël, e bashkëngjitni në master. E gjithë kjo është e shkëlqyer. Kështu duhet të synoni. Dhe duhet ta bëni atë vazhdimisht. Sa herë që bëni diçka, menjëherë e dërgoni në master.
Dhe zhvilluesi që bën diçka është përgjegjës për atë që bëri, që të funksionojë dhe të mos prishë asgjë. Këtu zakonisht lind historia me testet. Ne duam të ekzekutojmë disa teste mbi commit-in tonë, mbi bashkimin tonë, për të siguruar që kjo funksionon. Dhe këtu Jenkins mund t'ju ndihmojë.
Por me historinë: le të jenë ndryshimet të vogla, le t'i bëjmë detyrat të vogla, le të përpiqemi të bashkojmë detyrat direkt në master – këtu asnjë Jenkins nuk do t'ju ndihmojë. Sepse Jenkins do t'ju ndihmojë vetëm për të ekzekutuar testet.
Mund të kaloni edhe pa to. Kjo nuk do t'ju pengojë aspak. Sepse qëllimi i praktikës është që të bashkoheni sa më shpesh, për të mos shpenzuar një kohë të madhe në ndonjë konflikte në të ardhmen.
Të imagjinojmë se jemi në vitin 2020 ndonjëherë pa internet. Dhe ne po punojmë lokal. Nuk kemi Jenkins. Kjo është normale. Ende mund të merrni dhe të krijoni një degë lokale. Keni shkruar ndonjë kod në të. Keni bërë një detyrë për 3-4 orë. Jeni kaluar në master, keni bërë git pull, keni bashkuar degën tuaj atje. Keni mbaruar. Nëse e bëni këtë shpesh – përgëzime, keni Continuous Integration!
Cilat janë provat në botën moderne se ia vlen të investosh energji për këtë? Sepse në përgjithësi është e vështirë. Nëse provoni të punoni kështu, do të kuptoni se tani do të përfshiheni në një planifikim të caktuar, do t'ju duhet të kaloni më shumë kohë për të dekomponuar detyrat. Sepse nëse do të bëni man…, nuk do të mund të bashkoheni shpejt dhe, për rrjedhojë, do të bini në telashe. Nuk do të keni më praktikën.
Dhe kjo do të jetë e shtrenjtë. Nuk do të mund të punoni me Continuous Integration që nga nesër. Të gjithë do t'ju duhet shumë kohë të përshtateni, shumë kohë të mësoni të dekompozoni detyrat, shumë kohë të mësoni të rishikoni praktikat, nëse i keni. Sepse qëllimi ynë është që të bëhet bashkimi sot. Nëse e bëni rishikimin për tre ditë, atëherë keni probleme dhe nuk e realizoni Continuous Integration.
Por a kemi ndonjë provë të rëndësishme tani që na tregon se ka kuptim të investohet në këtë praktikë?
E para që më shkon në mendje është State of DevOps. Kjo është një kërkim që ata e bëjnë tashmë për 7 vjet. Tani ata e bëjnë si një organizatë të pavarur, por nën Google.
Dhe kërkimi i tyre në vitin 2018 tregoi një korelacion mes kompanive që përpiqen të përdorin degë me jetë të shkurtër, të cilat integlohen shpejt, integlohen shpesh, ato kanë tregues më të mirë të performancës IT.
Cilat janë këta tregues? Këto janë 4 metrika që ata grumbullojnë nga të gjitha kompanitë në anketat e tyre: frekuenca e vendosjes, koha për ndryshime, koha për të rikthyer shërbimin, shkalla e dështimit të ndryshimeve.
Së pari, ka këtë korelacion, ne e dimë se kompanitë që bëjnë shpërthime shpesh, ato kanë këto metrika shumë më të mira. Dhe ata e ndajnë kompanitë në disa kategori: kompani të ngadalta, që prodhojnë diçka ngadalë, performerë të mesëm, performerë të lartë dhe elita. Elita – kjo është Netflix, Amazon, që janë shumë të shpejtë, gjithçka e bëjnë shpejt, bukur dhe me cilësi.
Historia e dytë, që ndodhi pikërisht para një muaji. Në Technology Radar u shfaq një shënim i shkëlqyer mbi Gitflow. Gitflow ndryshon nga të tjerët sepse degët e tij jetojnë gjatë. Ka degë lëshimi që jetojnë gjatë, degë funksionesh që gjithashtu jetojnë gjatë. Kjo praktikë në Technology Radar është kaluar në HOLD. Pse? Sepse njerëzit përballen me dhimbje integrimi.
Nëse ke një degë që jeton shumë gjatë, ajo ngec, kalbet, ne fillojmë të harxhojmë më shumë kohë për të bërë një ndryshim në të.
Dhe sapo autori i Gitflow tha se, nëse jeni duke synuar Integrimin e Vazhdushëm, nëse dëshironi të lëvizni sa më shpesh të jetë e mundur, atëherë Gitflow është një ide e keqe. Ai theksoi gjithashtu në një artikull se, nëse keni një backend ku mund ta arrini këtë, atëherë Gitflow është i tepërt për ju, sepse Gitflow do t'ju ngadalësojë dhe do t'ju krijojë probleme me integrimin.
Kjo nuk do të thotë se Gitflow është i keq dhe se nuk duhet ta përdorni. Ai është për raste të tjera. Për shembull, kur ju nevojitet të mbani disa versione të shërbimit, aplikacionit, pra, atje ku ju nevojitet të mbështesni gjatë një periudhe të gjatë.
Por nëse bisedoni me njerëzit që mbështesin këto shërbime, do të dëgjoni shumë ankesë se kjo version ishte 3.2, që ishte 4 muaj më parë, dhe nuk përfshiu këtë ndreqje dhe tani, për ta futur, duhet të bëni shumë ndryshime. Dhe tani janë sërish të bllokuar, dhe po kalojnë një javë duke u përpjekur të marrin dhe të bashkojnë ndonjë veçori të re.
Siç vuri në dukje saktësisht Aleksandër Kovaljev në bisedë, korrelacioni nuk është e njëjtë me lidhjen shkak-pasojë. Kjo është e vërtetë. Do të thotë, nuk ka ndonjë lidhje të drejtpërdrejtë, që nëse keni Integrim të Vazhdushëm, atëherë të gjitha metrikat do të jenë të shkëlqyera, jo. Por ka një korrelacion pozitiv, që nëse kemi njërin, atëherë shumë gjasa kemi edhe tjetrin. Nuk është fakt, por është shumë e mundshme. Kjo është vetëm një korrelacion.
Duket se ne po bëjmë diçka, duket se po i bashkojmë, por si të kuptojmë se integrimi i vazhdueshëm na e ka; se ne po bashkohemi mjaft shpesh?
Jez Humble është autori i Handbook, Accelerate, faqes Continuous Delivery dhe librit "Continuous Delivery". Ai ofron një test të tillë:
- Kodi i inxhinierit hyn në master çdo ditë.
- Për çdo commit, ju ndizni testet unit.
- Build-i në master ra, e riparuan brenda rreth 10 minutash.
Ai propozon të përdorni një test të tillë për të siguruar se praktika juaj është me të vërtetë aty.
E fundit e gjej pak të diskutueshme. Pra, nëse mund ta rregulloni brenda 10 minutash, atëherë keni Continuous Integration, kjo duket pak e çuditshme për mendimin tim, por ka kuptim. Pse? Sepse, nëse bëni merge shpesh, kjo do të thotë që ndryshimet janë të vogla. Nëse ndonjë ndryshim i vogël shkakton dështimin e ndërtimit të masterit, do të mund ta gjeni shpejt, sepse ndryshimi është i vogël. Keni pasur një merge të vogël, në të cilin janë ndryshuar 20-30 rreshta. Dhe, përkatësisht, mund ta kuptoni shpejt se cila është arsyeja, sepse ndryshimet janë shumë të vogla, keni një zonë shumë të vogël për të kërkuar problemin.
Dhe edhe nëse prodhimi ynë prishet pas lançimit, nëse kemi praktikën e Continuous Integration, na është shumë më e lehtë të veprojmë, sepse ndryshimet janë të vogla. Po, kjo do ta prekë planifikimin. Do të jetë e dhimbshme. Dhe, ndoshta, gjëja më e vështirë në këtë praktikë është të mësohesh të ndash detyrat, pra, si të bësh diçka dhe ta realizosh brenda disa orëve dhe në të njëjtën kohë të kalosh nëpër rishikim, nëse e ke atë. Rishikimi është një dhimbje e veçantë.
Testet unitare janë thjesht një ndihmës që ju ndihmon të kuptoni nëse integrimi juaj kalon me sukses, nëse vërtet nuk ka ndodhur ndonjë prishje. Për mendimin tim, kjo gjithashtu nuk është një pikë e domosdoshme, sepse kuptimi i praktikës nuk qëndron aty.
Ky ishte një përmbledhje e shkurtër për Continuous Integration. Kjo është gjithçka që ka në këtë praktikë. Jam gati për pyetje.
Përmbledh faktikisht vetëm një herë tjetër:
- Continuous Integration nuk është Jenkins, nuk është Gitlab.
- Nuk është një mjet, është një praktikë për atë që ne sa më shpesh që mundemi i bëjmë merge kodin tonë në master.
- E bëjmë këtë që të shmangim dhimbjen e madhe që ndodh me mërgjet në të ardhmen, pra, përjetojmë një dhimbje të vogël tani, që të mos përjetojmë një të madhe në të ardhmen. Kjo është e gjithë kuptimi.
- Nga ana tjetër, komunikimi kalon përmes kodit, por unë këtë e shoh shumë rrallë, por për këtë është menduar gjithashtu.
Pyetje
Çfarë të bëjmë me detyrat e pa ndarë?
T'i ndajmë. Çfarë është problemi? Mundi të sillni një shembull, se ka një detyrë dhe ajo nuk ndahet?
Ka detyra të tilla që nuk mund të ndahen fare, për shembull, ato që kërkojnë ekspertizë të thellë dhe që vërtet mund të zgjidhen për një muaj deri në një rezultat të pranueshëm.
Nëse te kuptova drejtë, ka një detyrë të madhe dhe të komplikuar, rezultatet e së cilës do të jenë të dukshme vetëm pas një muaji?
Po, e saktë. Po, mund të vlerësojmë rezultatin jo më herët se pas një muaji.
Mirë. Në përgjithësi, kjo nuk është një problem. Pse? Sepse, në këtë rast, kur flasim për degë, nuk flasim për një degë me një veçori. Veçoritë mund të jenë të mëdha dhe të komplikuara. Ato mund të prekin një numër të madh komponentësh. Dhe ndoshta, nuk mund t'i realizojmë plotësisht brenda një dege. Kjo është normale. Na nevojitet vetëm ta ndajmë këtë histori. Nëse veçoria nuk është gati deri në fund, kjo nuk do të thotë se disa pjesë të kodit të saj nuk mund të bashkohen. Për shembull, ke shtuar një migrim dhe brenda veçorisë ka disa etapa. Ki etapat – bënë migrimin, shto një metodë të re. Dhe këto gjëra mund t'i bashkosh çdo ditë.
Mirë. Çfarë ka në këtë rast?
ÇFarë kuptimi ka të bashkosh gjëra të vogla çdo ditë?
Po.
Nëse ato të kanë prishur ndonjë gjë, e sheh menjëherë. Ke një copë të vogël që e ka prishur diçka, është më e lehtë ta rregullosh. Kuptimi është që të bashkosh një copë të vogël tani është shumë më e lehtë se sa të bashkosh diçka të madhe pas disa javësh. Dhe kuptimi i tretë është që inxhinierët e tjerë do të punojnë me versionin aktual të kodit. Ata do të shohin se këtu janë shtuar disa migrazione, e këtu është shfaqur një metodë, të cilën ndoshta ata do të duan ta përdorin gjithashtu. Të gjithë do të shohin se çfarë ndodh me kodin tënd. Pikërisht për këto tre gjëra bëhet kjo praktikë.
Faleminderit, pyetja është e mbyllur!
(Oleg Soroka) Mund të shtoj një gjë? E theve saktë, vetëm dua të shtoj një frazë.
Ashtu.
Me Continuous Integration, kodi bashkohet në degen përkatëse jo kur veçoria është plotësisht e gatshme, por kur ndalon së prishuri buildin. Dhe ju mund të angazhoni në master sa herë që të dëshironi gjatë ditës. Aspekti i dytë – nëse nuk mund të ndash një detyrë mujor në detyra për të paktën tri ditë, e lë për tri orë, atëherë ke një problem të madh. Dhe fakti që nuk ke Continuous Integration është problemi më i vogël. Kjo do të thotë që ke probleme me arkitekturën dhe praktikatat inxhinierike janë në zero. Sepse edhe nëse është hulumtim, në çdo rast duhet ta paraqesësh si hipoteza ose cicël.
Kemi folur për 4 metrika që i ndajnë kompanitë e suksesshme nga ato në prapa. Duhet të arrijmë këto 4 metrika. Nëse një detyrë mesatare zgjat një muaj, unë do të përqëndrohesha fillimisht te kjo metrikë. Do ta uja atë fillimisht në 3 ditë. Dhe pas kësaj, do të filloja të mendoja për Continuous.
A e kuptova saktë, që mendon se në përgjithësi nuk ka kuptim të investosh në praktikat inxhinierike, nëse çdo detyrë zgjat një muaj?
Ke Continuous Integration. Dhe aty ka një temë, që brenda 10 minutave duhet të rregullosh një gabim ose të rikthehesh. Imagjino, e nxorre atë. Madje ke edhe continuous deployment, e nxorre në prodhimin dhe vetëm atëherë e vëren se diçka ka shkuar keq. Dhe tani duhet ta rikthehesh, ndërkohë që tashmë ka ndodhur migrimi i bazës së të dhënave. Tashmë ke skemën e versionit të ardhshëm të bazës së të dhënave, madje, gjithashtu ka kaluar ndonjë backup dhe janë regjistruar të dhëna aty.
Dhe cila është alternativa jote? Nëse rikthen kodin prapa, atëherë ai nuk mund të punojë me këtë bazë të dhënash të përditësuar.
Baza lëviz vetëm përpara, po.
Tek njerëzit që kanë praktika inxhinierike të dobëta, shumë mundësi nuk e kanë lexuar as atë libër të trashë për... Çfarë të bësh me backup-in? Nëse rikthehesh nga një backup, atëherë do të thotë se humb të dhënat që janë grumbulluar gjatë kësaj periudhe. Për shembull, ke punuar tre orë me versionin e ri të bazës së të dhënave, atje janë regjistruar përdoruesit. Ti rikthehesh në një backup të vjetër, sepse me versionin e ri skema nuk punon, si për pasojë, këta përdorues i humb. Dhe ata janë të pakënaqur, ata ankohen.
Për të zotëruar të gjithë spektrin e praktikave që mbështesin Continuous Integration dhe Continuous Delivery, nuk mjafton të mësosh thjesht …. Së pari, ato mund të jenë shumë, dhe kjo do të ishte e papraktikshme. Përveç kësaj, ka një numër praktikash të tjera si Scientific. Ekziston një praktikë, që GitHub e popullarizoi një kohë, kur të gjitha kodet, edhe ato të vjetra, edhe ato të reja, ekzekutohen në të njëjtën kohë. Kjo ndodh kur krijon një karakteristikë të pa përfunduar që mund të kthejë një vlerë: si një funksion, ose si një Rest API. Ti ekzekuton të dyja kodet e reja dhe të vjetra dhe krahason ndryshimin midis tyre. Nëse ka një ndryshim, atëherë e regjistron këtë ngjarje. Kështu, ti e di se karakteristika jote e re është gati të aktivizohet mbi të vjetrin, nëse gjatë një periudhe të caktuar nuk ka pasur ndonjë ndryshim mes këtyre dyve.
Ka qindra praktika të tilla. Do të sugjeroja të filloni me zhvillimin e transbase. Ajo nuk është 100 % në Continuous Integration, por praktikat janë të njëjta, njëra nuk jeton mirë pa tjetrën.
A e ke përmendur zhvillimin e transbase si një shembull ku mund të shihen praktikat, apo po sugjeron që njerëzit të fillojnë ta përdorin zhvillimin e transbase?
Të shihen, pasi ata nuk do të jenë në gjendje ta përdorin. Për ta përdorur, duhet të lexojnë shumë. Dhe kur dikush pyet: "Çfarë duhet të bëj me një karakteristikë që zgjat një muaj, kjo do të thotë se ai nuk ka lexuar për zhvillimin e transbase." Unë gjithashtu nuk do të këshilloja akoma. Do të sugjeroja të përqendrohen ekskluzivisht në temën se si të ndajmë arkitektonikisht detyrat e mëdha në më të vogla. Kjo është thelbi i dekonstrukcionit.
Dekonstrukcioni është një nga instrumentet e arkitektit. Ne fillimisht bëjmë një analizë, më pas dekonstruktion, pastaj sintezë, më pas integrim. Dhe kështu gjithçka përbëhet. Dhe përpara se të arrijmë tek Continuous Integration, duhet të rritemi përmes dekonstrukcionit. Pyetjet në fazën e parë dalin, dhe ne tashmë flasim për fazën e katërt, do të thotë, sa më shpesh të bësh integrimin, aq më mirë. Akoma është herët për ta bërë, do të ishte mirë fillimisht të ndahesh monolitin tënd.
Duhet të vizatoni disa shigjeta dhe katrorë në ndonjë diagram. Ti nuk mund të thua se tani do të tregoj një diagram arkitekturor të aplikacionit të ri dhe të tregoj një katror, brenda të cilit është një buton i gjelbër për aplikacionin. Në çdo rast, do të ketë më shumë katrorë dhe shigjeta. Në çdo diagram që kam parë, ka qenë më shumë se një. Dhe dekompozimi madje në nivelin e përfaqësimit grafik tashmë po bëhet. Prandaj, katrorët mund të bëhen të pavarur. Nëse jo, atëherë kam pyetje të mëdha për arkitektin.
Ka një pyetje nga chat-i: "Nëse rishikimi është i detyrueshëm dhe zgjat gjatë, diku një ditë e më shumë?".
Keni probleme me praktikën. Rishikimi nuk duhet të zgjasë një ditë e më shumë. Kjo është e njëjta histori si me pyetjen e mëparshme, vetëm pak më e butë. Nëse rishikimi zgjat një ditë, atëherë shumë ndoshta po bëhet për një ndryshim shumë të madh. Kjo do të thotë se duhet të bëhet më e vogël. Në zhvillimin e transbase, që Oleg e rekomandoi, ka një histori të tillë që quhet rishikim i vazhdueshëm. Ideja e saj është se ne bëjmë një pull request kaq të vogël me qëllim, sepse synojmë të bashkohemi vazhdimisht dhe pak nga pak. Dhe kështu pull request-i ndryshon një abstraksion ose 10 rreshta. Falë kësaj, rishikimi ynë zgjat disa minuta.
Nëse rishikimi zgjat një ditë e më shumë, do të thotë se diçka nuk është në rregull. Së pari, ndoshta keni disa probleme me arkitekturën. Ose është një copë e madhe kodi, për shembull 1,000 rreshta. Ose keni një arkitekturë aq të ndërlikuar sa që njeriu nuk mund ta kuptojë. Kjo është një problem pak nga ana, por gjithashtu do të duhet të zgjidhni. Ndoshta nuk është e nevojshme të bëni rishikim fare. Këtë duhet ta mendoni. Rishikimi – është ajo gjë që ju ngadalëson. Ajo sjell përfitime në përgjithësi, por duhet të kuptoni se përse po e bëni këtë. A është një mënyrë për ju për të kaluar shpejt informacionin, është një mënyrë për të vendosur ndonjë standard të brendshëm, apo çfarë? Përse ju nevojitet kjo? Sepse rishikimi duhet bërë ose shumë shpejt, ose duhet anuluar fare. Është si zhvillimi i transbase – një histori shumë e bukur, por vetëm për djem të pjekur.
Sa i përket 4 metrikave, unë do të rekomandoja që t'i hiqni ato, për të kuptuar se çfarë sjell kjo. Të shikoni në numra, të shikoni imazhin, sa e keqe është gjithçka.
(Dmitri) Jam gati të hyj në një diskutim mbi këtë me ty. Numrat dhe metrikat janë të gjitha të shkëlqyera, praktikat janë të shkëlqyera. Por duhet të kuptojmë – a është e nevojshme për biznesin? Ka biznese që nuk kanë nevojë për një shpejtësi të tillë ndryshimi. Unë di kompani ku nuk është e mundur të bëhen ndryshime çdo 15 minuta. Dhe jo sepse janë të këqij. Është një cikël jetësor. Dhe për të bërë veçoritë branches, veçoritë toggle, nevojiten njohuri të thella.
Është e komplikuar. Nëse dëshiron të lexosh një histori më të hollësishme për veçorinë toggle, atëherë të rekomandoj shumë. . Dhe ka një artikull të shkëlqyer nga Martin Fowler rreth veçorive toggle: për llojet që ekzistojnë, ciklet e jetës, etj. Veçoria toggle – është e komplikuar.
Dhe ti ende nuk përgjigje për pyetjen: "A është Jenkins i nevojshëm apo jo?"
Jenkins në të vërtetë nuk është i nevojshëm në asnjë rast. Nëse flasim seriozisht, mjetet: Jenkins, Gitlab do t'ju sjellin lehtësi. Do të shihni nëse ndërtimi është bërë apo jo. Ato mund t'ju ndihmojnë, por nuk do t'ju japin praktikë. Ato mund t'ju japin vetëm një rreth – OK, nuk OK. Dhe kjo, nëse ende shkruani teste, sepse nëse nuk ka teste, atëherë kjo është pothuajse e pafalshme. Pra, është i nevojshëm, sepse – është më e lehtë, por në përgjithësi mund të jetoni edhe pa të, nuk do humbni shumë.
Pra, nëse keni praktika, atëherë do të thotë se nuk ju nevojitet?
E drejtë. Unë rekomandoj testin Jez Humble. Atje kam një qëndrim të dyfishtë mbi pikën e fundit. Por në përgjithësi, nëse keni tri gjëra, po bashkoni vazhdimisht, po ekzekutoni teste të angazhimeve në master, shpejt rregulloni ndërtimin në master, ndoshta nuk keni nevojë për ndonjë gjë tjetër.
Ndërsa presim pyetje nga pjesëmarrësit, kam një pyetje. Ne tani po flisnim për kodin produktor. A e ke përdorur për kodin e infrastrukturës? A është i njëjti kod, ka të njëjtat principe dhe të njëjtin cikël jetësor, apo aty ka cikle dhe principe të tjera? Zakonisht, kur të gjithë flasin për Integrimin dhe Zhvillimin e Vazhdushëm, ata harrojnë se ka edhe kod infrastrukturor. Dhe në kohët e fundit po bëhet gjithnjë e më shumë. A duhet të sjellim të gjitha këto rregulla atje?
Madje jo vetëm se duhet, kjo do të ishte në të vërtetë e shkëlqyer, sepse me siguri do të thjeshtojë jetën. Sa më shpejt të punojmë me kodin, jo me skriptet në bash, por kur kemi kod të mirë.
Stop-stop, skripti në bash – është gjithashtu kod. Mos e prek dashurinë time të vjetër.
Mirë, nuk do të shtyp kujtimet tua. Kam një antipati personale ndaj bash-it. Ai shpesh dështonte në mënyrë të frikshme dhe të shëmtuar. Dhe dështonte shpesh në mënyrë të papritur, prandaj nuk e pëlqej. Por mirë, le të supozojmë se ke kod në bash. Mund të jetë që unë vërtet nuk e kuptoj dhe ndoshta ka korniza normale për testim aty. Unë thjesht nuk jam në këtë fushë. Dhe ne po marrim të njëjtat përfitime.
Sa herë që punojmë me infrastrukturën si kod, ne hasim të njëjtat probleme si zhvilluesit. Disa muaj më parë u përballa me një situatë ku një koleg më dërgoi një pull request me 1,000 rreshta në bash. Dhe ti ngec në rishikim për 4 orë. Problemet janë të njëjta. Akoma është kod. Edhe është akoma punë në bashkëpunim. Ne ngecim me pull request dhe ngecim me ato konflikte të përzierjes të bash-it, për shembull.
Aktualisht po e shoh këtë gjë me programimin më të bukur të infrastrukturës. Kam futur Pulumi në infrastrukturën time. Ky është programim i pastër. Aty është shumë më e bukur, sepse kam të gjitha mundësitë e gjuhës së programimit, dmth. kam bërë toggles të bukura me të njëjtat if-e. Vërtet, ndryshimi im është tashmë në master. Të gjithë e shohin atë. Inxhinierë të tjerë janë të informuar. Ai tashmë ka ndikuar në diçka. Por, përveç kësaj, ai nuk është aktivizuar për të gjithë infrastrukturat. Ai është aktivizuar për stolat e mia të testit, për shembull. Prandaj, për t'u përgjigjur pyetjes tënde edhe njëherë, është e nevojshme. Kjo, si inxhinierë që punojmë me kod, gjithashtu na lehtëson jetën.
A ka ndokush pyetje tjetër?
Kam një pyetje. Dua të vazhdoj diskutimin me Olegun. Në përgjithësi, mendoj se ke të drejtë, se nëse një detyrë të merr një muaj, atëherë ke problem me arkitekturën, ke problem me analizën, dekompozimin, planifikimin etj. Por kam ndjesinë se nëse fillon të jetosh sipas Continuous Integration, atëherë do të fillosh të korrigjosh dhimbjet e planifikimit, sepse nuk mund të ikësh nga kjo.
(Oleg) Po, gjithçka është siç thoni. Në nivelin e punës, kjo praktikë është e krahasueshme me çdo praktikë tjetër serioze që ndryshon kulturën. E gjithë vështirësia në tejkalimin ndodhet në zakonet, veçanërisht zakonet e këqija. Dhe nëse për të arritur këtë praktikë kërkohet një ndryshim i rëndësishëm i zakonit të atyre që ju rrethojnë: zhvilluesve, menaxhmentit, menaxherit të prodhimit, prisni befasi.
Cilat mund të jenë befasi? Le të themi, se vendosët që do të realizoni integrimin më shpesh. Dhe në integrimin tuaj është lidhur diçka tjetër, le të themi artefaktet. Dhe në kompaninë tuaj, për shembull, ka një politikë që çdo artefakt duhet të jetë në një mënyrë të regjistruar në një sistem ruajtjeje artefaktesh. Dhe kjo merr një sasi të caktuar kohe. Një njeri duhet të vërë një shenjë, që si menaxher i lëshimit e ka provuar këtë artefakt për gatishmëri për të kaluar në prodhim. Nëse kjo zgjat 5-10-15 minuta, por lidhur me këtë bëni një lëshim një herë në javë, atëherë një herë në javë të shpenzoni gjysmë ore, nuk është një tatim i madh.
Nëse bëni Continuous Integration 10 herë në ditë, atëherë 10 herë duhet të mnoheni me 30 minuta. Dhe kjo e kalon kohën e punës së këtij menaxheri të lëshimit. Ai thjesht lodhet të bëj këtë. Ka shpenzime të vazhdueshme për disa praktika. Dhe ashtu.
Dhe ju duhet ose të anuloni këtë rregull, që të mos merresh më me këtë gjë, dmth. nuk jepni manualisht nivelin e përputhshmërisë së diçkaje me diçka tjetër. Ju besoni plotësisht në një grup të automatizuar testesh gatishmërie.
Dhe nëse ju nevojitet ndonjë provë nga dikush, që kryesori të nënshkruajë, dhe ju nuk hyni në prodhim pa atë që Vasia tha se lejohet etj. – e gjithë kjo marrëzi ndalon praktikat. Sepse nëse ka aktivitete të lidhura si një tatim, atëherë gjithçka rritet në 100 herë. Pra, ndryshimi shpesh do të merret jo me gëzim nga të gjithë. Sepse është e vështirë të korrigjohen zakonet e njerëzve.
Kur një person bën një punë të zakonshme, ai e bën atë, praktikisht, pa menduar. Ngarkesa e tij kognitive është zero. Ai thjesht punon me të gatshmen, ai ka një listë kontrolli në kokë, e ka bërë këtë një mijë herë. Dhe sapo të vijë dhe i thoni: "Le të anulojmë këtë praktikë dhe nga e hëna të zbatojmë një të re", për të kjo bëhet një ngarkesë e madhe kognitive. Dhe kjo ndodh menjëherë për të gjithë.
Prandaj, mënyra më e thjeshtë, e vërteta, është se kjo luks nuk e lejojnë të gjithë, por unë gjithmonë e bëj kështu. Nëse nis një projekt të ri, zakonisht të gjitha praktikat e paprovuar futen menjëherë në këtë projekt. Ndërsa projekti është i ri, nuk rrezikojmë shumë. Prod nuk është ende aty, nuk ka asgjë që mund të prishet. Prandaj, mund ta përdorim si stërvitje. Ky qasje funksionon. Por nuk të gjitha kompanitë kanë mundësi ta nisin këtë lloj projektesh shpesh. Megjithatë, kjo është disi e çuditshme sepse tani ka një transformim të plotë digital, të gjithë duhet të fillojnë eksperimente për të mbetur në hap me konkurrentët.
Këtu e gjen veten para faktit se më parë duhet të kesh një kuptim të asaj që duhet të bësh. Bota nuk është ideale, as prodhimi nuk është ideal.
Po, këto gjëra janë të lidhura ngushtë.
Biznesi gjithashtu nuk ka gjithmonë një kuptim se duhet të shkojnë në këtë drejtim.
Ka një situatë ku asnjë ndryshim nuk është i mundur. Kjo është një situatë kur presioni mbi ekip është më i madh. Ekipi është tashmë mjaft i shteruar. Ai nuk ka asnjë kohë rezervë për eksperimente. Ata punojnë për të zhvilluar karakteristika nga mëngjesi deri në mbrëmje. Dhe drejtuesit kërkojnë gjithnjë e më shumë karakteristika. Në këtë situatë, asnjë ndryshim nuk është i mundur. Ekipit mund t'i thuhet vetëm se nesër do ta bëjmë ashtu si dje, duhet vetëm të bëjmë pak më shumë karakteristika. Asnjë kalim në asnjë praktikë në këtë sens nuk është i mundur. Kjo është një situatë klasike, kur nuk ka kohë për të sharpen the axe, duhet prerë pemët, prandaj prehen me një aks të mprehtë. Këtu nuk ka këshilla të thjeshta.
(Dmitri) Unë do të lexoj një sqarim nga biseda: "Por nevojitet një mbulim i madh me teste në nivele të ndryshme. Sa kohë i kushtohet testeve? Duket disi e shtrenjtë, merr shumë kohë."
(Oleg) Kjo është një keqkuptim klasik. Duhet të keni mjaft teste në mënyrë që të keni vetëbesim. Continuous Integration nuk është një gjë ku së pari bëni 100% teste dhe vetëm pastaj filloni ta aplikoni këtë praktikë. Continuous Integration e ul barrën kognitive mbi ju, sepse çdo ndryshim që shihni me sy është aq i qartë sa që kuptoni nëse do të dështojë diçka apo jo, edhe pa teste. Ju mund ta testoni shpejt në mendje, sepse ndryshimet janë të vogla. Edhe nëse keni vetëm testues manualë, atyre gjithashtu u lehtësohet. Ju e keni lançuar dhe thoni: "Shiko, a ka ndodhur ndonjë dështim?" Ata kontrollojnë dhe thonë: "Jo, nuk ka ndodhur asgjë." Sepse testuesi e di se ku të shikojë. Keni një commit të lidhur me një fragment të vetëm kodit. Dhe kjo eksploitohet me një sjellje konkrete.
Këtu, sigurisht, e ke zbukuruar disi.
(Dmitry) Këtu nuk jam dakord. Ekziston praktika – zhvillimi përmes testimit, e cila pikërisht do t'ju shpëtojë nga kjo.
(Oleg) Këtë nuk e kam arritur akoma. Iluzioni i parë është se duhet të shkruani pikërisht 100% teste ose nuk duhet fare ta praktikoni Continuous Integration. Kjo është e pavërtetë. Këto janë dy praktika paralele. Dhe ato nuk varen drejtpërdrejt njëra nga tjetra. Mbulesa juaj me teste duhet të jetë optimale. Optimumi do të thotë që jeni të sigurt se cilësia e masterit, në të cilin ka mbetur pas commit-it tuaj, ju lejon të klikoni me besim butonin “Deploy” të premten në mbrëmje, kur jeni duke pirë. Si e arrini këtë? Nëpërmjet rishikimeve, mbulesës, nëpërmjet monitorimit të mirë.
Monitorimi i mirë – nuk është i dallueshëm nga testet. Nëse ju i ekzekutoni testet një herë në pre prod, ato kontrollojnë një herë të gjitha skenarët tuaj të përdoruesit dhe asgjë më shumë. Por nëse i ekzekutoni ato në një cikël të pafund, atëherë ky është sistemi juaj i zgjeruar i monitorimit, i cili e teston gjithçka në mënyrë të pafund – ka rënë apo nuk ka rënë. Në këtë rast, ndryshimi është vetëm në një herë ose në shumë herë. Një set i shkëlqyer testesh ... të ekzekutuara pafundësisht, janë monitorim. Dhe monitorimi i duhur duhet të jetë kështu.
Dhe prandaj, si do ta arrini këtë gjendje, kur të bëni deploy të premten në mbrëmje dhe të largoheni për në shtëpi, është një çështje tjetër. Mund të jeni thjesht një i guximshëm i çmendur.
Le të kthehemi pak pas te Integrimi i Vazhdueshëm. Ne u shpërngulëm në një praktikë tjetër të komplikuar.
Iluzione të dyta janë se MVP, thonë, duhet të bëhet shpejt, prandaj testet nuk janë të nevojshme. Nuk është gjithmonë kështu. E vërteta është se kur shkruani një tregim përdoruesi për MVP, mund ta zhvilloni atë në mënyrë të lirë, dmth, e dëgjuat që ekziston një tregim përdoruesi dhe menjëherë u nxitët ta kodoni, ose të punoni sipas TDD. Në praktikën TDD, siç tregon përvoja, nuk merr më shumë kohë, dmth testet janë një efekt anësor. Praktika TDD nuk ka të bëjë vetëm me testimin. Pavarësisht se quhet Zhvillim i Drejtuar nga Testet, aty nuk flitet për testet. Kjo është një qasje arkitektonike më shumë. Është një mënyrë se si të shkruani pikërisht atë që nevojitet dhe të mos shkruani atë që nuk nevojitet. Kjo praktikë fokusohet në iteracionin tuaj të ardhshëm të zhvillimit të mendjes në lidhje me ndërtimin e arkitekturës së aplikacionit.
Prandaj, nuk është kaq e lehtë të lirohemi nga këto iluzione. MVP dhe testet nuk janë në kundërshtim me njëra-tjetrën. Më shumë, në fakt, nëse bëni MVP sipas praktikës TDD, do ta bëni atë më mirë dhe më shpejt sesa nëse e bëni krejtësisht lirisht, pa praktikë.
Kjo është një mendim shumë i paqartë dhe i komplikuar. Kur dëgoni që tani do të shkruani edhe teste dhe për këtë arsye do të bëni diçka më shpejt, tingëllon krejtësisht e pabesueshme.
(Dmitri) Këtu shumë, kur përmendin MVP, e bëjnë atë sepse janë lenë të shkruajnë diçka normale. Dhe kjo është ende gjëra të ndryshme. Mos e shndërroni MVP në diçka të keqe që nuk funksionon.
Po, po, ke të drejtë.
Dhe pastaj papritur MVP në prodhim.
Përherë.
TDD tingëllon shumë e pazakontë, kur dëgjon që po shkruan teste dhe duket se po bën më shumë punë. Kjo tingëllon shumë e çuditshme, por në të vërtetë kjo ndihmon që të bësh gjërat më shpejt dhe më bukur. Kur shkruan një test, tashmë mendon shumë për atë se çfarë kodi do të jetë dhe si do të thirret, si dhe sjelljen që presim prej tij. Nuk thua thjesht që kam shkruar një funksion dhe ai bën diçka. Së pari mendon se ka këto kushte dhe do të thirret në këtë mënyrë. Këtë e mbulon me teste dhe prej kësaj kupton si do të duken ndërfaqet brenda kodit tënd. Kjo ndikon shumë në arkitekturë. Kodi yt automatikisht bëhet më modular, sepse së pari përpiqesh të kuptosh si do ta testosh, dhe pastaj e shkruan.
Kisha ime ndodhur me TDD që në një moment unë kam marrë një mentor për Ruby, kur ende isha programues në Ruby. Ai tha: "Le t'i bëjmë gjërat sipas TDD." Dhe unë mendoja: "Oj, tani do të shkruaj diçka shtesë." Ne u dakorduam që për dy javë të shkruaja të gjithë kodin funksional në Python duke përdorur TDD. Pas dy javësh kuptova se nuk doja të kthehesha mbrapsht. Pas dy javësh duke u përpjekur ta aplikoj kudo, kuptova sa më e lehtë ishte të mendosh. Por kjo nuk është e dukshme, prandaj e rekomandoj të gjithëve, nëse keni ndjesinë se TDD është e vështirë, e gjatë dhe e panevojshme, provoni ta mbani për dy javë. Mua më mjaftoi dy javë për këtë.
(Dmitrij) Ne mund ta zhvillojmë këtë mendim nga pikëpamja e funksionimit të infrastrukturës. Para se të lancojmë diçka të re, ne bëjmë monitoring dhe pastaj e lançojmë. Në këtë rast, monitorimi ynë bëhet një testim i zakonshëm. Edhe zhvillimi përmes monitoring-ut. Por pothuajse të gjithë thonë se është e gjatë, më lenë, kam bërë një skicë të përkohshme. Nëse e kemi bërë monitoring-un siç duhet, kuptojmë gjendjen e sistemit CI. Në sistemin CI ka shumë monitorim. Ne kuptojmë gjendjen e sistemit, kuptojmë çfarë ka brenda. Dhe gjatë zhvillimit ne pikërisht krijojmë sistemin që ta sjellim në gjendjen e dëshiruar.
Këto praktika janë të njohura prej kohësh. Ne e kemi diskutuar këtë rreth 4 vjet më parë. Por për 4 vjet praktikisht nuk ka ndryshuar asgjë.
Por në këtë notë propozoj të mbyllim diskutimin zyrtar.
Video (e futur si element media, por pse nuk funksionon):
Burimi: habr.com
