Le të diskutojmë pse mjetet CI dhe CI janë gjëra krejtësisht të ndryshme.
Çfarë dhimbjeje synon të zgjidhë CI, nga lindi ideja, cilat janë konfirmimet e fundit që funksionon, si të kuptosh që ke një praktikë dhe jo thjesht të instaluar Jenkins.
Ideja për të bërë një raport për Integrimin e Vazhdueshëm lindi një vit më parë, kur shkoja për intervista dhe kërkoja punë. Unë fola me 10-15 kompani, vetëm njëra prej tyre ishte në gjendje të përgjigjej qartë se çfarë është CI dhe të shpjegojë se si e kuptuan se nuk e kishin atë. Pjesa tjetër po flisnin marrëzi të pakuptueshme për Jenkins :) Epo, ne kemi Jenkins, ajo ndërton, CI! Gjatë raportit, do të përpiqem të shpjegoj se çfarë është në të vërtetë Integrimi i vazhdueshëm dhe pse Jenkins dhe mjete të ngjashme kanë një marrëdhënie shumë të dobët me këtë.
Pra, çfarë ju vjen zakonisht në mendje kur dëgjoni fjalën CI? Shumica e njerëzve do të mendojnë për Jenkins, Gitlab CI, Travis, etj.
Edhe nëse e kërkojmë në google, do të na japë këto mjete.
Nëse jeni të njohur me pyetjen, atëherë menjëherë pas renditjes së mjeteve, ata do t'ju thonë se CI është kur ndërtoni dhe kryeni teste në një Kërkesë tërheqjeje për një kryerje.
Integrimi i vazhdueshëm nuk ka të bëjë me mjete, jo me asamble me teste në një degë! Integrimi i vazhdueshëm është praktikë e integrimit shumë të shpeshtë të kodit të ri dhe për ta përdorur atë nuk është aspak e nevojshme të rrethohen Jenkins, GitLab, etj.
Përpara se të kuptojmë se si duket një CI i plotë, le të zhytemi së pari në kontekstin e njerëzve që e krijuan atë dhe të ndjejmë dhimbjen që po përpiqeshin të zgjidhnin.
Dhe ata zgjidhën dhimbjen e punës së bashku si ekip!
Le të shohim shembuj të vështirësive me të cilat përballen zhvilluesit kur zhvillohen në ekipe. Këtu kemi një projekt, një degë master në git dhe dy zhvillues.
Dhe ata shkuan në punë siç ishin mësuar të gjithë prej kohësh. Ne morëm një detyrë në skemën e madhe të gjërave, krijuam një degë tipare dhe shkruam kodin.
Njëri e përfundoi funksionin më shpejt dhe e bashkoi atë në master.
E dyta kishte nevojë për më shumë kohë, u shkri më vonë dhe përfundoi me një konflikt. Tani, në vend që të shkruajë veçoritë që i duhen biznesit, zhvilluesi shpenzon kohën dhe energjinë e tij për zgjidhjen e konflikteve.
Sa më e vështirë të jetë të kombinosh veçorinë tënde me një master të përbashkët, aq më shumë kohë kalojmë në të. Dhe këtë e tregova me një shembull mjaft të thjeshtë. Ky është një shembull ku ka vetëm 2 zhvillues.Imagjinoni sikur 10 ose 15 ose 100 njerëz në një kompani të shkruajnë në një depo. Do të çmendeni për të zgjidhur të gjitha këto konflikte.
Ka një rast pak më ndryshe. Ne kemi një master dhe disa zhvillues që bëjnë diçka.
Ata krijuan një degëz.
Njëri vdiq, gjithçka ishte në rregull, ai e kaloi detyrën.
Ndërkaq, zhvilluesi i dytë e dorëzoi detyrën e tij. Le të themi se ai e dërgoi atë për shqyrtim. Shumë kompani kanë një praktikë të quajtur rishikim. Nga njëra anë, kjo praktikë është e mirë dhe e dobishme, nga ana tjetër, na ngadalëson në shumë mënyra. Ne nuk do të hyjmë në këtë, por këtu është një shembull i shkëlqyer se çfarë mund të çojë një histori e keqe e rishikimit. Ju keni paraqitur një kërkesë tërheqjeje për shqyrtim. Nuk ka asgjë më shumë për të bërë zhvilluesi. Çfarë fillon të bëjë? Ai fillon të marrë përsipër detyra të tjera.
Gjatë kësaj kohe, zhvilluesi i dytë bëri diçka tjetër.
I pari përfundoi detyrën e tretë.
Dhe pas një kohe të gjatë, rishikimi i tij u testua dhe ai po përpiqet të pajtohet. Pra, çfarë po ndodh? Ajo kap një numër të madh konfliktesh. Pse? Sepse ndërsa kërkesa e tij për tërheqje ishte e varur në rishikim, shumë gjëra kishin ndryshuar tashmë në kod.
Përveç historisë me konflikte, ka një histori me komunikime. Ndërsa filli juaj është i varur në rishikim, ndërsa pret diçka, ndërsa jeni duke punuar në një veçori për një kohë të gjatë, ju ndaloni së gjurmuari se çfarë tjetër po ndryshon në bazën e kodit të shërbimit tuaj. Ndoshta ajo që po përpiqeni të zgjidhni tani është zgjidhur tashmë dje dhe mund të përdorni ndonjë metodë dhe ta ripërdorni atë. Por ju nuk do ta shihni këtë sepse jeni gjithmonë duke punuar me një degë të vjetëruar. Dhe kjo degë e vjetëruar gjithmonë rezulton që ju duhet të zgjidhni një konflikt bashkimi.
Rezulton se nëse punojmë si një ekip, d.m.th., jo një person po troket në depo, por 5-10 persona, atëherë sa më gjatë të mos ia shtojmë kodin masterit, aq më shumë vuajmë sepse në fund na duhet diçka pastaj bashkoje atë. Dhe sa më shumë konflikte të kemi, dhe versioni më i vjetër me të cilin punojmë, aq më shumë probleme kemi.
Të bësh diçka së bashku është e dhimbshme! Ne gjithmonë i pengojmë njëri-tjetrit.
Ky problem është vërejtur më shumë se 20 vjet më parë. Gjeta përmendjen e parë të praktikës së Integrimit të Vazhdueshëm në Programimin Ekstrem.
Programimi ekstrem është korniza e parë e shkathët. Faqja u shfaq në 96. Dhe ideja ishte që të përdornim një lloj praktike programimi, planifikimi dhe gjëra të tjera, në mënyrë që zhvillimi të ishte sa më fleksibël, në mënyrë që të mund t'i përgjigjemi shpejt çdo ndryshimi apo kërkese nga klientët tanë. Dhe ata filluan të përballen me këtë 24 vjet më parë, që nëse bën diçka për një kohë shumë të gjatë dhe mënjanë, atëherë shpenzon më shumë kohë për të sepse ke konflikte.
Tani do të analizojmë individualisht shprehjen “Integrim i vazhdueshëm”. Nëse e përkthejmë drejtpërdrejt, marrim integrim të vazhdueshëm. Por sa e vazhdueshme është nuk është shumë e qartë; është shumë e ndërprerë. Por se sa integrim ka ai nuk është gjithashtu shumë e qartë.
Dhe kjo është arsyeja pse unë po ju jap citate nga Extreme Programming tani. Dhe ne do t'i analizojmë të dyja fjalët veç e veç.
Integrimi - Siç e thashë tashmë, ne përpiqemi të sigurojmë që çdo inxhinier të punojë me versionin më aktual të kodit, në mënyrë që ai të përpiqet të shtojë kodin e tij sa më shpesh të jetë e mundur në një degë të përbashkët, në mënyrë që këto të jenë degë të vogla. Sepse nëse ato janë të mëdha, atëherë mund të ngecim lehtësisht me konfliktet e bashkimit për një javë. Kjo është veçanërisht e vërtetë nëse kemi një cikël të gjatë zhvillimi si ujëvarë, ku zhvilluesi u largua për një muaj për të prerë një veçori të madhe. Dhe ai do të mbetet i mbërthyer në fazën e integrimit për një kohë shumë të gjatë.
Integrimi është kur marrim degën tonë dhe e integrojmë me masterin, e bashkojmë. Ekziston një opsion përfundimtar kur jemi një zhvillues transbaze, ku ne përpiqemi të sigurojmë që t'i shkruajmë menjëherë masterit pa ndonjë degë shtesë.
Në përgjithësi, integrim do të thotë të marrësh kodin tënd dhe ta tërhiqësh atë në master.
Çfarë nënkuptohet këtu me fjalën "i vazhdueshëm", çfarë quhet vazhdimësi? Praktika nënkupton që zhvilluesi përpiqet të integrojë kodin e tij sa më shpejt që të jetë e mundur. Ky është qëllimi i tij kur kryen çdo detyrë - të marrë kodin e tij në master sa më shpejt të jetë e mundur. Në një botë ideale, zhvilluesit do ta bënin këtë çdo disa orë. Kjo do të thotë, ju merrni një problem të vogël dhe e bashkoni atë në master. Gjithçka është e mrekullueshme. Kjo është ajo për të cilën ju përpiqeni. Dhe kjo duhet bërë vazhdimisht. Sapo bëni diçka, e futni menjëherë te mjeshtri.
Dhe zhvilluesi që bën diçka është përgjegjës për atë që ka bërë për ta bërë atë të funksionojë dhe të mos prishë asgjë. Këtu zakonisht del historia e testit. Ne duam të kryejmë disa teste në angazhimin tonë, në bashkimin tonë, për t'u siguruar që funksionon. Dhe këtu mund t'ju ndihmojë Jenkins.
Por me histori: le t'i bëjmë ndryshimet të vogla, le t'i lëmë detyrat të jenë të vogla, le të krijojmë një problem dhe menjëherë të përpiqemi ta fusim disi në master - asnjë Jenkins nuk do të ndihmojë këtu. Sepse Jenkins do t'ju ndihmojë vetëm të kryeni teste.
Ju mund të bëni pa to. Kjo nuk do t'ju dëmtojë aspak. Sepse qëllimi i praktikës është të matet sa më shpesh që të jetë e mundur, në mënyrë që të mos humbet një sasi e madhe kohe për ndonjë konflikt në të ardhmen.
Le të imagjinojmë që për disa arsye jemi në vitin 2020 pa internet. Dhe ne punojmë në vend. Ne nuk kemi Jenkins. Kjo është mirë. Ju ende mund të vazhdoni dhe të bëni një degë lokale. Ju keni shkruar një kod në të. Detyrën e përfunduam në 3-4 orë. Ne kaluam në master, bëmë një tërheqje git dhe shkrimë degën tonë atje. Gati. Nëse e bëni këtë shpesh, urime, ju keni Integrim të Vazhdueshëm!
Çfarë dëshmie ka në botën moderne që ia vlen të shpenzoni energji? Sepse në përgjithësi është e vështirë. Nëse përpiqeni të punoni kështu, do të kuptoni se tani do të ndikohen disa planifikime, do t'ju duhet t'i kushtoni më shumë kohë detyrave të zbërthimit. Sepse nëse bëni burrë..., atëherë nuk do të arrini të pajtoheni shpejt dhe, në përputhje me rrethanat, do të futeni në telashe. Nuk do të keni më praktikë.
Dhe do të jetë e shtrenjtë. Nuk do të jetë e mundur të punohet menjëherë nga nesër duke përdorur Integrimin e Vazhdueshëm. Do t'ju duhet shumë kohë të gjithëve për t'u mësuar me të, do t'ju duhet shumë kohë për t'u mësuar me zbërthimin e detyrave, do t'ju duhet shumë kohë për t'u mësuar me ribërjen e praktikës së rishikimit, nëse keni një të tillë. . Sepse synimi ynë është që ajo të shkrihet sot. Dhe nëse bëni një rishikim brenda tre ditëve, atëherë keni probleme dhe Integrimi i vazhdueshëm nuk po funksionon për ju.
Por a kemi ndonjë provë relevante tani që na tregon se investimi në këtë praktikë ka kuptim?
Gjëja e parë që më erdhi në mendje ishte Gjendja e DevOps. Ky është një studim që djemtë e kanë bërë prej 7 vitesh. Tani ata e bëjnë këtë si një organizatë e pavarur, por nën Google.
Dhe studimi i tyre i vitit 2018 tregoi një korrelacion midis kompanive që përpiqen të përdorin degë jetëshkurtër që integrohen shpejt, integrohen shpesh dhe kanë tregues më të mirë të performancës së IT.
Cilët janë këta tregues? Këto janë 4 metrikë që ata marrin nga të gjitha kompanitë në pyetësorët e tyre: frekuenca e vendosjes, koha e drejtimit për ndryshime, koha për të rivendosur shërbimin, ndryshimi i shkallës së dështimit.
Dhe, së pari, ekziston ky korrelacion, ne e dimë se kompanitë që matin shpesh kanë metrikë shumë më të mirë. Dhe ato kanë një ndarje të kompanive në disa kategori: këto janë kompani të ngadalta që prodhojnë diçka ngadalë, me performancë mesatare, me performancë të lartë dhe elitë. Elita janë Netflix, Amazon, të cilat janë super të shpejta, bëjnë gjithçka shpejt, bukur dhe me efikasitet.
Historia e dytë, e cila ndodhi vetëm një muaj më parë. Teknologjia Radar ka një artikull të shkëlqyeshëm rreth Gitflow. Gitflow është i ndryshëm nga të gjithë të tjerët në atë që degët e tij janë jetëgjatë. Ka degë të lëshimit që jetojnë për një kohë të gjatë, dhe me degë që jetojnë gjithashtu për një kohë të gjatë. Kjo praktikë në Technology Radar është zhvendosur në HOLD. Pse? Sepse njerëzit përballen me dhimbjen e integrimit.
Nëse dega juaj jeton për një kohë shumë të gjatë, ajo ngec, kalbet dhe ne fillojmë të shpenzojmë më shumë kohë duke u përpjekur të bëjmë një lloj ndryshimi në të.
Dhe së fundmi autori i Gitflow tha se nëse qëllimi juaj është Integrimi i Vazhdueshëm, nëse qëllimi juaj është që dëshironi të rrotulloheni sa më shpesh të jetë e mundur, atëherë Gitflow është një ide e keqe. Ai veçmas shtoi në artikull se nëse keni një backend ku mund të përpiqeni për këtë, atëherë Gitflow është i tepërt për ju, sepse Gitflow do t'ju ngadalësojë, Gitflow do t'ju krijojë probleme me integrimin.
Kjo nuk do të thotë që Gitflow është i keq dhe nuk duhet të përdoret. Është për raste të tjera. Për shembull, kur ju duhet të mbështesni disa versione të një shërbimi ose aplikacioni, d.m.th. kur keni nevojë për mbështetje për një periudhë të gjatë kohore.
Por nëse flisni me njerëz që mbështesin shërbime të tilla, do të dëgjoni shumë dhimbje për faktin se ky version ishte 3.2, që ishte 4 muaj më parë, por ky rregullim nuk ishte përfshirë në të dhe tani, për ta bërë atë, ju duhet të bëni një sërë ndryshimesh. Dhe tani ata janë ngecur përsëri, dhe tani ata janë duke u përpjekur për një javë duke u përpjekur të zbatojnë një veçori të re.
Siç vuri në dukje saktë Alexander Kovalev në bisedë, korrelacioni nuk është i njëjtë me shkakun. Kjo eshte e vertetë. Kjo do të thotë, nuk ka asnjë lidhje të drejtpërdrejtë që nëse keni Integrim të vazhdueshëm, atëherë të gjitha metrikat do të jenë të shkëlqyera. Por ka një korrelacion pozitiv që nëse njëra është një, atëherë ka shumë të ngjarë edhe tjetra. Jo një fakt, por ka shumë të ngjarë. Është thjesht një korrelacion.
Duket se tashmë po bëjmë diçka, duket se tashmë po shkrihemi, por si mund ta kuptojmë që kemi ende Integrim të Vazhdueshëm, që po shkrihemi mjaft shpesh?
Jez Humble është autori i Handbook, Accelerate, uebsajti i dorëzimit të vazhdueshëm dhe librit Continuous Delivery. Ai ofron këtë test:
- Kodi i inxhinierit i shkon mjeshtrit çdo ditë.
- Për çdo angazhim që kryeni testet e njësisë.
- Ndërtimi në master ra, u rregullua për rreth 10 minuta.
Ai sugjeron të përdorni një test si ky për t'u siguruar që keni praktikë të mjaftueshme.
Kjo e fundit më duket pak e diskutueshme. Domethënë, nëse mund ta rregulloni për 10 minuta, atëherë keni Integrim të vazhdueshëm, tingëllon pak e çuditshme, për mendimin tim, por ka kuptim. Pse? Sepse nëse ngrini shpesh, do të thotë që ndryshimet tuaja janë të vogla. Nëse një ndryshim i vogël do të thotë se ndërtimi juaj kryesor është i prishur, atëherë mund të gjeni një shembull shpejt sepse ndryshimi është i vogël. Këtu keni pasur një bashkim të vogël, 20-30 rreshta në të kanë ndryshuar. Dhe, në përputhje me rrethanat, mund të kuptoni shpejt se cila ishte arsyeja, sepse ndryshimet janë të vogla, ju keni një zonë shumë të vogël për të kërkuar problemin.
Dhe edhe nëse produkti ynë ndahet pas lëshimit, atëherë nëse kemi praktikën e Integrimit të Vazhdueshëm, është shumë më e lehtë për ne të veprojmë, sepse ndryshimet janë të vogla. Po, kjo do të ndikojë në planifikim. Kjo do të dëmtojë. Dhe, ndoshta, gjëja më e vështirë në këtë praktikë është të mësoheni me zbërthimin e detyrave, domethënë si ta bëni atë në mënyrë që të merrni diçka dhe ta bëni atë brenda disa orësh dhe në të njëjtën kohë të kaloni një rishikim, nëse ju keni një. Rishikimi është një dhimbje më vete.
Testet e njësisë janë thjesht një asistent që ju ndihmon të kuptoni nëse integrimi juaj ishte i suksesshëm dhe nëse asgjë nuk u prish. Për mendimin tim, kjo nuk është gjithashtu plotësisht e detyrueshme, sepse kjo nuk është pika e praktikës.
Kjo është një hyrje e shkurtër e Integrimit të Vazhdueshëm. Kjo është gjithçka që ka për këtë praktikë. Unë jam gati për pyetje.
Unë vetëm do të përmbledh shkurtimisht përsëri:
- Integrimi i vazhdueshëm nuk është Jenkins, nuk është Gitlab.
- Ky nuk është një mjet, është një praktikë që ne bashkojmë kodin tonë në master sa më shpesh të jetë e mundur.
- Ne e bëjmë këtë për të shmangur dhimbjen e madhe që lind nga bashkimet në të ardhmen, domethënë, ne përjetojmë pak dhimbje tani për të mos përjetuar më shumë në të ardhmen. Kjo është e gjithë çështja.
- Nga ana tjetër ka komunikim përmes kodit, por unë shumë rrallë e shoh këtë, por kjo është edhe ajo për të cilën është krijuar.
Pyetjet tuaja
Çfarë duhet të bëni me detyrat jo të dekompozuara?
Zbërthehet. Cili është problemi? A mund të jepni një shembull që ka një detyrë dhe nuk zbërthehet?
Ka detyra që nuk mund të zbërthehen nga fjala "plotësisht", për shembull, ato që kërkojnë ekspertizë shumë të thellë dhe që në fakt mund të zgjidhen brenda një muaji për të arritur një rezultat të tretshëm.
Nëse ju kuptoj saktë, atëherë ka një detyrë të madhe dhe komplekse, rezultati i së cilës do të jetë i dukshëm vetëm brenda një muaji?
Po ashtu eshte. Po, do të jetë e mundur të vlerësohet rezultati jo më herët se në një muaj.
Mirë. Në përgjithësi, ky nuk është problem. Pse? Sepse në këtë rast kur flasim për thupra, nuk po flasim për një thupër me veçori. Karakteristikat mund të jenë të mëdha dhe komplekse. Ato mund të ndikojnë në një numër të madh komponentësh. Dhe ndoshta ne nuk mund t'i bëjmë ato plotësisht në një degë. Kjo është mirë. Ne vetëm duhet ta zbërthejmë këtë histori. Nëse një veçori nuk është plotësisht gati, kjo nuk do të thotë se disa pjesë të kodit të tij nuk mund të bashkohen. Ju keni shtuar, le të themi, migrimin dhe ka disa faza brenda veçorisë. Le të themi se keni një fazë - bëni një migrim, shtoni një metodë të re. Dhe ju tashmë mund t'i matni këto gjëra çdo ditë.
Mirë. Çfarë kuptimi ka atëherë?
Çfarë kuptimi ka të vrasësh gjëra të vogla çdo ditë?
Po.
Nëse ata thyejnë diçka, ju e shihni atë menjëherë. Ju keni një copë të vogël që ka thyer diçka, është më e lehtë për ju ta rregulloni atë. Çështja është se bashkimi i një pjese të vogël tani është shumë më i lehtë sesa bashkimi i diçkaje të madhe brenda disa javësh. Dhe pika e tretë është se inxhinierët e tjerë do të punojnë me versionin aktual të kodit. Ata do të shohin se disa migrime janë shtuar këtu dhe më pas është shfaqur një metodë që mund të dëshirojnë ta përdorin gjithashtu. Të gjithë do të shohin se çfarë po ndodh në kodin tuaj. Pikërisht për këto tre gjëra bëhet praktika.
Faleminderit, çështja është mbyllur!
(Oleg Soroka) Mund të shtoj? Ke thënë gjithçka saktë, dua të shtoj vetëm një frazë.
So.
Me Integrimin e Vazhdueshëm, kodi shkrihet në një degë të përbashkët jo kur veçoria është plotësisht gati, por kur ndërtimi ndalon së thyeri. Dhe ju mund të angazhoheni në mënyrë të sigurt për të zotëruar sa herë në ditë dëshironi. Aspekti i dytë është se nëse për ndonjë arsye nuk mund ta ndash detyrën mujore në detyra për të paktën tre ditë, unë hesht rreth tre orë, atëherë ke një problem të madh. Dhe fakti që nuk keni Integrim të Vazhdueshëm është problemi më i vogël. Kjo do të thotë që ju keni probleme me arkitekturën dhe zero praktikat inxhinierike. Sepse edhe nëse ky është hulumtim, atëherë në çdo rast duhet formuluar në formë hipotezash ose cikli.
Ne folëm për 4 metrika që dallojnë kompanitë e suksesshme nga ato të mbetura. Ne ende duhet të jetojmë për të parë këto 4 metrika. Nëse detyra juaj mesatare kërkon një muaj për t'u përfunduar, atëherë unë do të fokusohesha në këtë metrikë së pari. Së pari do ta ulja në 3 ditë. Dhe pas kësaj fillova të mendoj për Continuous.
A ju kuptova drejt që mendoni se në përgjithësi nuk ka kuptim të investoni në praktikat inxhinierike nëse çdo detyrë kërkon një muaj për të përfunduar?
Ju keni Integrim të Vazhdueshëm. Dhe ka një temë të tillë që në 10 minuta ose mund ta rregulloni një rregullim ose ta ktheni përsëri. Imagjinoni që e keni nxjerrë. Për më tepër, ju madje keni vendosje të vazhdueshme, e keni nxjerrë për ta nxitur dhe vetëm atëherë keni vënë re se diçka nuk shkoi mirë. Dhe ju duhet ta ktheni atë, por ju tashmë keni migruar bazën e të dhënave tuaja. Ju tashmë keni skemën e bazës së të dhënave të versionit tjetër, për më tepër, keni pasur edhe një lloj rezervë, dhe të dhënat janë shkruar gjithashtu atje.
Dhe çfarë alternativë keni? Nëse e ktheni përsëri kodin, atëherë ai nuk mund të funksionojë më me këtë bazë të dhënash të përditësuar.
Baza vetëm lëviz përpara, po.
Njerëzit që kanë praktika të dobëta inxhinierike me shumë mundësi nuk e kanë lexuar as librin e trashë rreth... Çfarë duhet të bëni me kopjen rezervë? Nëse rikuperoni nga një kopje rezervë, do të thotë se humbni të dhënat që keni grumbulluar gjatë atij momenti. Për shembull, ne kemi punuar për tre orë me versionin e ri të bazës së të dhënave, përdoruesit e regjistruar atje. Ju refuzoni kopjen rezervë të vjetër sepse skema nuk funksionon me versionin e ri, kështu që i keni humbur këta përdorues. Dhe ata janë të pakënaqur, betohen.
Për të zotëruar gamën e plotë të praktikave që mbështesin Integrimin e Vazhdueshëm dhe Ofrimin e Vazhdueshëm, nuk mjafton vetëm të mësoni se si të shkruani.... Së pari, mund të ketë shumë prej tyre, do të jetë jopraktike. Plus ka një mori praktikash të tjera si Shkencore. Ekziston një praktikë e tillë, GitHub e popullarizoi atë në një kohë. Kjo është kur ju keni kodin e vjetër dhe kodin e ri të ekzekutuar në të njëjtën kohë. Kjo ndodh kur krijoni një veçori të papërfunduar, por ai mund të kthejë një vlerë: ose si funksion ose si një API Rest. Ju ekzekutoni kodin e ri dhe kodin e vjetër dhe krahasoni ndryshimin midis tyre. Dhe nëse ka një ndryshim, atëherë ju regjistroni këtë ngjarje. Në këtë mënyrë ju e dini se keni një veçori të re gati për t'u futur në krye të atij të vjetër nëse nuk keni pasur një mospërputhje midis të dyve për një kohë të caktuar.
Ka qindra praktika të tilla. Unë do të sugjeroja të filloni me zhvillimin transbazë. Ajo nuk është 100% për Integrimin e Vazhdueshëm, por praktikat janë të njëjta, nuk mund të jetojë mirë njëri pa tjetrin.
A e dhatë zhvillimin transbazë si shembull ku mund të shihni praktikat apo u sugjeroni njerëzve të fillojnë të përdorin zbërthimin e bazës?
Hidhini një sy, sepse ata nuk do të mund ta përdorin atë. Për t'i përdorur ato, duhet të lexoni shumë. Dhe kur një person pyet: "Çfarë të bëjë me një veçori që kërkon një muaj, do të thotë që ai nuk ka lexuar për zhvillimin e transbazës." Unë nuk do ta rekomandoja ende. Unë do të këshilloja të përqendrohesha vetëm në temën se si të zbërthehen në mënyrë korrekte arkitektonike detyrat e mëdha në ato më të vogla. Ky është thelbi i dekompozimit.
Dekompozimi është një nga mjetet e arkitektit. Së pari bëjmë analizën, pastaj zbërthimin, pastaj sintezën, pastaj integrimin. Dhe kështu funksionon gjithçka për ne. Dhe ne ende duhet të rritemi drejt Integrimit të Vazhdueshëm përmes dekompozimit. Pyetjet lindin në fazën e parë dhe tashmë po flasim për fazën e katërt, pra sa më shpesh të bëjmë integrim, aq më mirë. Është ende shumë herët për ta bërë këtë; do të ishte mirë që fillimisht të shkurtoni monolitin tuaj.
Ju duhet të vizatoni një numër shigjetash dhe katrorësh në një diagram. Nuk mund të thuash që tani do të tregoj diagramin arkitekturor të një aplikacioni të ri dhe do të tregoj një katror, brenda të cilit ka një buton jeshil për aplikacionin. Në çdo rast, do të ketë më shumë sheshe dhe shigjeta. Çdo diagram që pashë kishte më shumë se një. Dhe zbërthimi, edhe në nivelin e paraqitjes grafike, tashmë po ndodh. Prandaj, sheshet mund të bëhen të pavarura. Nëse jo, atëherë kam pyetje të mëdha për arkitektin.
Ekziston një pyetje nga biseda: "Nëse një rishikim është i detyrueshëm dhe kërkon shumë kohë, ndoshta një ditë ose më shumë?"
Ju keni probleme me praktikën. Rishikimi nuk duhet të zgjasë një ditë ose më shumë. Kjo është e njëjta histori me pyetjen e mëparshme, vetëm pak më e butë. Nëse një rishikim vazhdon për një ditë, atëherë ka shumë të ngjarë që ky rishikim do të ketë një ndryshim shumë të madh. Kjo do të thotë që ajo duhet të bëhet më e vogël. Në zhvillimin transbazë, të cilin Oleg rekomandoi, ekziston një histori e quajtur rishikim i vazhdueshëm. Ideja e saj është që ne të bëjmë një kërkesë kaq të vogël tërheqjeje me qëllim, sepse ne përpiqemi të bashkohemi vazhdimisht dhe nga pak. Dhe kështu kërkesa për tërheqje ndryshon një abstraksion ose 10 rreshta. Falë këtij rishikimi, na duhen disa minuta.
Nëse rishikimi zgjat një ditë ose më shumë, diçka nuk është në rregull. Së pari, mund të keni disa probleme me arkitekturën. Ose kjo është një pjesë e madhe e kodit, 1 rreshta, për shembull. Ose arkitektura juaj është aq komplekse sa një person nuk mund ta kuptojë atë. Ky është një problem paksa anash, por gjithashtu do të duhet të zgjidhet. Ndoshta nuk ka nevojë fare për një rishikim. Duhet të mendojmë edhe për këtë. Rishikimi është gjëja që ju ngadalëson. Ka avantazhet e veta në përgjithësi, por ju duhet të kuptoni pse po e bëni. A është kjo një mënyrë për ju për të përcjellë shpejt informacionin, a është kjo një mënyrë për ju për të vendosur disa standarde brenda apo çfarë? Pse ju duhet kjo? Sepse rishikimi duhet të bëhet ose shumë shpejt ose të anulohet fare. Është si zhvillimi transbazë - historia është shumë e bukur, por vetëm për djemtë e pjekur.
Lidhur me 4 metrikat, unë do të rekomandoja gjithsesi t'i hiqni ato për të kuptuar se në çfarë çon kjo. Shikoni numrat, shikoni foton, sa e keqe është gjithçka.
(Dmitri) Unë jam gati të hyj në një diskutim për këtë me ju. Numrat dhe metrikat janë të gjitha të shkëlqyera, praktikat janë të shkëlqyera. Por ju duhet të kuptoni nëse biznesi ka nevojë për të. Ka biznese që nuk kanë nevojë për atë lloj shpejtësie ndryshimi. Unë njoh kompani ku ndryshimet nuk mund të bëhen çdo 15 minuta. Dhe jo sepse janë shumë të këqij. Ky është një cikël i tillë jetësor. Dhe për të bërë funksionin e degëve, funksionin e ndërrimit, keni nevojë për njohuri të thella.
Eshte e komplikuar. Nëse dëshironi të lexoni më në detaje historinë rreth veçorisë së ndërrimit, ju rekomandoj shumë . Dhe ka një artikull të mrekullueshëm nga Martin Fowler për veçoritë e ndërrimit: çfarë llojesh ekzistojnë, ciklet e jetës, etj. Tipari i ndërrimit është i ndërlikuar.
Dhe ende nuk i jeni përgjigjur pyetjes: "A nevojitet apo jo Jenkins?"
Jenkins nuk është i nevojshëm në asnjë rast me të vërtetë. Megjithatë, seriozisht, mjetet: Jenkins, Gitlab do t'ju sjellin lehtësi. Do të shihni që montimi është i montuar ose jo i montuar. Ata mund t'ju ndihmojnë, por nuk do t'ju japin praktikë. Ata mund t'ju japin vetëm një rreth - Ok, jo Ok. Dhe pastaj, nëse shkruani edhe teste, sepse nëse nuk ka teste, atëherë është pothuajse e kotë. Prandaj, është e nevojshme sepse është më e përshtatshme, por në përgjithësi mund të jetoni pa të, nuk do të humbni shumë.
Kjo do të thotë, nëse keni praktika, a do të thotë kjo që nuk ju nevojiten?
Kjo është e drejtë. Unë rekomandoj testin Jez Humble. Aty kam një qëndrim ambivalent ndaj pikës së fundit. Por në përgjithësi, nëse keni tre gjëra, bashkoheni vazhdimisht, kryeni teste për kryerjet në master, rregulloni shpejt ndërtimin në master, atëherë ndoshta nuk keni nevojë për asgjë tjetër.
Ndërsa presim pyetje nga pjesëmarrësit, kam një pyetje. Ne po flisnim vetëm për kodin e produktit. E keni përdorur për kodin e infrastrukturës? A është i njëjti kod, a ka të njëjtat parime dhe të njëjtin cikël jetësor, apo ka cikle dhe parime të ndryshme jetësore? Zakonisht, kur të gjithë flasin për Integrim dhe Zhvillim të Vazhdueshëm, të gjithë harrojnë se ekziston edhe kodi i infrastrukturës. Dhe së fundmi ka pasur gjithnjë e më shumë. Dhe a duhet të sillen të gjitha këto rregulla atje?
As ashtu siç duhet, do të ishte mirë sepse do ta bënte jetën më të lehtë në të njëjtën mënyrë. Sapo punojmë me kod, jo me bash skripta, por kemi kod normal.
Stop, stop, një skrip bash është gjithashtu kod. Mos e prek dashurinë time të vjetër.
Mirë, nuk do t'i shkel kujtimet e tua. Unë kam një mospëlqim personal për bash-in. Thyehet e shëmtuar dhe e frikshme gjatë gjithë kohës. Dhe shpesh prishet në mënyrë të paparashikueshme, prandaj nuk më pëlqen. Por në rregull, le të themi se ke kod bash. Ndoshta vërtet nuk e kuptoj dhe ka korniza normale testimi atje. Unë thjesht nuk jam në dijeni. Dhe ne marrim të njëjtat përfitime.
Sapo punojmë me infrastrukturën si kod, kemi të njëjtat probleme si zhvilluesit. Para disa muajsh u ndesha në një situatë ku një koleg më dërgoi një kërkesë tërheqjeje për 1 linja në bash. Dhe rrini në rishikim për 000 orë. Të njëjtat probleme lindin. Është ende kod. Dhe është ende një bashkëpunim. Ne ngecim me kërkesën për tërheqje dhe ngecim me faktin se po zgjidhim të njëjtat konflikte të bashkimit në të njëjtin bash, për shembull.
Tani po e shikoj në mënyrë shumë aktive të gjithë këtë në programet më të bukura infra. Tani e kam futur Pulumin në infrastrukturë. Ky është programimi në formën e tij më të pastër. Atje është edhe më bukur, sepse unë i kam të gjitha aftësitë e një gjuhe programimi, d.m.th. kam bërë një ndërrim të bukur nga bluja me të njëjtat nëse dhe gjithçka është në rregull. Kjo është, ndryshimi im është tashmë në master. Të gjithë tashmë mund ta shohin atë. Inxhinierë të tjerë dinë për të. Tashmë ka ndikuar diçka atje. Megjithatë, nuk është aktivizuar për të gjitha infrastrukturat. Ajo u ndez për stolat e mia të provës, për shembull. Prandaj, për t'iu përgjigjur pyetjes suaj përsëri, është e nevojshme. Na e bën jetën më të lehtë, si inxhinierë që punojnë me kod, në të njëjtën mënyrë.
Nëse dikush tjetër ka pyetje?
Kam një pyetje. Unë dua të vazhdoj diskutimin me Oleg. Ne pergjithesi une mendoj qe ke te drejte, qe nese nje detyre zgjat nje muaj per te kryer, atehere ke problem me arkitekturen, ke problem me analizen, dekompozimin, planifikimin etj. Por kam nje ndjenje qe po te fillosh duke u përpjekur live sipas Integrimit të Vazhdueshëm, atëherë do të filloni ta korrigjoni dhimbjen me planifikim, sepse nuk do t'i ikni askund tjetër.
(Oleg) Po, ashtu është. Kjo praktikë është e krahasueshme në përpjekje me çdo praktikë tjetër serioze të ndryshimit të kulturës. Gjëja më e vështirë për t'u kapërcyer janë zakonet, veçanërisht zakonet e këqija. Dhe nëse për të zbatuar këtë praktikë, kërkohet një ndryshim serioz në zakonet e atyre që ju rrethojnë: zhvilluesit, menaxhmenti, menaxheri i prodhimit, atëherë ju presin surpriza.
Çfarë surprizash mund të ketë? Le të themi se keni vendosur që do të integroheni më shpesh. Dhe ju keni disa gjëra të tjera të lidhura me integrimin, për shembull, artefakte. Dhe në kompaninë tuaj, për shembull, ekziston një politikë që çdo objekt duhet të llogaritet në një farë mënyre në një lloj sistemi të ruajtjes së objekteve. Dhe kërkon pak kohë. Një person duhet të kontrollojë kutinë që ai, si menaxher lëshimi, e ka testuar këtë objekt për t'u siguruar që është gati për lëshim në prodhim. Nëse duhen 5-10-15 minuta, por ju e bëni paraqitjen një herë në javë, atëherë shpenzimi i gjysmë ore një herë në javë është një taksë e vogël.
Nëse bëni Integrim të vazhdueshëm 10 herë në ditë, atëherë 10 herë duhet të shumëzohen me 30 minuta. Dhe kjo tejkalon sasinë e kohës së punës të këtij menaxheri të lëshimit. Ai thjesht lodhet duke e bërë atë. Ka kosto fikse për disa praktika. Kjo eshte e gjitha.
Dhe ju duhet ose ta anuloni këtë rregull në mënyrë që të mos bëni më mbeturina të tilla, domethënë të mos caktoni manualisht një diplomë për të korresponduar me diçka. Ju jeni duke u mbështetur tërësisht në disa grupe të automatizuara testesh gatishmërie.
Dhe nëse keni nevojë për prova nga dikush, në mënyrë që shefi ta nënshkruajë atë, dhe ju të mos hyni në prodhim pa thënë Vasya që ai e lejon, etj. - e gjithë kjo marrëzi e pengon praktikuesin. Sepse nëse ka disa aktivitete që lidhen me një taksë, atëherë çdo gjë rritet 100 herë. Prandaj, ndërrimi shpesh nuk do të përshëndetet me gëzim nga të gjithë. Sepse zakonet e njerëzve janë të vështira për t'u ndryshuar.
Kur një person bën punën e tij të zakonshme, ai e bën atë pothuajse pa menduar. Ngarkesa e saj njohëse është zero. Ai thjesht luan me të, ai tashmë ka një listë kontrolli në kokën e tij, ai e ka bërë atë një mijë herë. Dhe sapo vini dhe i thoni: "Le ta anulojmë këtë praktikë dhe të prezantojmë një të re duke filluar nga e hëna", për të bëhet një ngarkesë e fuqishme njohëse. Dhe u vjen të gjithëve menjëherë.
Prandaj, gjëja më e thjeshtë, megjithëse jo të gjithë mund ta përballojnë këtë luks, por kjo është ajo që bëj gjithmonë, kjo është sa vijon. Nëse fillon një projekt i ri, atëherë zakonisht të gjitha praktikat e patestuara futen menjëherë në këtë projekt. Ndërsa projekti është i ri, ne nuk rrezikojmë asgjë. Nuk ka ende asnjë Prod, nuk ka asgjë për të shkatërruar. Prandaj, mund të përdoret si trajnim. Kjo qasje funksionon. Por jo të gjitha kompanitë kanë mundësinë të fillojnë shpesh projekte të tilla. Edhe pse kjo është gjithashtu pak e çuditshme, sepse tani ka një transformim të plotë dixhital, të gjithë duhet të nisin eksperimente në mënyrë që të mbajnë hapin me konkurrentët.
Këtu arrini në përfundimin se së pari duhet të kuptoni se çfarë duhet të bëni. Bota nuk është ideale dhe as prod-i nuk është ideal.
Po, këto gjëra janë të ndërlidhura.
Bizneset gjithashtu nuk e kuptojnë gjithmonë se duhet të shkojnë në këtë mënyrë.
Ekziston një situatë në të cilën ndryshimet nuk janë fare të mundshme. Kjo është një situatë ku ka më shumë presion mbi ekipin. Skuadra tashmë është mjaft e djegur. Ajo nuk ka kohë të lirë për asnjë eksperiment. Ata punojnë në karakteristika nga mëngjesi në mbrëmje. Dhe menaxhimi ka gjithnjë e më pak karakteristika. Kërkohen gjithnjë e më shumë. Në një situatë të tillë, ndryshimet nuk janë fare të mundshme. Skuadrës mund t'i thuhet vetëm se nesër do të bëjmë të njëjtën gjë si dje, thjesht duhet të bëjmë pak më shumë veçori. Në këtë kuptim, asnjë kalim në asnjë praktikë nuk është i mundur. Kjo është një situatë klasike kur nuk ka kohë për të mprehur sëpatën, pemët duhet të priten, kështu që ata e presin atë me një sëpatë të shurdhër. Këtu nuk ka këshilla të thjeshta.
(Dmitry) Do të lexoj një sqarim nga biseda: "Por ne kemi nevojë për shumë mbulim testimi në nivele të ndryshme. Sa kohë i kushtohet testeve? Është pak e shtrenjtë dhe kërkon shumë kohë.”
(Oleg) Ky është një keqkuptim klasik. Duhet të ketë mjaft teste për të qenë të sigurt. Integrimi i vazhdueshëm nuk është një gjë ku fillimisht kryhen 100% të testeve dhe vetëm atëherë filloni ta zbatoni këtë praktikë. Integrimi i vazhdueshëm zvogëlon ngarkesën tuaj njohëse për faktin se secili nga ndryshimet që shihni me sytë tuaj është aq i dukshëm sa e kuptoni nëse do të prishë diçka apo jo, edhe pa teste. Mund ta provoni shpejt këtë në kokën tuaj sepse ndryshimet janë të vogla. Edhe nëse keni vetëm testues manualë, është më e lehtë edhe për ta. Ju doli jashtë dhe tha: "Shiko, a është prishur ndonjë gjë?" Ata kontrolluan dhe thanë: "Jo, asgjë nuk është e prishur". Sepse testuesi e di ku të shikojë. Ju keni një kryerje të lidhur me një pjesë të kodit. Dhe kjo shfrytëzohet nga sjellje specifike.
Këtu ju, sigurisht, zbukuruar.
(Dmitri) Nuk jam dakord këtu. Ekziston një praktikë - zhvillim i drejtuar nga testi, i cili do t'ju shpëtojë nga kjo.
(Oleg) Epo, nuk kam arritur ende në atë pikë. Iluzioni i parë është se ju duhet të shkruani 100% të testeve ose nuk keni nevojë të bëni fare Integrim të vazhdueshëm. Nuk eshte e vertete. Këto janë dy praktika paralele. Dhe ata nuk janë të varur drejtpërdrejt. Mbulimi juaj i testit duhet të jetë optimal. Optimale - kjo do të thotë që ju vetë jeni të sigurt se cilësia e mjeshtrit në të cilën mbeti zotëria juaj pas kryerjes ju lejon të shtypni me siguri butonin "Deploy" në një mbrëmje të së premtes së dehur. Si e arrini këtë? Përmes rishikimit, përmes mbulimit, përmes monitorimit të mirë.
Monitorimi i mirë nuk dallohet nga testet. Nëse kryeni teste një herë në pre-prod, atëherë ata kontrollojnë të gjitha skriptet e përdoruesit tuaj një herë dhe kaq. Dhe nëse i drejtoni ato në një lak të pafund, atëherë ky është sistemi juaj i monitorimit i vendosur, i cili teston pafundësisht gjithçka - nëse është rrëzuar apo jo. Në këtë rast, ndryshimi i vetëm është nëse bëhet një ose dy herë. Një grup shumë i mirë testesh... që vrapon pafund, ky është monitorimi. Dhe monitorimi i duhur duhet të jetë i tillë.
Dhe për këtë arsye, se si do ta arrini saktësisht këtë gjendje kur të bëheni gati të premten në mbrëmje dhe të shkoni në shtëpi është një pyetje tjetër. Ndoshta ju jeni thjesht një pleh i guximshëm.
Le të kthehemi pak te Integrimi i Vazhdueshëm. Ikën në një praktikë komplekse paksa të ndryshme.
Dhe iluzioni i dytë është se MVP, thonë ata, duhet të bëhet shpejt, kështu që testet nuk nevojiten fare atje. Jo sigurisht në atë mënyrë. Fakti është se kur shkruani një histori përdoruesi në një MVP, ose mund ta zhvilloni atë në top, domethënë, keni dëgjuar se ka pasur një lloj historie të përdoruesit dhe menjëherë vraponi për ta koduar atë, ose mund të punoni duke përdorur TDD. Dhe sipas TDD, siç tregon praktika, nuk zgjat më shumë, d.m.th. testet janë një efekt anësor. Praktika e TDD nuk ka të bëjë me testimin. Pavarësisht nga ajo që quhet Test Driven Development, nuk bëhet fjalë fare për teste. Kjo është gjithashtu më tepër një qasje arkitekturore. Kjo është një qasje për të shkruar saktësisht atë që nevojitet dhe për të mos shkruar atë që nuk nevojitet. Kjo është një praktikë e përqendrimit në përsëritjen e ardhshme të të menduarit tuaj në drejtim të krijimit të një arkitekture aplikacioni.
Prandaj, nuk është aq e lehtë të heqësh qafe këto iluzione. MVP dhe testet nuk kundërshtojnë njëra-tjetrën. Madje, përkundrazi, nëse bëni MVP duke përdorur praktikën TDD, atëherë do ta bëni më mirë dhe më shpejt sesa nëse e bëni pa praktikë fare, por me top.
Kjo është një ide shumë jo e qartë dhe komplekse. Kur të dëgjoni se tani do të shkruaj më shumë teste dhe në të njëjtën kohë do të bëj diçka më shpejt, tingëllon absolutisht joadekuate.
(Dmitry) Shumë njerëz këtu, kur thërrasin MVP, njerëzit janë shumë dembel për të shkruar diçka normale. Dhe këto janë akoma gjëra të ndryshme. Nuk ka nevojë ta ktheni MVP-në në ndonjë gjë të keqe që nuk funksionon.
Po, po, ke të drejtë.
Dhe pastaj papritmas MVP në prod.
Forever.
Dhe TDD tingëllon shumë e pazakontë kur dëgjoni se shkruani teste dhe duket se bëni më shumë punë. Tingëllon shumë e çuditshme, por në fakt rezulton më e shpejtë dhe më e bukur në këtë mënyrë. Kur shkruani një test, tashmë mendoni shumë në kokën tuaj se çfarë kodi do të quhet dhe si, si dhe çfarë sjelljeje presim prej tij. Ju nuk mund të thoni vetëm se kam shkruar një funksion dhe ai bën diçka. Fillimisht menduat se ajo kishte kësisoj kushte, do të thirrej kështu e ashtu. Ju e mbuloni këtë me teste dhe nga kjo kupton se si do të duken ndërfaqet tuaja brenda kodit tuaj. Kjo ka një ndikim të madh në arkitekturë. Kodi juaj automatikisht bëhet më modular, sepse së pari përpiqeni të kuptoni se si do ta testoni dhe vetëm më pas e shkruani.
Ajo që më ndodhi me TDD ishte se në një moment punësova një mentor Ruby kur isha ende një programues Ruby. Dhe ai thotë: "Le ta bëjmë atë sipas TDD." Mendova: "Dreq, tani duhet të shkruaj diçka shtesë." Dhe ne ramë dakord që brenda dy javësh do të shkruaja të gjithë kodin e punës në Python duke përdorur TDD. Pas dy javësh, kuptova se nuk doja të kthehesha. Pas dy javësh përpjekjeje për ta zbatuar këtë kudo, e kupton se sa më e lehtë është bërë për ty që edhe të mendosh. Por kjo nuk është e qartë, kështu që unë rekomandoj për të gjithë që nëse keni ndjenjën se TDD është e vështirë, kërkon kohë dhe e panevojshme, provoni të qëndroni me të për vetëm dy javë. Dy ishin të mjaftueshme për mua.
(Dmitri) Ne mund ta zgjerojmë këtë ide nga pikëpamja e funksionimit të infrastrukturës. Para se të lëshojmë ndonjë gjë të re, ne bëjmë monitorim dhe më pas nisim. Në këtë rast, monitorimi bëhet testim normal për ne. Dhe ka zhvillim nëpërmjet monitorimit. Por pothuajse të gjithë thonë se është e gjatë, unë jam dembel, kam bërë një draft të përkohshëm. Nëse kemi bërë monitorim normal, kuptojmë gjendjen e sistemit CI. Dhe sistemi CI ka shumë monitorim. Ne e kuptojmë gjendjen e sistemit, kuptojmë se çfarë është brenda tij. Dhe gjatë zhvillimit, ne thjesht po e bëjmë sistemin në mënyrë që të arrijë gjendjen e dëshiruar.
Këto praktika janë të njohura për një kohë të gjatë. Ne e diskutuam këtë rreth 4 vjet më parë. Por në 4 vjet praktikisht asgjë nuk ka ndryshuar.
Por në këtë shënim, unë propozoj të mbyllet diskutimi zyrtar.
Video (e futur si një element mediatik, por për ndonjë arsye nuk funksionon):
Burimi: www.habr.com