Le të diskutojmë pse mjetet CI dhe CI janë krejtësisht gjëra të ndryshme.
Cila është dhimbja që CI synon të zgjidhë, nga ka ardhur idea, çfarë konfirmimesh të fundit ka që funksionon, si të kuptoni që keni praktikë dhe jo thjesht Jenkins të instaluar.
Ideja për të bërë një prezantim mbi Integrimin e Vazhdueshëm lindi një vit më parë, kur isha në intervista për të kërkuar punë. Kam biseduar me 10-15 kompani, dhe vetëm njëra arriti të shpjegojë qartë se çfarë është CI dhe si ata kuptuan që nuk e kishin atë. Të tjerat thoshin gjëra të paqarta rreth Jenkins 🙂 Po, ne kemi Jenkins, ai bën ndërtimet, CI! Në këtë prezantim do të përpiqem të shpjegoj se çfarë është në të vërtetë Integrimi i Vazhdueshëm dhe pse Jenkins dhe mjetet e ngjashme kanë një lidhje shumë të dobët me këtë.
Pra, çfarë vjen zakonisht në mendje kur mendoni për CI? Shumicës së njerëzve u vjen në mendje Jenkins, Gitlab CI, Travis, etj.
Edhe nëse ne e gjejmë në Google, do të na tregojnë këto mjete.
Nëse pyesni njerëzit nëse janë të njohur, menjëherë pas përmendjes së mjeteve do t'ju tregojnë se CI është kur ndodh ndërtimi dhe provojnë testet në Pull Request për commit.
Integrimi i Vazhdueshëm nuk ka të bëjë me mjetet, as me ndërtimet me teste në degë! Integrimi i Vazhdueshëm është një praktikë e integrimit të shpeshtë të kodit të ri dhe për ta zbatuar këtë nuk është e nevojshme të zhvilloni 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 atë dhe të ndjejmë dhimbjen që ata përpiqeshin të zgjidhnin.
Ata po zgjidhnin dhimbjen e bashkëpunimit në ekip!
Le të shohim disa shembuj, me cilat sfida përballen zhvilluesit gjatë zhvillimit në grup. Kemi një projekt, dega master në git dhe dy zhvillues.
Dhe ata filluan të punojnë siç kanë bërë gjithmonë. Merrnin një detyrë në Jira, krijonin një feature branch dhe shkruanin kod.
Njëri përfundoi veçorinë më shpejt dhe e bashkoi në master.
Tjetri pati më shumë kohë, ai u bashkua më vonë dhe mori një konflikt. Tani, në vend që të shkruante funksionalitete të nevojshme për biznesin, zhvilluesi kalon kohë dhe energji për të zgjidhur konfliktet.
Sa më e komplikuar të jetë bashkimi i funksionalitetit tuaj me masterin e përbashkët, aq më shumë kohë do të harxhoni në këtë. Dhe kjo është ende një shembull mjaft i thjeshtë. Ky është një shembull ku përfshihen vetëm 2 zhvillues. Imagjinoni nëse 10, 15 ose 100 njerëz në kompani shkruajnë në një depo. Do të çmendeni duke zgjidhur të gjitha këto konflikte.
Ka një rast pak ndryshe. Ne kemi masterin dhe disa zhvillues që po bëjnë diçka.
Ata krijuan nga një degë.
Njëri u bashkua, gjithçka ishte në rregull, dorëzoi detyrën.
Zhvilluesi tjetër në të njëjtën kohë dorëzoi detyrën e tij. Supozoni se ai e dha atë për rishikim. Në shumë kompani ekziston praktika - rishikimi. Nga njëra anë, kjo është një praktikë e mirë dhe e dobishme, nga ana tjetër, na pengon në shumë raste. Nuk do të thellohemi në këtë, por ja një shembull i shkëlqyer se çfarë mund të sjellë një histori e komplikuar me rishikimin. Keni dorëzuar një pull request për rishikim. Zhvilluesit nuk kanë gjë tjetër për të bërë. Çfarë fillon ai të bëjë? Ai fillon të marrë detyra të tjera.
Në këtë kohë, zhvilluesi i dytë ka bërë diçka tjetër.
I pari përfundoi një detyrë tjetër.
Dhe pas një kohe, rishikimi i tij është provuar dhe ai përpiqet të bashkohet. Çfarë ndodh? Ai përjeton një numër të madh konfliktesh. Pse? Sepse derisa pull requesti i tij të ishte në rishikim, në kod pati shumë ndryshime.
Përveç historisë me konflikti, ka dhe një histori me komunikimin. Pasi që dega juaj është në rishikim, ndalon së ndjekuri se çfarë tjetër po ndryshon në bazën e kodit tuaj të shërbimit. Mund të jetë që ajo që po përpiqeni të zgjidhni tani është zgjidhur nga dje dhe mund të merrni një metodë për ta ri përdorur. Por nuk do ta shihni këtë, sepse gjithmonë punoni me një degë të vjetër. Dhe kjo degë e vjetër gjithmonë sjell si pasojë se do të keni të nevojshme të zgjidhni konflikte bashkimi.
Kështu, nëse punojmë si një ekip, dmth. jo vetëm një njeri merret me depozitën, por 5-10 njerëz, sa 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 të kemi, dhe sa më shumë me një version të vjetër punojmë, aq më tepër probleme kemi.
Bashkëpunimi është i dhimbshëm! Ne gjithmonë pengojmë njëri-tjetrin.
Kjo problematikë është vënë re mbi 20 vjet më parë. Për herë të parë, unë e gjetëm përmendjen e praktikës së Integrimit të Vazhdueshëm në programimin ekstrem.
Programimi ekstrem është korniza e parë agile. Faqa u shfaq në vitin 96. Ideja ishte të përdoren disa praktika programimi, planifikimi dhe të tjerë, që zhvillimi të jetë sa më fleksibël, për të ndihmuar në reagimin më të shpejtë ndaj ndryshimeve dhe kërkesave nga klientët tanë. Dymbëdhjetë vjet më parë filluan të përballen me faktin se, nëse bën diçka për një kohë të gjatë dhe në mënyrë të ndarë, konsumon më shumë kohë për shkak të konflikteve.
Tani do ta shqyrtojmë frazën "Integrimi i vazhdueshëm" fjalë për fjalë. Nëse e përkthejmë dosido, na del integrim i vazhdueshëm. Por sa vazhdimisht është kjo, nuk është shumë e qartë; ajo është shumë e ndërprerë. Por sa është "integration" gjithashtu nuk është shumë e dukshme.
Dhe për këtë arsye po sjell tani citate nga programimi ekstrem. Të dy fjalët do t'i shqyrtojmë veçmas.
Integrimi - Siç e thashë, ne synojmë 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ë të jenë dega 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 programuesi largohet për një muaj për të punuar në një karakteristikë të madhe. Dhe ai në fazën e integrimit mund të ngecë për një kohë të gjatë.
Integrimi është kur marrim degën tonë dhe e integrojmë me masterin, e bashkojmë atë. Ka një variant ultimativ, kur ne jemi "transbase developer", ku përpiqemi të shkruajmë direkt në master pa degë të panevojshme.
Në thelb, integrimi është të marrësh kodin tënd dhe ta çosh në master.
Çfarë nënkuptohet këtu me fjalën "continuous", çfarë quhet vazhdimësi? Praktika nënkupton që programuesi synon të integrojë kodin e tij sa më shpejt. Kjo është qëllimi gjatë përfundimit të çdo detyre – të bëjë që kodi i tij të shfaqet në master sa më shpejt. Në një botë ideale, programuesit do ta bënin këtë çdo disa orë. Do thotë, merr një detyrë të vogël, e bashkon në master. E gjitha është e shkëlqyer. Kështu që duhet ta bëni vazhdimisht. Sa herë që bëni diçka, menjëherë e çoni në master.
Dhe programuesi, i cili bën diçka, është përgjegjës për atë që ka bërë, që të funksionojë dhe të mos prishë asgjë. Këtu zakonisht dalin historitë me testet. Ne dëshirojmë të ekzekutojmë disa teste mbi commit-in tonë, mbi bashkimin tonë, për t'u siguruar që ajo funksionon. Dhe këtu Jenkins mund t'ju ndihmojë.
Por për historitë: a të bëjmë ndryshimet të vogla, a të bëjmë që detyrat të jenë të vogla, a të bëjmë që detyra ta përfundojmë dhe menjëherë të përpiqemi ta bashkojmë në master – këtu nuk do t'ju ndihmojnë asnjë Jenkins. Sepse Jenkins do t'ju ndihmojnë vetëm për të ekzekutuar testet.
Mund të kaloni edhe pa to. Nuk do t'ju pengojnë fare. Sepse qëllimi i praktikës është të bashkoni sa më shpesh, për të mos humbur një sasi të madhe kohe për disa konflikte në të ardhmen.
Imagjinoni se vitin 2020 ndodhemi pa internet. Dhe ne punojmë lokal. Nuk kemi Jenkins. Kjo është në rregull. Ende mund të merrni dhe të krijoni një degë lokale. Keni shkruar ndonjë kod. Keni përfunduar një detyrë pas 3-4 orësh. Kaloni në master, bëni git pull, e bashkoni degën tuaj atje. Gati. Nëse e bëni këtë shpesh – përshëndetje, keni integrim të vazhdueshëm!
Cilat janë provat në botën moderne që tregojnë se duhet të investoni energjinë tuaj në këtë? Sepse në përgjithësi kjo është e ndërlikuar. Nëse përpiqeni të punoni kështu, do të kuptoni se kjo do të prekë ndonjë planifikim, do t'ju duhet të përkushtoni më shumë kohë për dekompozimin e detyrave. Sepse nëse bëni man…, nuk do të bëni bashkimin shpejt dhe për rrjedhojë do të bini në një situatë të vështirë. Praktikat tuaja do të humbasin.
Dhe kjo do të jetë e shtrenjtë. Nuk do të arrini t'i kaloni menjëherë praktikë aktuale të integrimit të vazhdueshëm. Të gjithë do t'ju duhen shumë kohë për t'u adaptuar, shumë kohë për t'u mësuar të dekompozoni detyrat, shumë kohë për t'u mësuar të rishikoni praktikat, nëse ato ekzistojnë. Sepse qëllimi ynë është që ta bashkojmë sot. Dhe nëse e bëni rishikimin në tre ditë, atëherë keni probleme dhe integrimi i vazhdueshëm nuk funksionon.
Por a kemi ndonjë provë aktuale tani që na thotë se investimi në këtë praktikë ka kuptim?
E para që më erdhi në mendje – është State of DevOps. Ky është një studim që ekipi e ka zhvilluar për 7 vjet. Tani ata e bëjnë si një organizatë të pavarur, por nën Google.
Dhe studimi i tyre në vitin 2018 tregoi një korrelacion midis kompanive që përpiqen të përdorin degë të shkurtra, të cilat integrohen shpejt, integrohen shpesh, ato kanë të dhëna më të mira të performancës IT.
Çfarë janë këto të dhëna? Këto janë 4 metrika që ata shkencojnë nga të gjitha kompanitë në anketat e tyre: frekuenca e lansimit, kohëzgjatja për ndryshime, koha për të rikthyer shërbimin, shkalla e dështimit të ndryshimit.
Së pari, ekziston ky korrelacion, e dimë se kompanitë që bëjnë bashkime shpesh, kanë këto metrika shumë më të mira. Dhe ata kanë bërë një ndarje të kompanive në disa kategori: ato kompani të ngadalta që prodhojnë diçka ngadalë, performerë mesatarë, performerë të lartë dhe elita. Elita janë Netflix, Amazon, të cilat janë jashtëzakonisht të shpejta, gjithëçka e bëjnë shpejt, bukur dhe me cilësi.
Historia tjetër, që ndodhi vetëm një muaj më parë. Në Technology Radar u shfaq një shënim i shkëlqyer rreth Gitflow. Gitflow dallon nga të gjitha të tjerat sepse degët e tij jetojnë për një kohë të gjatë. Ka degë lëshimi që jetojnë për një kohë të gjatë, degë funksionesh që gjithashtu jetojnë gjatë. Kjo praktikë në Technology Radar kaloi në HOLD. Pse? Sepse njerëzit përballen me dhimbjen e integrimit.
Nëse një degë jeton për një kohë shumë të gjatë, ajo ngec, skadon, ne fillojmë të harxhojmë më shumë kohë për të bërë një ndryshim në të.
Dhe së fundmi, autori i Gitflow tha se nëse ju përpiqeni për Integrim të Vazhdushëm, nëse ju dëshironi të lëvizni sa më shpesh, atëherë Gitflow është një ide e keqe. Ai veçantësh në artikullin e tij shtoi se nëse keni një backend, ku mund të synoni këtë, atëherë Gitflow është e 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ë që Gitflow është i keq dhe nuk duhet ta përdorni. Ai është për raste të tjera. Për shembull, kur ju nevojitet të mbështesni disa versione të shërbimit, aplikacionit, pra ku duhet të mbështetni për një periudhë më të zgjatur kohore.
Por nëse flisni me njerëzit që mbështesin këto shërbime, do të dëgjoni shumë dhimbje për faktin se kjo version ishte 3.2, që ishte 4 muaj më parë, dhe se kjo përmirësim nuk u përfshi dhe tani, për ta treguar, duhet të bëni shumë ndryshime. Dhe tani ata mbeten përsëri të bllokuar, dhe kalojnë një javë duke u zvarritur për të marrë dhe bërë bashkimin e ndonjë funksionaliteti të ri.
Siç e vuri në dukje Aleksandër Kovalëv në bisedë, korrelacioni nuk do të thotë lidhje shkaku-pasojë. Kjo është e vërtetë. Pra, nuk ka ndonjë lidhje të drejtpërdrejtë se nëse keni Integrim të Vazhdushëm, atëherë të gjitha metrikat do të jenë shkëlqyese, jo. Por ekziston një korrelacion pozitiv që nëse një është e vërtetë, atëherë me siguri tjetra është gjithashtu e tillë. Nuk është fakt, por me siguri. Ky është thjesht një korrelacion.
Duket se ne tashmë po bëjmë diçka, duket se po bashkohemi, por si të kuptojmë nëse ne në të vërtetë kemi Integrim të Vazhdushëm, se po bashkohemi mjaft shpesh?
Jez Humble është autori i Manualit, Accelerate, faqeve të Integrimit të Vazhdushëm dhe librit "Integrimi i Vazhdushëm". Ai ofron këtë test:
- Kodi i inxhinierit hyjnë në master çdo ditë.
- Në çdo commit ju ekzekutoni teste unit.
- Buildi në master ra, u rregullua për afërsisht 10 minuta.
Ai ofron të përdorë këtë test për të siguruar që praktika është atje.
E fundit e gjej pak të diskutueshme. Kështu që nëse mund ta rregulloni për 10 minuta, do të thotë se keni Integrim të Vazhdushëm, tingëllon pak e çuditshme, në mendimin tim, por ka kuptim. Pse? Sepse nëse po bashkoheni shpesh, do të thotë se ndryshimet janë të vogla. Nëse një ndryshim i vogël shkakton dështimin e buildit në master, atëherë do të jeni në gjendje të gjeni shpejt shembullin e gabimit, sepse ndryshimi është i vogël. Ja, keni pasur një bashkim të vogël, në të cilin janë ndryshuar 20-30 linja. Dhe, përkatësisht, mund të kuptoni shpejt se cila ishte arsyeja, sepse ndryshimet janë të vogla, kështu që keni një zonë shumë të vogël për të kërkuar problemin.
Dhe madje edhe nëse na bie prodhimi pas lansimit, nëse kemi një praktikë Integrimi të Vazhdushëm, është shumë më lehtë të veprojmë, sepse ndryshimet janë të vogla. Po, kjo do të ndikojë në planifikim. Do të jetë e dhimbshme. Dhe ndoshta, më e vështira në këtë praktikë – është të mësoni të ndani detyrat, pra si të bëni diçka dhe ta kryeni brenda disa orësh dhe ndërkohë të kaloni revistën, nëse e keni. Rishikimi është një dhimbje e veçantë.
Teste unit janë thjesht një ndihmësi që ju ndihmon të kuptoni – a ka kaluar me sukses integrimi juaj, a ka ndodhur ndonjë dështim. Në mendimin tim, kjo gjithashtu nuk është një pikë e obligueshme, sepse thelbi i praktikës nuk është kjo.
Kjo është një përmbledhje e shkurtër mbi Integrimin e Vazhdushëm. Kjo është gjithçka që ka në këtë praktikë. Jam i gatshëm për pyetje.
Shkurt, vetëm përsëri do t'i përmbledh:
- Integrimi i Vazhdushëm nuk është Jenkins, nuk është Gitlab.
- Kyç është jo vetëm një mjet, por një praktikë për të bashkuar sa më shpesh kodin tonë në master.
- E bëjmë këtë për të shmangur dhimbjen e madhe që vjen nga bashkimet në të ardhmen, pra, po përjetojmë një dhimbje të vogël tani për të mos përjetuar një dhimbje të madhe më vonë. Kjo është e gjitha.
- Nga ana e kodit kalon komunikimi, por unë shumë rrallë e shoh këtë, megjithatë për këtë është menduar gjithashtu.
Pyetje
Çfarë të bëjmë me detyrat që nuk decompozohet?
Të decompozojmë. Çfarë problemi ka? Mund të japësh një shembull, se ka një detyrë dhe ajo nuk decompozohet?
Ka detyra të tilla që nuk mund të decompozohet fare, për shembull, ato që kërkojnë një ekspertizë të thellë dhe që mund të zgjidhen realisht gjatë një muaji deri në një rezultat të pranueshëm.
Nëse të kuptova mirë, ka një detyrë të madhe dhe të komplikuar, rezultati i së cilës do të jetë i dukshëm vetëm pas një muaji?
Po, saktësisht. Po, rezultatin mund ta vlerësosh vetëm 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 po flasim për degën e funksionalitetit. Funksionalitetet mund të jenë të mëdha dhe të komplikuara. Ato mund të përfshijnë shumë komponentë. Dhe ndoshta nuk mund t’i realizojmë plotësisht në një degë. Kjo është normale. Na nevojitet vetëm të ndajmë këtë histori. Nëse funksionaliteti nuk është gati deri në fund, kjo nuk do të thotë se disa pjesë të kodit të tij nuk mund të bashkohen. Ke shtuar, për shembull, migrimin dhe brenda funksionalitetit ka disa faza. Ka, për shembull, një fazë – të bësh migrimin, të shtosh një metodë të re. Dhe këto gjëra mund t’i bashkosh çdo ditë.
Mirë. Çfarë ka kuptim në këtë?
Çfarë kuptimi ka të bashkosh gjëra të vogla çdo ditë?
Po.
Nëse ato të dëmtojnë, e sheh menjëherë. Ke një copë të vogël që e ka thyer diçka, dhe është më e lehtë ta rregullosh. Këtu është kuptimi, që të bashkosh një copë të vogël tani është shumë më e lehtë sesa 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 migrime, dhe këtu ka një metodë që ata gjithashtu ndoshta do të duan ta përdorin. Të gjithë do të shohin se çfarë po ndodh me kodin tënd. Pikërisht për këto tre arsye praktika bëhet.
Faleminderit, pyetja është mbyllur!
(Oleg Soroka) A mund të shtoj diçka? Ti e ke thënë atë të drejtë, dua vetëm të shtoj një frazë.
Po.
Gjatë Continuous Integration, kodi bashkohet në degën e përbashkët jo kur funksionaliteti është plotësisht gati, por kur ndalon së prishuri ndërtimin. Dhe ju mund të angazhoheni në master sa herë që dëshironi gjatë ditës. Aspekti i dytë - nëse për ndonjë arsye nuk mund të ndash një detyrë njëmujor në detyra, edhe për tri ditë, nuk po flas për tri orë, atëherë keni një problem të madh. Dhe fakti që nuk keni Continuous Integration – është më i vogli nga këto probleme. Kjo do të thotë që keni probleme me arkitekturën dhe praktikat inxhinierike janë në zero. Sepse edhe nëse bëhet fjalë për kërkime, prapë duhet ta formatizoni atë në formën e hipotezave ose ciklit.
Flisnim për 4 metrikat që dallojnë kompanitë e suksesshme nga ato që mbeten prapa. Para këtyre 4 metrike, duhet të arrini. Nëse një detyrë e mesme zgjat një muaj, do të përqendrohesha fillimisht në këtë metrikë. Do ta ulja fillimisht në 3 ditë. Pas kësaj, do të filloja të mendoja për Continuous.
A e kuptova drejt, që mendon se investimi në praktikat inxhinierike, nëse cdo detyrë zgjat një muaj, nuk ka kuptim akoma?
Ke Continuous Integration. Dhe aty është një temë që për 10 minuta ose e rregulloni ose e ktheni mbrapsht. Imagjino, e ke lëshuar. Po ashtu ke dhe continuous deployment, e ke lëshuar në prodhim dhe vetëm pastaj e ke vënë re që diçka shkoi keq. Dhe duhet ta kthesh, por tashmë ka ndodhur migrimi i bazës së të dhënave. Tani skema e bazës së të dhënave është në versionin e ardhshëm, për më tepër, është bërë edhe një backup, dhe gjithashtu janë regjistruar të dhëna aty.
Dhe çfarë alternative ke? Nëse e kthen kodin prapa, nuk mund të funksionojë me këtë bazë të dhënash të përditësuar.
Baza lëviz vetëm përpara, po.
Për njerëzit që kanë praktika inxhinierike të dobëta, me siguri, ata nuk kanë lexuar asnjë libër të trashë për... Çfarë bëni me backupin? Nëse po rikuperoheni nga një backup, atëherë do të thotë se po humbni të dhënat që u grumbulluan në atë moment. Për shembull, keni punuar tri orë me versionin e ri të bazës së të dhënave, janë regjistruar përdorues. Po kthehesh në një backup të vjetër, sepse skema me versionin e ri nuk funksionon, përkatësisht, ata përdorues i keni humbur. Dhe ata janë të pakënaqur, ata kanë ankesa.
Për të zotëruar të gjitha praktikat që mbështesin Continuous Integration dhe Continuous Delivery, nuk mjafton të mësosh thjesht të shkruash…. Së pari, ato mund të bëhen shumë dhe do të ishte jo praktik. Përveç kësaj, ka shumë praktika të tjera si Scientific. Ka një praktikë të tillë, të njohur nga GitHub në një kohë. Kjo është kur ti ke njëkohësisht kodin e vjetër dhe kodin e ri në funksion. Kjo kur bën një karakteristikë të papërfunduar, por ajo mund të kthejë ndonjë vlerë: ose si funksion, ose si Rest API. Ti ekzekuton si kodin e ri ashtu edhe atë të vjetër dhe krahason diferencën mes tyre. Dhe nëse ka një diferencë, e regjistron këtë ngjarje. Kështu e di se karakteristika e re është gati për t’u lançuar mbi të vjetrën, nëse për një periudhë të caktuar kohe nuk ka pasur shpërputhje mes këtyre dyja.
Ka qindra të tillë praktikash. Do propozohja të fillosh me transbase development. Ajo nuk është 100 % në Continuous Integration, por praktikat janë të njëjta, njëra pa tjetrën nuk mund të ekzistojë mirë.
E ke përdorur transbase development si një shembull, ku mund të shohësh praktikat ose po sugjeron që njerëzit ta fillojnë të përdorin transbase development?
Të shohin, pasi ata nuk do të mund ta përdorin. Për ta përdorur, duhet të lexosh shumë. Dhe kur dikush ka pyetje si: "Çfarë të bëj me një karakteristikë që merr një muaj", do të thotë se ai nuk ka lexuar për transbase development. Njëkohësisht nuk do ta këshilloja akoma. Do të sugjeroja të përqendrohesh ekskluzivisht në temën e ndarjes arkitektonike të detyrave të mëdha në më të vogla. Kjo është thelbi i dekombinimit.
Dekombinimi është një nga mjetet e arkitektit. Ne fillimisht bëjmë një analizë, më pas dekombinimin, pastaj sintezën, e më pas integrimin. Kështu gjithçka përbëhet. Dhe për të arritur në Continuous Integration, duhet të kalosh përmes dekombinimit. Pyetjet në fazën e parë lindin, e ne tani po flasim për fazën e katërt, do të thotë sa më shpesh të bësh integrimin, aq më mirë. Ende është herët për ta bërë, është më mirë të fillosh me ndarjen e monolitit tënd.
Duhet të vizatosh disa shigjeta dhe katrorë në ndonjë skemë. Ti nuk mund të thuash se tani do tregoj një skemë arkitektonike të aplikacionit të ri dhe të tregosh 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 skemë që kam parë, kishte më shumë se një. Dhe dekombinimi, edhe në nivelin e prezantimit grafik, tashmë po kryhet. Prandaj katrorët mund të bëhen të pavarur. Nëse jo, atëherë kam shumë pyetje për arkitektin.
Ka një pyetje nga çati: "Nëse rishikimi është i detyrueshëm dhe zgjat shumë, diku një ditë e më shumë?".
Keni probleme me praktikën. Rishikimi nuk duhet të zgjatë një ditë e më shumë. Kjo është e njëjta histori si me pyetjen e mëparshme, por pak më e butë. Nëse rishikimi zgjat një ditë, do të thotë se ndoshta po rishikohet një ndryshim shumë të madh. Kështu që duhet ta bësh atë më të vogël. Në transbase development, që Oleg rekomandoi, ka një histori që quhet continuous review. Ideja e saj është se ne qëllimisht krijojmë kërkesa të vogla për bashkimin, sepse synojmë të bashkohemi vazhdimisht dhe pak nga pak. Prandaj kërkesa e bashkimit ndryshon një abstraksion ose 10 rreshta. Falë kësaj, rishikimi zgjat disa minuta.
Nëse rishikimi zgjat një ditë e më shumë, atëherë diçka nuk është në rregull. Së pari, ndoshta keni disa probleme me arkitekturën. Ose ndoshta është një copë e madhe kodi, për shembull 1,000 rreshta. Ose arkitektura juaj është aq e komplikuar saqë personi nuk mund ta kuptojë. Kjo është një problem nga një këndvështrim tjetër, por do të duhet ta zgjidhni atë gjithashtu. Ndoshta rishikimi nuk ka nevojë të bëhet fare. Kjo është diçka për të cilën duhet të mendohet. Rishikimi është ajo që ju ngadalëson. Ai ka përfitimet e tij në përgjithësi, por duhet të kuptoni se përse e bëni atë. A është një mënyrë për të kaluar informacionin shpejt, a është një mënyrë për të vendosur disa standarde brenda ose çfarë? Pse keni nevojë për të? Sepse rishikimi duhet të jetë ose shumë i shpejtë, ose ta anuloni atë krejt. Kjo është si transbase development - një histori shumë e bukur, por vetëm për djem të pjekur.
Në lidhje me 4 metrikat, do të rekomandoja t'i kapni ato për të kuptuar në çfarë rezultati çojnë. Shihni në numra, shihni skemën, sa keq është gjithçka.
(Dmitri) Jam i gatshëm të hyj në diskutim me ty për këtë. Numrat dhe metrikat janë të shkëlqyera, praktikat janë të shkëlqyera. Por duhet të kuptohet - a i nevojitet kjo biznesit. Ka biznese për të cilat nuk ka nevojë për këtë shpejtësi ndryshimi. Unë njoh kompani, ku nuk mund të bëhen ndryshime çdo 15 minuta. Dhe jo sepse ato janë të këqija. Është një cikël jetësor i tillë. Dhe për të bërë karakteristika branches, karakteristika toggle, janë të nevojshme njohuri të thella.
Është e komplikuar. Nëse dëshiron të lexosh më shumë për karakteristikën toggle, rekomandoj shumë. . Ka ekziston një artikull i shkëlqyer nga Martin Fowler për ndërrimin e veçorave: për llojet, ciklet e jetës dhe të tjera. Ndërrimi i veçorave është i komplikuar.
Dhe akoma nuk e ke përgjigjur pyetjen: «A është i nevojshëm Jenkins apo jo?»
Jenkins në të vërtetë nuk është aspak i nevojshëm. Nëse flasim seriozisht, mjetet: Jenkins, Gitlab do t'ju sjellin lehtësi. Do të shihni nëse ndërtimi është krejtësisht funksional apo jo. Ato mund t'ju ndihmojnë, por nuk do t'ju sjellin praktikë. Ato mund t'ju japin vetëm një dizenjim – OK, jo OK. Dhe këtë nëse dëgjoni të gjithë testet, sepse nëse nuk keni teste, atëherë ka pak kuptim. Prandaj është i nevojshëm, sepse është më e lehtë, por në përgjithësi mund të jetoni edhe pa të, nuk do të humbni shumë.
Pra, nëse keni praktika, do të thotë që ai nuk është i nevojshëm për ju?
E gjitha është e saktë. Unë rekomandoj testin Jez Humble. Atje kam një qëndrim të dyshimtë për pikën e fundit. Por në përgjithësi, nëse keni tre gjëra: ju bashkoni vazhdimisht, ju ekzekutoni testet për commitet në master, shpejt rregulloni ndërtimin në master, atëherë ndoshta nuk keni nevojë për asgjë tjetër.
Ndërkohë që presim pyetje nga pjesëmarrësit, kam një pyetje. Tani po flisnim për kodin produktor. A ke përdorur kodin për infrastrukturën? A është i njëjtë me kodin e produktit, a ka të njëjtin cikël jete dhe të njëjtat parime, apo ka cikle dhe parime të tjera? Zakonisht, kur flisni për Continuous Integration dhe Development, harrohet se ekziston edhe kodi i infrastrukturës. Dhe vitet e fundit, ai po bëhet gjithnjë e më shumë i rëndësishëm. A duhet të sjellim të gjitha këto rregulla aty?
Nuk është se duhet, por do të ishte e shkëlqyer, sepse do ta thjeshtonte jetën. Sa herë që punojmë me kod, jo me skriptet e bash, por kemi një kod të rregullt.
Prit, prit, skriptet në bash – janë gjithashtu kod. Mos e prek dashurinë time të vjetër.
Mirë, nuk do të shkelë në kujtimet e tua. Kam një antipati personale për bash. Ai thyen në mënyrë të çrregullt dhe është gjithmonë i frikshëm. Dhe thyen shpesh pa pritshmëri, prandaj nuk e dua shumë. Mirë, le të themi që ke kod në bash. Ndoshta, nuk e di nëse ka struktura të mira për testimin atje. Nuk jam në temë. Dhe ne 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ë kam hasur një situatë kur një koleg më dërgoi një kërkesë për të bashkuar 1,000 rreshta në bash. Dhe ti ngelesh në rishikim për 4 orë. Problemet janë të njëjta. Është akoma kod. Dhe akoma punë në grup. Ne ngecim me kërkesat për bashkimin dhe ngecim me konfliktet e bashkimit të njëjtë të bash-it, për shembull.
Tani jam duke e ndjekur këtë proces në programimin më të bukur të infrastrukturës. Kam integruar Pulumi në infrastrukturë. Kjo është programim e pastër. Atje është edhe më e bukur, sepse kam të gjitha mundësitë e gjuhës së programimit, pra kam bërë ndërrimet e bukura me if-at, dhe gjithçka është në rregull. Pra, ndryshimi im është tashmë në master. Të tjerët e dinë për të. Ai tashmë ka ndikuar ndonjëherë. Por gjithashtu është aktivizuar jo për të gjitha infrastrukturat. Është aktivizuar për ambientet e mia testuese, për shembull. Prandaj, duke u përgjigjur pyetjes tënde përsëri, është e nevojshme. Na thjeshton jetën si inxhinierë që punojmë me kod.
Nëse ndonjë i pranishëm ka pyetje tjetër?
Kam një pyetje. Dua të vazhdoj diskutimin me Olegun. Në përgjithësi mendoj se ke të drejtë, kur ndonjëherë një detyrë zgjat një muaj, atëherë ke një problem me arkitekturën, ke një problem me analizën, dekompozimin, planifikimin etj. Por kam ndjesinë se nëse fillon të jetosh sipas Continuous Integration, do të fillosh të rregullosh problemet me planifikimin, sepse nuk ka asnjë mënyrë tjetër që ti t'i shpëtosh.
(Oleg) Po, gjithçka është ashtu. Sa i përket mundësisë së punës, kjo praktikë është e barabartë me çdo praktikë tjetër serioze që ndryshon kulturën. Gjëja më e vështirë për t'u kapërcyer janë zakonet, sidomos, zakonet e këqija. Dhe nëse për të vendosur këtë praktikë kërkohet një ndryshim serioz i zakoneve të atyre rreth jush: zhvilluesve, drejtuesve, menaxherëve të prodhimit, do të keni surpriza.
Cilat mund të jenë surprizat? Imagjinoni se keni vendosur të bëni shpesh integrim. Dhe në integrim, ju keni lidhur disa gjëra të tjera, si artefaktet. Dhe në kompaninë tuaj, për shembull, ka një politikë që çdo artefakt duhet të regjistrohet në një sistem të ruajtjes së artefakteve. Dhe kjo merr një sasi kohe. Njerëzit duhet të shënojnë që si menaxher versioni e kanë provuar këtë artefakt për gatishmërinë për ta depozituar në production. Nëse kjo merr 5-10-15 minuta, por ju e bëni depozitimin një herë në javë, atëherë një herë në javë të kaloni gjysmë ore është një taksë e vogël.
Nëse ju bëni Continuous Integration 10 herë në ditë, atëherë duhet të shumëzoni 10 herë me 30 minuta. Dhe kjo e tejkalon sasinë e kohës së punës së atij menaxheri të versionit. Ai thjesht lodhet ta bëjë këtë. Ka kosto të vazhdueshme për disa praktika. Dhe gjithçka.
Dhe ju duhet ose ta anuloni këtë rregull, që të mos përfshiheni më në këtë punë, që do të thotë se nuk i jepni manualisht një gradë për përputhshmëri të diçkaje me diçka tjetër. Ju mbështeteni 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ë production pa atë që Vasia nuk tha, që ai lejon dhe kështu me radhë - e gjitha kjo pengon praktikat. Sepse nëse ka aktivitete të lidhura si taksë, atëherë gjithçka rritet 100 herë. Prandaj, ndryshimi shpesh nuk do të pranohet me gëzim nga të gjithë. Sepse është e vështirë të ndryshosh zakonat e njerëzve.
Kur një njeri bën punën e zakonshme, ai e bën atë pothuajse pa menduar. Ngarkesa e tij njohëse është zero. Ai thjesht e bën atë, sepse ka një listë kontrolli në kokë, e ka bërë këtë një mijë herë. Dhe sa herë që i thua: "Le të anulojmë këtë praktikë dhe nga e hëna të zbatojmë një të re," për të kjo bëhet një ngarkesë njohëse e fuqishme. Ndërsa ajo ndodh për të gjithë menjëherë.
Prandaj, më e thjeshta është, megjithatë, këtë luks nuk e kanë të gjithë, por unë gjithmonë veproj kështu. Nëse nisi një projekt të ri, zakonisht të gjitha praktikat e pabesueshme shtyhen menjëherë në këtë projekt. Deri sa projekti është i ri, ne nuk rrezikojmë shumë. Prod nuk ekziston ende, nuk ka asgjë për të shkatërruar. Prandaj, mund të përdoret si trajnim. Ky qasje funksionon. Por nuk të gjitha kompanitë kanë mundësi të nisin projekte të tilla shpesh. Megjithatë, është pak e çuditshme, sepse tani po zhvillohet një transformim digjital, të gjithë duhet të fillojnë eksperimentet për të mbetur në konkurrencë.
Këtu ju pengoni në faktin se së pari duhet të keni një kuptim se çfarë keni nevojë të bëni. Bota nuk është ideale, prodhimi gjithashtu nuk është ideal.
Po, këto gjëra janë të lidhura.
Biznesi gjithashtu nuk ka gjithmonë një kuptim se ku duhet të shkojë.
Ka situata kur asnjë ndryshim nuk është i mundur. Kjo është një situatë kur ka një presion më të madh mbi ekipin. Ekipi tashmë është i lodhur. Ai nuk ka asnjë kohë të lirë për eksperimentet. Ata punojnë nga mëngjesi deri në mbrëmje për të punuar karakteristika. Dhe drejtuesi po kërkon më shumë karakteristika. Kështu që në atë situatë, asnjë ndryshim nuk është i mundur. Ekipit mund t'u thuhet vetëm, se nesër do të bëjmë si dje, thjesht duhet të bëjmë pak më shumë karakteristika. Çdo kalim në praktika të tjera në këtë kuptim nuk është i mundur. Kjo është një situatë klasike, kur nuk ka kohë për të mbushur axhenda, duhet të pritet druri, kështu që e bëjnë me së fundi një shkurt. Këtu nuk ka këshillash të thjeshta.
(Dmitri) Do të lexoj një sqarim nga çati: "Por ju nevojitet mbulimi i madh me teste në nivele të ndryshme. Sa kohë i kushtohet testeve? Duket sikur është shumë e kushtueshme, merr shumë kohë."
(Oleg) Kjo është një keqkuptim klasik. Testet duhet të jenë të mjaftueshme që ju të keni besimin tuaj. Continuous Integration nuk është diçka, ku së pari shkojnë 100% teste dhe vetëm pastaj filloni të përdorni këtë praktikë. Continuous Integration ul ngarkesën njohëse për ju, sepse çdo ndryshim që e shihni me sy është aq i qartë që ju e kuptoni nëse do ta thyejë diçka apo jo, edhe pa teste. Ju mund ta provoni shpejt në mendjen tuaj, sepse janë ndryshime të vogla. Edhe nëse keni vetëm testues manualë, atyre gjithashtu iu bëhet më e lehtë. Ju e nxorët dhe thoni: "A doli gjithçka mirë?" Ata kontrollojnë dhe thonë: "Po, gjithçka është mirë." Sepse testuesi di se ku të shikojë. Një komit është i lidhur me një fragment të caktuar të kodit. Dhe kjo është eksploruar me një sjellje të caktuar.
Këtu, sigurisht, ti e ke bërë më të bukur.
(Dmitri) Këtu nuk pajtohem. Ka praktikë — zhvillim përmes testimit, e cila do t'ju mbajë larg këtij problemi.
(Oleg) Ja, unë ende nuk kam arritur deri këtu. Iluzioni i parë është se duhet të shkruani 100% teste ose të mos merremi fare me Continuous Integration. Kjo nuk është e vërtetë. Këto janë dy praktika paralele. Dhe ato nuk varen drejtpërdrejt nga njëra-tjetra. Mbulesa juaj me teste duhet të jetë optimale. Optimale do të thotë që ju të jeni të sigurt se cilësia e variantit master, që ka mbetur pas commit-it tuaj, ju lejon të shtypni me besim butonin „Deploy“ të premten në mbrëmje kur jeni nën ndikimin e alkoolit. Si e arrini këtë? Nëpërmjet revistave, mbulimit, përmes monitorimit të mirë.
Monitorimi i mirë nuk është i ndryshëm nga testet. Nëse ju ekzekutoni testet një herë në pre prodhim, ato kontrollojnë një herë të gjitha skenaret tuaj të përdoruesve dhe kaq. Por nëse i ekzekutoni ato në një cikël të pafund, atëherë kjo është sistemi juaj i monitorimit të zgjeruar, i cili teston gjithçka vazhdimisht – ra apo nuk ra. Në këtë rast, dallimi është vetëm në një herë ose shumë herë. Një set shumë i mirë testesh ..., të ekzekutuar pafundësisht, është monitorim. Dhe monitorimi i drejtë duhet të jetë i tillë.
Dhe prandaj, si do t'i arrini këto gjendje, kur të shpërndaheni të premten në mbrëmje dhe të shkoni në shtëpi, është një pyetje tjetër. Ndoshta jeni thjesht një guximtar.
Le të rikthehemi pak te Continuous Integration. Ne zbuluam pak në një praktikë të ndërlikuar tjetër.
Dhe iluzioni i dytë është se MVP, njerëzit thonë se duhet të bëhet shpejt, prandaj testet nuk janë të nevojshme. Jo e gjithë vërteta. Kur ju shkruani një histori përdoruesi për MVP, mund ta zhvilloni atë ose mbi bazen e dëshmive, dmth. dëgjuat për një histori përdoruesi dhe menjëherë filloi të kodoni, ose të punoni sipas TDD. Dhe sipas praktikës TDD, koha e zhvillimit nuk është më e gjatë, dmth. testet janë një efekt anësor. Praktika TDD nuk konsiston në testim. Megjithëse quhet Zhvillim i Drejtuar nga Testet, aty flitet në të vërtetë për një qasje arkitekturore. Kjo është një qasje se si të shkruani atë që nevojitet dhe të mos shkruani atë që nuk nevojitet. Kjo praktikë përqëndrohet në iteracionin tuaj të ardhshëm në zhvillimin e mendjes për sa i përket krijimit të arkitekturës së aplikacionit.
Pra, është e vështirë të heqësh dorë nga këto iluzione. MVP dhe testet nuk e kundërshtojnë njëra-tjetrën. Përkundrazi, nëse e bëni MVP sipas praktikës TDD, do ta bëni më mirë dhe më shpejt se sa nëse do ta bëni pa praktikë, për një rezultat sipas dëshmive.
Kjo është një mendim shumë i padukshëm dhe i ndërlikuar. Kur dëgjon se tani do të shkruaj teste dhe në të njëjtën kohë do të bëj diçka më shpejt, kjo tingëllon krejtësisht e pamundur.
(Dmitri) Shumë njerëz kur flasin për MVP, kjo është sepse u duket e lodhshme të shkruajnë diçka normale. Dhe këto janë ende gjëra të ndryshme. Mos e ktheni MVP në diçka të keqe që nuk punon.
Po, po, ke të drejtë.
Dhe më pas papritur MVP në prodhim.
Përherë.
Dhe TDD tingëllon shumë e zakonshme, ku dëgjon se po shkruan teste dhe duket se po bën më shumë punë. Kjo tingëllon shumë çuditshëm, por në të vërtetë kjo ka rezultuar më shpejt dhe më tërheqëse. Kur shkruan një test, tashmë mendon shumë për atë se çfarë lloji kodi do të ketë dhe si do të thirret, gjithashtu çfarë sjelljeje presim prej tij. Nuk thjesht thoni se kam shkruar një funksion dhe ai bën diçka. Fillimisht keni menduar për atë që ka këto kushte, kështu do të thirret. Ju e mbuloni atë me teste dhe nga kjo e kuptoni se si do të duken interfaces brenda kodit tuaj. Kjo ka një ndikim të madhe në arkitekturë. Kodi juaj automatikisht bëhet më modular, sepse fillimisht përpiqeni të kuptoni se si do ta testoni dhe vetëm atëherë e shkruani atë.
Me TDD më ndodhi që në një moment angazhova një mentor për Ruby, kur isha ende programues në Ruby. Ai tha: „Le të bëj TDD.” Dhe unë mendoj: „O Zot, tani do të shkruaj diçka shtesë.” Dhe u dakorduam që gjatë dy javëve të shkruaj çdo kod funksional në Python sipas TDD. Pas dy javësh kuptova se dëshiroj të mos kthehem më mbrapa. Pas dy javësh duke përpjekur ta aplikoj kudo, kuptoni se sa është bërë më e lehtë për ju edhe thjesht të mendoni. Por këtë nuk është e dukshme, prandaj i rekomandoj të gjithëve, nëse keni ndjesinë se TDD është e vështirë, e gjatë dhe e panevojshme, provoni ta ndihmoni këtë për dy javë. Më mjaftoi dy.
(Dimitri) Mund te zhvillojmë këtë mendim nga pikëpamja e përdorimit të infrastrukturës. Para se të lancojmë diçka të re, bëjmë monitorim, e pastaj e lancojmë. Në këtë rast monitorimi ynë bëhet testim normal. Dhe ka zhvillim përmes monitorimit. Por pothuajse të gjithë thonë se është e gjatë, jam dembel, kam bërë një version të përkohshëm. Nëse e kemi bërë monitorimin siç duhet, ne kuptojmë gjendjen e sistemit CI. Dhe sistemi CI ka shumë monitorime. Ne kuptojmë gjendjen e sistemit, dimë se çfarë ka brenda. Dhe gjatë zhvillimit, ne saktësisht e bëjmë sistemin që të arrijë në gjendjen e duhur.
Këto praktika janë të njohura prej kohësh. Ne e kemi diskutuar atë katër vjet më parë. Por për katër vjet praktikisht nuk ka ndryshuar asgjë.
Por në këtë notë, propozoj të mbyllim diskutimin zyrtar.
Video (e vendosur si element mediatik, por për ndonjë arsye nuk funksionon):
Burimi: habr.com
