{"id":93885,"date":"2020-09-10T19:42:23","date_gmt":"2020-09-10T17:42:23","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/continuous-integration-kak-praktika-a-ne-jenkins-andrej-aleksandrov"},"modified":"2020-09-10T19:42:23","modified_gmt":"2020-09-10T17:42:23","slug":"continuous-integration-kak-praktika-a-ne-jenkins-andrej-aleksandrov","status":"publish","type":"post","link":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/continuous-integration-kak-praktika-a-ne-jenkins-andrej-aleksandrov","title":{"rendered":"Continuous Integration ca practic\u0103, nu Jenkins. Andrei Alexandrov","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Continuous Integration ca practic\u0103, nu Jenkins. Andrei Alexandrov\" src=\"\/wp-content\/uploads\/2020\/09\/ed8a32ae63b8dccfc8b4893ab27f1527.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>S\u0103 discut\u0103m de ce uneltele CI \u0219i CI-ul \u00een sine sunt complet diferite.<\/p>\n<p><\/p>\n<p>Ce problem\u0103 trebuie s\u0103 rezolve CI, de unde a ap\u0103rut ideea, care sunt ultimele dovezi c\u0103 func\u021bioneaz\u0103, cum putem \u00een\u021belege c\u0103 ave\u021bi cu adev\u0103rat o practic\u0103, nu doar un Jenkins instalat.<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>G\u00e2ndul de a face o prezentare despre Continuous Integration a ap\u0103rut acum un an, c\u00e2nd c\u0103utam un loc de munc\u0103 prin intermediul interviurilor. Am interac\u021bionat cu 10-15 companii, dintre care doar una a reu\u0219it s\u0103 r\u0103spund\u0103 clar ce este CI \u0219i s\u0103 explice cum au con\u0219tientizat c\u0103 nu \u00eel au. Celelalte au spus lucruri neclare despre Jenkins \ud83d\ude42 Ei bine, avem Jenkins, face build-uri, CI! \u00cen prezentare voi \u00eencerca s\u0103 explic ce este de fapt Continuous Integration \u0219i de ce Jenkins \u0219i uneltele similare au o leg\u0103tur\u0103 foarte slab\u0103 cu acest concept.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Continuous Integration ca practic\u0103, nu Jenkins. Andrei Alexandrov\" src=\"\/wp-content\/uploads\/2020\/09\/a57813a652c0d788e5a927dc8a7130ba.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>\u0218i a\u0219adar, ce \u00eei vine \u00een minte unui om c\u00e2nd aude cuv\u00e2ntul CI? Majorit\u0103\u021bii oamenilor le va veni \u00een minte Jenkins, Gitlab CI, Travis \u0219i altele.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Continuous Integration ca practic\u0103, nu Jenkins. Andrei Alexandrov\" src=\"\/wp-content\/uploads\/2020\/09\/c9799c11ba7bb7bbdb2048c2f314b22a.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Chiar \u0219i dac\u0103 c\u0103ut\u0103m pe Google, aceste unelte vor ap\u0103rea.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Continuous Integration ca practic\u0103, nu Jenkins. Andrei Alexandrov\" src=\"\/wp-content\/uploads\/2020\/09\/028ef088b28b73e7905b1666d9d53d1b.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Dac\u0103 \u00eentreb\u0103m cunoscu\u021bi, imediat dup\u0103 ce enumera uneltele, v\u0103 vor spune c\u0103 CI este atunci c\u00e2nd \u00een Pull Request-ul de pe commit se face build \u0219i se ruleaz\u0103 teste.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Continuous Integration ca practic\u0103, nu Jenkins. Andrei Alexandrov\" src=\"\/wp-content\/uploads\/2020\/09\/f37ba8f985c10900f669540e063c5e43.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Continuous Integration nu este despre unelte, nu este despre build-uri cu teste \u00een ramur\u0103! Continuous Integration este o practic\u0103 de integrare foarte frecvent\u0103 a noului cod, iar pentru a o aplica nu trebuie neap\u0103rat s\u0103 folose\u0219ti Jenkins, GitLab \u0219i altele.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Continuous Integration ca practic\u0103, nu Jenkins. Andrei Alexandrov\" src=\"\/wp-content\/uploads\/2020\/09\/c3a12b4a875050550b42714607e787c7.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>\u00cenainte s\u0103 discut\u0103m despre cum arat\u0103 un CI complet, haide\u021bi mai \u00eent\u00e2i s\u0103 ne scufund\u0103m \u00een contextul persoanelor care l-au g\u00e2ndit \u0219i s\u0103 resim\u021bim durerea pe care au \u00eencercat s\u0103 o rezolve.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Continuous Integration ca practic\u0103, nu Jenkins. Andrei Alexandrov\" src=\"\/wp-content\/uploads\/2020\/09\/2ab9c0f4dba2887fed5744c8b021b424.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>\u0218i durerea pe care o rezolvau era colaborarea \u00een echip\u0103!<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Continuous Integration ca practic\u0103, nu Jenkins. Andrei Alexandrov\" src=\"\/wp-content\/uploads\/2020\/09\/11a5f3b1075f8b8d0f169fe07adf6c91.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>S\u0103 ne uit\u0103m la exemple, cu ce dificult\u0103\u021bi se confrunt\u0103 dezvoltatorii \u00een timpul dezvolt\u0103rii \u00een echip\u0103. Iat\u0103, avem un proiect, ramura master \u00een git \u0219i doi dezvoltatori.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Continuous Integration ca practic\u0103, nu Jenkins. Andrei Alexandrov\" src=\"\/wp-content\/uploads\/2020\/09\/8138a52376e87239ff5f7b0af5cd8fee.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>\u0218i au \u00eenceput s\u0103 lucreze a\u0219a cum au f\u0103cut to\u021bi p\u00e2n\u0103 acum. Au luat o sarcin\u0103 \u00een Jira, au creat o ramur\u0103 de feature \u0219i au \u00eenceput s\u0103 scrie cod.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Continuous Integration ca practic\u0103, nu Jenkins. Andrei Alexandrov\" src=\"\/wp-content\/uploads\/2020\/09\/54720c40d9bbd9631b411a2a26c4083f.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Unul a terminat fisa mai repede \u0219i a fuzionat \u00een master.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Continuous Integration ca practic\u0103, nu Jenkins. Andrei Alexandrov\" src=\"\/wp-content\/uploads\/2020\/09\/4593dc3cf33a44bf3a4d8166be9bc5da.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Celuilalt i-a luat mai mult timp, s-a fuzionat mai t\u00e2rziu \u0219i a \u00eent\u00e2mpinat un conflict. Acum, \u00een loc s\u0103 scrie func\u021bii necesare afacerii, dezvoltatorul \u00ee\u0219i pierde timpul \u0219i energia rezolv\u00e2nd conflicte.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Continuous Integration ca practic\u0103, nu Jenkins. Andrei Alexandrov\" src=\"\/wp-content\/uploads\/2020\/09\/c947601fb1dd3b3dd64bac455dc6691a.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Cu c\u00e2t este mai complicat s\u0103 \u00eembin\u0103m caracteristica noastr\u0103 cu masterul comun, cu at\u00e2t mai mult timp ne consum\u0103 acest proces. Iar acesta este doar un exemplu destul de simplu. Este un exemplu \u00een care exist\u0103 doar 2 dezvoltatori. Imagina\u021bi-v\u0103 dac\u0103 sunt 10, 15 sau 100 de persoane \u00eentr-o companie care scriu \u00een acela\u0219i depozit. Vei \u00eennebuni \u00eencerc\u00e2nd s\u0103 rezolvi toate aceste conflicte. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Continuous Integration ca practic\u0103, nu Jenkins. Andrei Alexandrov\" src=\"\/wp-content\/uploads\/2020\/09\/16c6b8b51ae462f1e0acb966a93c0ae5.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Exist\u0103 un alt caz. Avem un master \u0219i c\u00e2\u021biva dezvoltatori care lucreaz\u0103 la ceva.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Continuous Integration ca practic\u0103, nu Jenkins. Andrei Alexandrov\" src=\"\/wp-content\/uploads\/2020\/09\/21b78ad8d0cb7cb5bded6ef9d49707c5.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Ei au creat c\u00e2te o ramur\u0103.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Continuous Integration ca practic\u0103, nu Jenkins. Andrei Alexandrov\" src=\"\/wp-content\/uploads\/2020\/09\/b85d8aa0080f08c1ad8ad83f3a9ab084.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Unul s-a integrat, totul este \u00een regul\u0103, a predat sarcina.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Continuous Integration ca practic\u0103, nu Jenkins. Andrei Alexandrov\" src=\"\/wp-content\/uploads\/2020\/09\/e96d4fd52c39089e3377ed85adeeb591.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>\u00centre timp, al doilea dezvoltator \u0219i-a predat sarcina. S\u0103 presupunem c\u0103 a trimis-o pentru revizuire. \u00cen multe companii, exist\u0103 practica de a face revizuiri. Pe de o parte, aceasta este o practic\u0103 bun\u0103 \u0219i util\u0103, pe de alt\u0103 parte, ne \u00eencetine\u0219te \u00een multe privin\u021be. Nu vom intra \u00een acest subiect, dar iat\u0103 un exemplu excelent despre ce poate duce o istorie necontrolat\u0103 cu revizuirile. Ai trimis o cerere de pull pentru revizuire. Dezvoltatorului nu-i mai r\u0103m\u00e2ne nimic de f\u0103cut. Ce \u00eencepe s\u0103 fac\u0103? \u00cencepe s\u0103 ia alte sarcini. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Continuous Integration ca practic\u0103, nu Jenkins. Andrei Alexandrov\" src=\"\/wp-content\/uploads\/2020\/09\/7b8e121be99432606056acf11e20f518.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>\u00centre timp, al doilea dezvoltator a mai f\u0103cut ceva. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Continuous Integration ca practic\u0103, nu Jenkins. Andrei Alexandrov\" src=\"\/wp-content\/uploads\/2020\/09\/ceaa5ba5b3b5014fad527362f5794e94.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Primul a finalizat a treia sarcin\u0103. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Continuous Integration ca practic\u0103, nu Jenkins. Andrei Alexandrov\" src=\"\/wp-content\/uploads\/2020\/09\/9c27663e63bb9489ecffc5a1f73abb87.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>\u0218i dup\u0103 un timp considerabil, revizuirea lui a fost testat\u0103 \u0219i \u00eencearc\u0103 s\u0103 se integreze. Ce se \u00eent\u00e2mpl\u0103? Prinde o cantitate uria\u0219\u0103 de conflicte. De ce? Pentru c\u0103 \u00een timp ce cererea lui de pull a fost \u00een revizuire, \u00een cod s-au schimbat deja multe lucruri. <\/p>\n<p><\/p>\n<p>Pe l\u00e2ng\u0103 problemele cu conflictele, exist\u0103 \u0219i problema comunic\u0103rii. Atunci c\u00e2nd ramura ta este \u00een revizuire, c\u00e2nd a\u0219teapt\u0103 ceva, c\u00e2nd ai petrecut mult timp lucr\u00e2nd la o caracteristic\u0103, \u00eencetezi s\u0103 mai urm\u0103re\u0219ti ce se schimb\u0103 \u00een baza de cod a serviciului t\u0103u. Poate c\u0103 ceea ce \u00eencerci s\u0103 rezolvi acum a fost deja solu\u021bionat ieri \u0219i po\u021bi prelua o metod\u0103 pe care s\u0103 o reutilizezi. Dar nu vei vedea asta deoarece lucrezi mereu cu o ramur\u0103 dep\u0103\u0219it\u0103. Iar aceast\u0103 ramur\u0103 dep\u0103\u0219it\u0103 duce \u00eentotdeauna la necesitatea de a rezolva conflicte de integrare. <\/p>\n<p><\/p>\n<p>Deci, se dovede\u0219te c\u0103, dac\u0103 lucr\u0103m \u00een echip\u0103, adic\u0103 nu un singur om se ocup\u0103 de depozit, ci 5-10 persoane, cu c\u00e2t mai mult \u00eent\u00e2rziem s\u0103 ad\u0103ug\u0103m codul nostru \u00een master, cu at\u00e2t mai mult suferim din cauza faptului c\u0103, \u00een cele din urm\u0103, trebuie s\u0103 integr\u0103m ceva. \u0218i cu c\u00e2t avem mai multe conflicte \u0219i lucr\u0103m cu o versiune mai veche, cu at\u00e2t mai multe probleme avem.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Continuous Integration ca practic\u0103, nu Jenkins. Andrei Alexandrov\" src=\"\/wp-content\/uploads\/2020\/09\/55c070f65a4d3838fb8c02bb9684c76b.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>A face ceva \u00eempreun\u0103 - este dureros! Ne punem mereu be\u021be \u00een roate unii altora. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Continuous Integration ca practic\u0103, nu Jenkins. Andrei Alexandrov\" src=\"\/wp-content\/uploads\/2020\/09\/b914c50aad6f3c9f97edcad7e71ba627.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Aceast\u0103 problem\u0103 a fost remarcat\u0103 cu peste 20 de ani \u00een urm\u0103. Prima men\u021biune a practicii Continuous Integration am g\u0103sit-o \u00een programarea extrem\u0103.<\/p>\n<p><\/p>\n<p>Programarea extrem\u0103 este primul framework agile. Pagina a ap\u0103rut \u00een 1996. Ideea era de a folosi anumite practici de programare, planificare \u0219i altele, pentru a face dezvoltarea c\u00e2t mai flexibil\u0103, astfel \u00eenc\u00e2t s\u0103 putem reac\u021biona mai repede la schimb\u0103ri \u0219i cerin\u021bele clien\u021bilor no\u0219tri. Acum 24 de ani au \u00eenceput s\u0103 se confrunte cu faptul c\u0103 dac\u0103 faci ceva foarte mult timp \u00een mod separat, pierzi mai mult timp datorit\u0103 conflictelor. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Continuous Integration ca practic\u0103, nu Jenkins. Andrei Alexandrov\" src=\"\/wp-content\/uploads\/2020\/09\/93a80838bdb3b297557dbf2ac7587965.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>\u00cen prezent, vom analiza expresia \u201eContinuous Integration\u201d pe cuvinte separate. Dac\u0103 traducem direct, rezultatul este integrare continu\u0103. Dar c\u00e2t de continu\u0103 este, nu este foarte clar, este de fapt foarte fragmentat\u0103. De asemenea, nu este foarte evident c\u00e2t de mult este aceasta integrare. <\/p>\n<p><\/p>\n<p>De aceea, v\u0103 aduc acum citate din programarea extrem\u0103. Vom analiza ambele cuvinte separat. <\/p>\n<p><\/p>\n<p>Integration \u2014 A\u0219a cum am spus, ne propunem ca fiecare inginer s\u0103 lucreze cu cea mai actualizat\u0103 versiune a codului, astfel \u00eenc\u00e2t codul s\u0103u s\u0103 fie ad\u0103ugat c\u00e2t mai des \u00een ramura comun\u0103, pentru a fi ramuri mici. Pentru c\u0103 dac\u0103 sunt mari, putem r\u0103m\u00e2ne cu u\u0219urin\u021b\u0103 blocati timp de o s\u0103pt\u0103m\u00e2n\u0103 din cauza conflictelor de fuziune. Este deosebit de complicat dac\u0103 avem un ciclu lung de dezvoltare tip waterfall, \u00een care dezvoltatorul a plecat timp de o lun\u0103 s\u0103 fac\u0103 o caracteristic\u0103 foarte mare. \u0218i el se va bloca mult timp \u00een etapa de integrare. <\/p>\n<p><\/p>\n<p>Integration \u2014 este atunci c\u00e2nd lu\u0103m ramura noastr\u0103 \u0219i o integr\u0103m cu ramura principal\u0103, o fuzion\u0103m. Exist\u0103 o variant\u0103 ultimativ\u0103, c\u00e2nd suntem transbase developer, unde ne propunem ca imediat s\u0103 scriem \u00een ramura principal\u0103 f\u0103r\u0103 ramuri intermediare.<\/p>\n<p><\/p>\n<p>\u00cen general, integration este s\u0103 iei codul t\u0103u \u0219i s\u0103-l aduci \u00een ramura principal\u0103. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Continuous Integration ca practic\u0103, nu Jenkins. Andrei Alexandrov\" src=\"\/wp-content\/uploads\/2020\/09\/8950103e6a59ed7132ec321ac6abe600.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Ce se \u00een\u021belege prin termenul \u201econtinuu\u201d, ce este continuitatea? Practica \u00eenseamn\u0103 c\u0103 dezvoltatorul se str\u0103duie\u0219te s\u0103 integreze codul s\u0103u c\u00e2t mai repede posibil. Aceasta este obiectivul s\u0103u \u00een \u00eendeplinirea oric\u0103rei sarcini \u2013 s\u0103 fac\u0103 astfel \u00eenc\u00e2t codul s\u0103u s\u0103 apar\u0103 \u00een master c\u00e2t mai repede. \u00centr-o lume ideal\u0103, dezvoltatorii ar face acest lucru la fiecare c\u00e2teva ore. Adic\u0103, iei o sarcin\u0103 mic\u0103, o \u00eembini \u00een master. Totul este minunat. La asta aspiri. \u0218i trebuie s\u0103 faci asta continuu. Ori de c\u00e2te ori finalizezi ceva, lo ap\u0219i imediat \u00een master. <\/p>\n<p><\/p>\n<p>Iar dezvoltatorul care face ceva este responsabil pentru ceea ce a realizat, pentru a func\u021biona \u0219i pentru a nu strica nimic. Aici de obicei apare povestea cu testele. Vrem s\u0103 r\u0103m\u00e2nem s\u0103 rul\u0103m teste pe commit-ul nostru, pe \u00eembinarea noastr\u0103, pentru a ne asigura c\u0103 func\u021bioneaz\u0103. Iar aici Jenkins poate fi de mare ajutor.<\/p>\n<p><\/p>\n<p>Dar \u00een leg\u0103tur\u0103 cu pove\u0219tile: hai s\u0103 facem modific\u0103rile mici, hai s\u0103 facem sarcinile mici \u0219i hai s\u0103 \u00eencerc\u0103m imediat s\u0103 \u00eembin\u0103m sarcina \u00een master \u2013 aici nimic nu te va ajuta, chiar \u0219i Jenkins. Pentru c\u0103 Jenkins te ajut\u0103 exclusiv s\u0103 rulezi testele. <\/p>\n<p><\/p>\n<p>Po\u021bi s\u0103 te descurci \u0219i f\u0103r\u0103 ele. Nu \u00ee\u021bi va afecta cu nimic. Pentru c\u0103 scopul practicii este s\u0103 \u00eembini c\u00e2t mai des, pentru a nu pierde o cantitate imens\u0103 de timp pe conflicte \u00een viitor. <\/p>\n<p><\/p>\n<p>S\u0103 presupunem c\u0103 avem anul 2020 f\u0103r\u0103 internet dintr-un motiv anume. \u0218i lucr\u0103m local. Nu avem Jenkins. Este \u00een regul\u0103. Po\u021bi s\u0103 \u00ee\u021bi creezi o ramur\u0103 local\u0103. \u00cen ea ai scris un cod. Ai rezolvat o sarcin\u0103 \u00een 3-4 ore. Te-ai comutat pe master, ai f\u0103cut git pull, ai \u00eembinat ramura ta. Gata. Dac\u0103 faci asta des \u2013 felicit\u0103ri, ai Continuous Integration!<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Continuous Integration ca practic\u0103, nu Jenkins. Andrei Alexandrov\" src=\"\/wp-content\/uploads\/2020\/09\/1f2117b65994b940edb04e0e119f6e8a.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Ce dovezi exist\u0103 \u00een lumea modern\u0103 c\u0103 merit\u0103 s\u0103 investe\u0219ti eforturi \u00een asta? Pentru c\u0103, \u00een general, este complicat. Dac\u0103 \u00eencerci s\u0103 lucrezi astfel, vei \u00een\u021belege c\u0103 va trebui s\u0103-\u021bi planifici mai bine timpul \u0219i s\u0103 dedici mai mult timp descompunerii sarcinilor. Pentru c\u0103 dac\u0103 vei face man..., nu vei putea s\u0103 te \u00eembini rapid \u0219i, \u00een consecin\u021b\u0103, vei fi \u00een dificultate. Practica nu va mai fi eficient\u0103. <\/p>\n<p><\/p>\n<p>\u0218i va fi scump. Nu va fi posibil s\u0103 lucr\u0103m din prima zi cu Continuous Integration. Cu to\u021bii ve\u021bi avea nevoie de mult timp pentru a v\u0103 obi\u0219nui, mult timp pentru a \u00eenv\u0103\u021ba s\u0103 decompune\u021bi sarcinile, mult timp pentru a \u00eenv\u0103\u021ba s\u0103 reface\u021bi practica de revizuire, dac\u0103 o ave\u021bi. Pentru c\u0103 obiectivul nostru este s\u0103 se fac\u0103 merge ast\u0103zi. Iar dac\u0103 face\u021bi revizuirea timp de trei zile, atunci ave\u021bi probleme \u0219i Continuous Integration nu va func\u021biona. <\/p>\n<p><\/p>\n<p>Dar avem c\u00e2teva dovezi relevante chiar acum, care ne spun c\u0103 merit\u0103 s\u0103 investim \u00een aceast\u0103 practic\u0103?<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Continuous Integration ca practic\u0103, nu Jenkins. Andrei Alexandrov\" src=\"\/wp-content\/uploads\/2020\/09\/2026a8f1d72fb05613511e7bab57e8ec.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Primul lucru care mi-a venit \u00een minte este State of DevOps. Este un studiu pe care echipa \u00eel desf\u0103\u0219oar\u0103 de 7 ani. \u00cen prezent, \u00eel fac ca organiza\u021bie independent\u0103, dar sub Google.<\/p>\n<p><\/p>\n<p>Iar studiul lor din 2018 a ar\u0103tat o corela\u021bie \u00eentre companiile care \u00eencearc\u0103 s\u0103 foloseasc\u0103 ramuri cu o durat\u0103 scurt\u0103 de via\u021b\u0103, care se integreaz\u0103 rapid, frecvent, av\u00e2nd indicatori de performan\u021b\u0103 IT mai buni.<\/p>\n<p><\/p>\n<p>Ce indicatori sunt ace\u0219tia? Sunt 4 metrici pe care le colecteaz\u0103 de la toate companiile \u00een chestionarele lor: frecven\u021ba de implementare, timpul de r\u0103spuns pentru modific\u0103ri, timpul de restaurare a serviciului, rata de e\u0219ec a modific\u0103rilor.<\/p>\n<p><\/p>\n<p>\u00cen primul r\u00e2nd, exist\u0103 aceast\u0103 corela\u021bie, \u0219tim c\u0103 companiile care se integreaz\u0103 frecvent au aceste metrici semnificativ mai bune. \u0218i exist\u0103 o clasificare a companiilor \u00een mai multe categorii: companii lente, care produc ceva \u00eencet, performer mediu, performer de \u00eenalt\u0103 calitate \u0219i elit\u0103. Elita este Netflix, Amazon, care sunt foarte rapide, fac totul repede, frumos \u0219i de calitate.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Continuous Integration ca practic\u0103, nu Jenkins. Andrei Alexandrov\" src=\"\/wp-content\/uploads\/2020\/09\/4fd98ef48a5cffdd6ae2ceea93dbb0bf.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>A doua poveste, care s-a \u00eent\u00e2mplat cu doar o lun\u0103 \u00een urm\u0103. \u00cen Technology Radar a ap\u0103rut un articol minunat despre Gitflow. Gitflow se deosebe\u0219te de toate celelalte prin faptul c\u0103 ramurile sale au o via\u021b\u0103 lung\u0103. Exist\u0103 ramuri de lansare, care tr\u0103iesc mult timp, ramuri de func\u021bionalit\u0103\u021bi, care la fel au o durat\u0103 lung\u0103 de via\u021b\u0103. Aceast\u0103 practic\u0103 \u00een Technology Radar a fost mutat\u0103 \u00een HOLD. De ce? Pentru c\u0103 oamenii se confrunt\u0103 cu dificult\u0103\u021bi \u00een integrare. <\/p>\n<p><\/p>\n<p>Dac\u0103 o ramur\u0103 tr\u0103ie\u0219te foarte mult, se blocheaz\u0103, devine \u00eenvechit\u0103, \u00eencepem s\u0103 pierdem mai mult timp pentru a face o modificare \u00een ea. <\/p>\n<p><\/p>\n<p>Recent authors of Gitflow have claimed that if you are aiming for Continuous Integration and wish to integrate as frequently as possible, then Gitflow is a poor choice. They further noted in an article that if you have a backend where you can strive for this, Gitflow is redundant for you because it will slow you down and create integration issues. <\/p>\n<p><\/p>\n<p>This does not mean that Gitflow is bad and that it shouldn't be used. It is suitable for other scenarios. For example, when you need to maintain multiple versions of a service or application, that is, when you need to provide support over an extended period. <\/p>\n<p><\/p>\n<p>However, if you talk to people who maintain such services, you will hear a lot of frustration about version 3.2, which was four months ago, and how a certain fix was missed in it, necessitating numerous changes to implement it. They find themselves stuck again, spending a week trying to merge a new feature. <\/p>\n<p><\/p>\n<p>As Alexander Kovalev correctly pointed out in the chat, correlation does not equal causation. This means that there is no direct link suggesting that having Continuous Integration will guarantee excellent metrics. However, there is a positive correlation\u2014if one exists, the other is likely to follow. It\u2019s not a certainty, but likely. It is merely correlation. <\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Continuous Integration ca practic\u0103, nu Jenkins. Andrei Alexandrov\" src=\"\/wp-content\/uploads\/2020\/09\/d5fc050550b0e9f86a1fdf85fff32fa5.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>It seems we are doing something right; we are merging, but how can we determine if we actually have Continuous Integration and if we are merging frequently enough?<\/p>\n<p><\/p>\n<p>Jez Humble is the author of the Handbook, Accelerate, the Continuous Delivery website, and the book \"Continuous Delivery.\" He proposes the following test:<\/p>\n<p><\/p>\n<ul>\n<li>An engineer's code is merged into the master branch daily. <\/li>\n<li>You run unit tests for every commit.<\/li>\n<li>If the build in the master branch fails, it is fixed in about 10 minutes.<\/li>\n<\/ul>\n<p><\/p>\n<p>He suggests using this test to confirm that you indeed have the practice in place. <\/p>\n<p><\/p>\n<p>Ceea ce consider eu pu\u021bin discutabil. Adic\u0103, dac\u0103 pute\u021bi repara \u00een 10 minute, \u00eenseamn\u0103 c\u0103 ave\u021bi Continuous Integration, ceea ce sun\u0103 pu\u021bin ciudat, \u00een opinia mea, dar are sens. De ce? Pentru c\u0103, dac\u0103 face\u021bi merge-uri frecvent, \u00eenseamn\u0103 c\u0103 schimb\u0103rile sunt mici. Dac\u0103 o mic\u0103 schimbare a dus la defectarea build-ului master, pute\u021bi g\u0103si rapid exemplul, pentru c\u0103 schimbarea e mic\u0103. A\u0219adar, a\u021bi avut un mic merge, \u00een care s-au schimbat 20-30 de linii. \u0218i, \u00een consecin\u021b\u0103, pute\u021bi \u00een\u021belege repede care a fost cauza, pentru c\u0103 modific\u0103rile sunt minuscule, ave\u021bi un domeniu foarte restr\u00e2ns pentru a c\u0103uta problema. <\/p>\n<p><\/p>\n<p>\u0218i chiar dac\u0103 dup\u0103 lansare ne distruge prod-ul, dac\u0103 avem practica Continuous Integration, ne va fi mult mai u\u0219or s\u0103 ac\u021bion\u0103m, deoarece schimb\u0103rile sunt mici. Da, asta va afecta planificarea. Va fi dureros. \u0218i, probabil, cel mai greu \u00een aceast\u0103 practic\u0103 este s\u0103 te obi\u0219nuie\u0219ti s\u0103 dezb\u0103\u021bi sarcinile, adic\u0103, cum s\u0103 faci ceva \u0219i s\u0103 finalizezi asta \u00een c\u00e2teva ore \u0219i s\u0103 treci prin revizie, dac\u0103 o ai. Revizia este o alt\u0103 durere. <\/p>\n<p><\/p>\n<p>Testele unitare sunt doar un asistent care te ajut\u0103 s\u0103 \u00een\u021belegi \u2013 dac\u0103 integrarea ta a trecut cu succes, dac\u0103 nimic nu s-a defectat. \u00cen opinia mea, acesta nu este un punct absolut obligatoriu, deoarece sensul practici nu st\u0103 \u00een acest lucru. <\/p>\n<p><\/p>\n<p>Asta e o scurt\u0103 descriere despre Continuous Integration. Asta este tot ce con\u021bine aceast\u0103 practic\u0103. Sunt deschis la \u00eentreb\u0103ri. <\/p>\n<p><\/p>\n<p>Pe scurt, voi rezuma \u00eenc\u0103 o dat\u0103:<\/p>\n<p><\/p>\n<ul>\n<li>Continuous Integration nu este Jenkins, nu este Gitlab.<\/li>\n<li>Nu este un instrument, este o practic\u0103 care presupune c\u0103 noi integr\u0103m codul nostru \u00een master c\u00e2t mai des posibil. <\/li>\n<li>Facem asta pentru a evita durerea uria\u0219\u0103 care apare cu merge-urile \u00een viitor, adic\u0103 experiment\u0103m o mic\u0103 durere acum, pentru a nu avea o mare durere mai t\u00e2rziu. Acesta este tot sensul. <\/li>\n<li>Comunica\u021bia trece prin cod, dar rar v\u0103d asta, \u00eens\u0103 pentru asta a fost g\u00e2ndit\u0103.<\/li>\n<\/ul>\n<p><\/p>\n<p><strong>\u00centreb\u0103ri<\/strong><\/p>\n<p><\/p>\n<p><em>Ce s\u0103 facem cu sarcinile nedecopozate?<\/em><\/p>\n<p><\/p>\n<p>Decopozati-le. Care este problema? Pute\u021bi s\u0103 oferi\u021bi un exemplu \u00een care exist\u0103 o sarcin\u0103 ce nu se poate decopozita?<\/p>\n<p><\/p>\n<p><em>Exist\u0103 sarcini care nu pot fi decopozitate deloc, de exemplu, cele care necesit\u0103 o expertiz\u0103 foarte profund\u0103 \u0219i care pot fi rezolvate doar pe parcursul unei luni, p\u00e2n\u0103 la un rezultat care s\u0103 fie acceptabil.<\/em> <\/p>\n<p><\/p>\n<p>Dac\u0103 te-am \u00een\u021beles corect, exist\u0103 o sarcin\u0103 mare \u0219i complex\u0103, al c\u0103rei rezultat va fi vizibil doar peste o lun\u0103?<\/p>\n<p><\/p>\n<p><em>Da, exact. Da, rezultatul poate fi evaluat nu mai devreme de o lun\u0103.<\/em> <\/p>\n<p><\/p>\n<p>Bine. \u00cen general, nu este o problem\u0103. De ce? Pentru c\u0103, \u00een acest caz, c\u00e2nd vorbim despre ramuri, nu ne referim la o ramur\u0103 cu o func\u021bionalitate. Func\u021bionalit\u0103\u021bile pot fi mari \u0219i complexe. Ele pot afecta un num\u0103r mare de componente. \u0218i, posibil, nu le putem finaliza complet \u00eentr-o singur\u0103 ramur\u0103. Este \u00een regul\u0103. Trebuie doar s\u0103 \u00eemp\u0103r\u021bim aceast\u0103 poveste. Dac\u0103 func\u021bionalitatea nu este complet gata, nu \u00eenseamn\u0103 c\u0103 anumite p\u0103r\u021bi ale codului ei nu pot fi integrate. Ai ad\u0103ugat, de exemplu, o migrare \u0219i \u00een interiorul func\u021bionalit\u0103\u021bii exist\u0103 anumite etape. Ai, de exemplu, o etap\u0103 \u2013 s\u0103 faci migrarea, s\u0103 adaugi o metod\u0103 nou\u0103. \u0218i po\u021bi deja integra aceste lucruri zilnic. <\/p>\n<p><\/p>\n<p><em>Bine. Care este, atunci, sensul acestui lucru?<\/em><\/p>\n<p><\/p>\n<p>Care este sensul de a integra lucruri mici zilnic?<\/p>\n<p><\/p>\n<p><em>Da.<\/em><\/p>\n<p><\/p>\n<p>Dac\u0103 au stricat ceva, vezi imediat. Ai o bucat\u0103 mic\u0103 care a stricat ceva, \u00ee\u021bi este mai u\u0219or s\u0103 repari asta. Sensul este c\u0103 integrarea unei buc\u0103\u021bi mici acum este mult mai u\u0219oar\u0103 dec\u00e2t integrarea unei lucruri mari dup\u0103 c\u00e2teva s\u0103pt\u0103m\u00e2ni. \u0218i al treilea sens este c\u0103 al\u021bi ingineri vor lucra cu versiunea de cod actualizat\u0103. Ei vor vedea c\u0103 aici au fost ad\u0103ugate anumite migra\u021bii, iar aici a ap\u0103rut o metod\u0103 despre care poate vor dori s\u0103 foloseasc\u0103. Toat\u0103 lumea va vedea ce se \u00eent\u00e2mpl\u0103 \u00een codul t\u0103u. Anume pentru aceste trei lucruri se face practica. <\/p>\n<p><\/p>\n<p><em>Mul\u021bumesc, \u00eentrebarea este \u00eenchis\u0103!<\/em><\/p>\n<p><\/p>\n<p><em>(Oleg Soroka) Pot s\u0103 adaug ceva? Ai spus totul corect, vreau doar s\u0103 adaug o fraz\u0103.<\/em><\/p>\n<p><\/p>\n<p>A\u0219a.<\/p>\n<p><\/p>\n<p><em>\u00cen cadrul Continuous Integration, codul se integreaz\u0103 \u00een ramura comun\u0103 nu atunci c\u00e2nd func\u021bionalitatea este complet gata, ci atunci c\u00e2nd construc\u021bia nu mai este broken. \u0218i po\u021bi s\u0103 faci commit \u00een master de c\u00e2te ori vrei pe zi. Al doilea aspect \u2013 dac\u0103 din anumite motive nu po\u021bi \u00eemp\u0103r\u021bi o sarcin\u0103 de o lun\u0103 \u00een sarcini de cel pu\u021bin trei zile, nu mai vorbesc de trei ore, \u00eenseamn\u0103 c\u0103 ai o problem\u0103 imens\u0103. \u0218i faptul c\u0103 nu ai Continuous Integration este cea mai mic\u0103 dintre aceste probleme. Asta \u00eenseamn\u0103 c\u0103 ai probleme cu arhitectura \u0219i practicile ingineresti sunt la zero. Pentru c\u0103 chiar dac\u0103 este cercetare, \u00een orice caz trebuie s\u0103 fie formulat\u0103 sub form\u0103 de ipoteze sau ciclu.<\/em> <\/p>\n<p><\/p>\n<p><em>Am discutat despre 4 metrici care diferen\u021biaz\u0103 companiile de succes de cele care stagneaz\u0103. P\u00e2n\u0103 la aceste 4 metrici mai este mult de munc\u0103. Dac\u0103 o sarcin\u0103 medie dureaz\u0103 o lun\u0103, m-a\u0219 concentra mai \u00eent\u00e2i pe aceast\u0103 metric\u0103. A\u0219 reduce timpul la 3 zile. Abia apoi a\u0219 \u00eencepe s\u0103 m\u0103 g\u00e2ndesc la Continuous.<\/em><\/p>\n<p><\/p>\n<p>Am \u00een\u021beles corect c\u0103 tu crezi c\u0103, \u00een general, nu are sens s\u0103 investe\u0219ti \u00een practici de inginerie dac\u0103 orice sarcin\u0103 dureaz\u0103 o lun\u0103?<\/p>\n<p><\/p>\n<p><em>Ai Continuous Integration. \u0218i exist\u0103 o tem\u0103 acolo, c\u0103 \u00een 10 minute po\u021bi fie s\u0103 aplici o corectare, fie s\u0103 dai \u00eenapoi. Imagineaz\u0103-\u021bi c\u0103 l-ai implementat. Mai mult, ai chiar \u0219i continuous deployment, l-ai implementat pe prod \u0219i abia apoi ai observat c\u0103 ceva nu a func\u021bionat. \u0218i trebuie s\u0103 \u00eel dai \u00eenapoi, dar deja ai avut o migrare a bazei de date. Schema bazei de date este deja actualizat\u0103, ba mai mult, poate a trecut \u0219i un backup, \u0219i deja s-au \u00eenregistrat date.<\/em><\/p>\n<p><\/p>\n<p><em>\u0218i care este alternativa ta? Dac\u0103 dai \u00eenapoi codul, atunci acesta nu mai poate func\u021biona cu aceast\u0103 baz\u0103 de date actualizat\u0103.<\/em><\/p>\n<p><\/p>\n<p>Baza se deplaseaz\u0103 doar \u00eenainte, da. <\/p>\n<p><\/p>\n<p><em>Oamenii care au practici de inginerie slabe nu au citit, cel mai probabil, nici o carte groas\u0103 despre\u2026 Ce trebuie s\u0103 faci cu backup-ul? Dac\u0103 te recupera\u021bi dintr-un backup, asta \u00eenseamn\u0103 c\u0103 pierzi datele acumulate \u00een acel moment. De exemplu, ai lucrat trei ore cu noua versiune a bazei de date, utilizatorii s-au \u00eenregistrat. Te \u00eentorci la un backup vechi, pentru c\u0103 schema nu func\u021bioneaz\u0103 cu noua versiune, a\u0219a c\u0103 ai pierdut ace\u0219ti utilizatori. \u0218i ei sunt nemul\u021bumi\u021bi, se pl\u00e2ng.<\/em><\/p>\n<p><\/p>\n<p><em>Pentru a st\u0103p\u00e2ni \u00eentregul spectru de practici care sus\u021bin Continuous Integration \u0219i Continuous Delivery, nu este suficient s\u0103 \u00eenve\u021bi pur \u0219i simplu s\u0103 scrii \u2026. \u00cen primul r\u00e2nd, acestea pot deveni foarte multe, ceea ce va fi impractic. \u00cen plus, exist\u0103 o gr\u0103mad\u0103 de alte practici, cum ar fi cele \u0219tiin\u021bifice. Exist\u0103 o astfel de practic\u0103, pe care GitHub a popularizat-o la un moment dat. Este atunci c\u00e2nd ai codul vechi \u0219i codul nou care ruleaz\u0103 simultan. Este atunci c\u00e2nd faci o caracteristic\u0103 incomplet\u0103, dar aceasta poate returna un anumit rezultat: fie ca func\u021bie, fie ca Rest API. Tu rulezi at\u00e2t codul vechi, c\u00e2t \u0219i codul nou, \u0219i compari diferen\u021ba dintre ele. \u0218i dac\u0103 exist\u0103 o diferen\u021b\u0103, atunci \u00eenregistrezi acel eveniment. Astfel, \u0219tii c\u0103 noua ta caracteristic\u0103 este gata s\u0103 fie desf\u0103\u0219urat\u0103 peste cea veche, dac\u0103 \u00een decursul unei anumite perioade nu a existat nicio divergen\u021b\u0103 \u00eentre cele dou\u0103.<\/em> <\/p>\n<p><\/p>\n<p><em>Exist\u0103 sute de astfel de practici. A\u0219 sugera s\u0103 \u00eencepi cu transbase development. Nu este 100 % pe Continuous Integration, dar practicile sunt acelea\u0219i, unul f\u0103r\u0103 altul tr\u0103ie\u0219te prost.<\/em> <\/p>\n<p><\/p>\n<p>Ai adus transbase development ca exemplu, unde se pot observa practicile sau sugerezi oamenilor s\u0103 \u00eenceap\u0103 s\u0103 foloseasc\u0103 transbase development?<\/p>\n<p><\/p>\n<p><em>S\u0103 se uite, deoarece nu vor putea s\u0103 le foloseasc\u0103. Pentru a le utiliza, trebuie s\u0103 citeasc\u0103 mult. \u0218i c\u00e2nd \u00eentrebarea unei persoane este: \u201eCe s\u0103 fac cu o caracteristic\u0103 care dureaz\u0103 o lun\u0103?\u201d, aceasta \u00eenseamn\u0103 c\u0103 nu a citit despre transbase development. Nu a\u0219 recomanda \u00eenc\u0103. A\u0219 sugera s\u0103 te concentrezi exclusiv pe tema modului corect de a fragmenta sarcinile mari \u00een sarcini mai mici. Aceasta este, de fapt, esen\u021ba decompozi\u021biei.<\/em><\/p>\n<p><\/p>\n<p><em>Decompozi\u021bia este un instrument al arhitectului. Mai \u00eent\u00e2i facem analiza, apoi decompozi\u021bia, apoi sinteza, \u0219i apoi integrarea. Astfel, totul se \u00eembin\u0103. \u0218i pentru a ajunge la Continuous Integration, trebuie s\u0103 progres\u0103m prin decompozi\u021bie. \u00centreb\u0103rile apar \u00een prima etap\u0103, iar noi vorbim deja despre a patra etap\u0103, adic\u0103 cu c\u00e2t faci integrarea mai des, cu at\u00e2t mai bine. Este \u00eenc\u0103 devreme s\u0103 o facem, ar fi bine s\u0103 ne r\u0103zboim \u00eent\u00e2i cu monolitul nostru.<\/em> <\/p>\n<p><\/p>\n<p><em>Trebuie s\u0103 desen\u0103m c\u00e2teva s\u0103ge\u021bi \u0219i p\u0103trate pe un anumit grafic. Nu po\u021bi spune c\u0103 acum voi ar\u0103ta schema arhitectural\u0103 a unei noi aplica\u021bii \u0219i voi ar\u0103ta un p\u0103trat, \u00een interiorul c\u0103ruia este un buton verde pentru aplica\u021bie. \u00cen orice caz, vor fi mai multe p\u0103trate \u0219i s\u0103ge\u021bi. Pe orice schem\u0103 pe care am v\u0103zut-o, erau mai multe dec\u00e2t unul. De aceea, decompunerea, chiar \u0219i la nivelul reprezent\u0103rii grafice, este deja realizat\u0103. A\u0219adar, p\u0103tratele pot fi independente. Dac\u0103 nu, atunci am \u00eentreb\u0103ri mari pentru arhitect.<\/em> <\/p>\n<p><\/p>\n<p>Exist\u0103 o \u00eentrebare din chat: \u201eDac\u0103 revizuirea este obligatorie \u0219i dureaz\u0103 mult, undeva o zi sau mai mult?\u201d.<\/p>\n<p><\/p>\n<p>Ave\u021bi probleme cu practica. Nu ar trebui ca revizuirea s\u0103 dureze o zi sau mai mult. Aceasta este o poveste similar\u0103 cu \u00eentrebarea anterioar\u0103, dar pu\u021bin mai bl\u00e2nd\u0103. Dac\u0103 revizuirea dureaz\u0103 o zi, \u00eenseamn\u0103 c\u0103, cel mai probabil, este vorba despre o modificare foarte mare. Asta \u00eenseamn\u0103 c\u0103 ar trebui s\u0103 facem schimb\u0103rile mai mici. \u00cen dezvoltarea transbase, pe care Oleg a recomandat-o, exist\u0103 o poveste numit\u0103 revizuire continu\u0103. Ideea ei este c\u0103 facem cereri de pull at\u00e2t de mici inten\u021bionat, deoarece ne str\u0103duim s\u0103 ne unim constant \u0219i pu\u021bin c\u00e2te pu\u021bin. \u0218i astfel, cererea de pull schimb\u0103 o abstrac\u021bie sau 10 linii. Datorit\u0103 acestui lucru, revizuirea dureaz\u0103 c\u00e2teva minute. <\/p>\n<p><\/p>\n<p>Dac\u0103 revizuirea dureaz\u0103 o zi sau mai mult, \u00eenseamn\u0103 c\u0103 ceva nu este \u00een regul\u0103. \u00cen primul r\u00e2nd, este posibil s\u0103 ave\u021bi unele probleme cu arhitectura. Sau este un cod mare, de exemplu, de 1.000 de linii. Sau arhitectura este at\u00e2t de complicat\u0103 \u00eenc\u00e2t persoana nu o poate \u00een\u021belege. Aceasta este o problem\u0103 secundar\u0103, dar va trebui s\u0103 o rezolva\u021bi \u0219i pe aceasta. Poate c\u0103 nu este nevoie de revizuire deloc. Trebuie s\u0103 v\u0103 g\u00e2ndi\u021bi \u0219i la asta. Revizuirea este acel lucru care v\u0103 \u00eencetine\u0219te. Ea aduce unele beneficii \u00een general, dar trebuie s\u0103 \u00een\u021belege\u021bi de ce face\u021bi asta. Este pentru voi un mod rapid de a transmite informa\u021bii, este pentru voi un mod de a stabili anumite standarde? De ce ave\u021bi nevoie de ea? Pentru c\u0103 revizuirea trebuie s\u0103 fie foarte rapid\u0103 sau, \u00een general, s\u0103 fie anulat\u0103. Este ca \u00een dezvoltarea transbase \u2013 o poveste foarte frumoas\u0103, dar numai pentru echipele mature. <\/p>\n<p><\/p>\n<p>Referitor la cele 4 metrici, a\u0219 recomanda totu\u0219i s\u0103 le captura\u021bi, pentru a \u00een\u021belege la ce duc. S\u0103 ne uit\u0103m la cifre, s\u0103 vedem imaginea, c\u00e2t de r\u0103u este totul. <\/p>\n<p><\/p>\n<p><em>(Dmitry) Sunt gata s\u0103 intru \u00een discu\u021bie pe acest subiect cu tine. Numerele \u0219i metricile sunt grozave, practicile sunt grozave. Dar trebuie s\u0103 \u00een\u021belegem dac\u0103 sunt necesare pentru afacere. Exist\u0103 afaceri pentru care nu este necesar\u0103 o vitez\u0103 at\u00e2t de mare de schimbare. Cunosc companii \u00een care nu se pot face schimb\u0103ri la fiecare 15 minute. \u0218i nu pentru c\u0103 ar fi rele. Este un ciclu de via\u021b\u0103. \u0218i pentru a implementa func\u021bionalit\u0103\u021bi de ramuri, func\u021bionalit\u0103\u021bi toggle, sunt necesare cuno\u0219tin\u021be profunde.<\/em> <\/p>\n<p><\/p>\n<p>Este complicat. Dac\u0103 vrei s\u0103 cite\u0219ti o poveste despre func\u021bionalitatea toggle mai \u00een detaliu, \u00ee\u021bi recomand cu c\u0103ldur\u0103. <noindex><a rel=\"nofollow\" href=\"https:\/\/trunkbaseddevelopment.com\/\">https:\/\/trunkbaseddevelopment.com\/<\/a><\/noindex>. \u0218i exist\u0103 un articol minunat de Martin Fowler despre func\u021biile toggle: despre tipurile existente, ciclurile de via\u021b\u0103 etc. Func\u021bionalitatea toggle este complicat\u0103. <\/p>\n<p><\/p>\n<p><em>\u0218i totu\u0219i, nu ai r\u0103spuns la \u00eentrebare: \"Este necesar Jenkins sau nu?\"<\/em><\/p>\n<p><\/p>\n<p>Jenkins nu este necesar \u00een niciun caz de fapt. Dac\u0103 vorbim serios, instrumentele: Jenkins, Gitlab \u00ee\u021bi vor aduce confort. Vei vedea dac\u0103 build-ul a fost realizat sau nu. Ele te pot ajuta, dar nu \u00ee\u021bi vor aduce practica. Ele \u00ee\u021bi pot da doar un cerc \u2013 Ok, nu Ok. \u0218i asta, dac\u0103 scrii teste, pentru c\u0103 dac\u0103 nu ai teste, devine aproape inutil. A\u0219a c\u0103 este necesar, pentru c\u0103 este mai comod, dar \u00een general po\u021bi tr\u0103i \u0219i f\u0103r\u0103 el, nu vei pierde mult. <\/p>\n<p><\/p>\n<p><em>Deci, dac\u0103 ai practici, \u00eenseamn\u0103 c\u0103 nu ai nevoie de el?<\/em><\/p>\n<p><\/p>\n<p>Exact. Recomand testul lui Jez Humble. Am o opinie mixt\u0103 despre ultimul punct. Dar \u00een general, dac\u0103 ai trei lucruri, te unifici constant, rulezi teste la commit-uri \u00een bran\u0219\u0103, repari rapid build-ul \u00een bran\u0219\u0103, atunci, poate, nu mai ai nevoie de nimic altceva. <\/p>\n<p><\/p>\n<p><em>\u00cen timp ce a\u0219tept\u0103m \u00eentreb\u0103rile participan\u021bilor, am o \u00eentrebare. Tocmai am vorbit despre codul de produs. L-ai folosit pentru codul de infrastructur\u0103? Este acela\u0219i cod, are acelea\u0219i principii \u0219i acela\u0219i ciclu de via\u021b\u0103 sau exist\u0103 cicluri \u0219i principii diferite acolo? De obicei, c\u00e2nd toat\u0103 lumea vorbe\u0219te despre Integrarea \u0219i Dezvoltarea Continu\u0103, uit\u0103 c\u0103 exist\u0103 \u0219i cod de infrastructur\u0103. \u0218i \u00een ultima vreme, acesta devine din ce \u00een ce mai important. Ar trebui s\u0103 aducem toate aceste reguli acolo?<\/em><\/p>\n<p><\/p>\n<p>Chiar nu este vorba c\u0103 ar trebui, ar fi minunat, pentru c\u0103 cu siguran\u021b\u0103 ar simplifica via\u021ba. De \u00eendat\u0103 ce lucr\u0103m cu cod, nu cu scripturi Bash, ci avem un cod normal.<\/p>\n<p><\/p>\n<p><em>Stai-stai, un script Bash este \u0219i el cod. Nu atinge dragostea mea veche.<\/em> <\/p>\n<p><\/p>\n<p>Bine, nu voi c\u0103lca pe amintirile tale. Am o antipatie personal\u0103 fa\u021b\u0103 de bash. Se stric\u0103 \u00eentr-un mod ur\u00e2t \u0219i \u00eenfior\u0103tor tot timpul. \u0218i se stric\u0103 adesea \u00eentr-un mod imprevizibil, a\u0219a c\u0103 nu-l plac. Dar bine, s\u0103 presupunem c\u0103 ai cod \u00een bash. Poate c\u0103 chiar nu m\u0103 pricep \u0219i exist\u0103 frameworkuri normale pentru testare. Pur \u0219i simplu nu sunt la curent. \u0218i ob\u021binem acelea\u0219i avantaje.<\/p>\n<p><\/p>\n<p>De \u00eendat\u0103 ce lucr\u0103m cu infrastructura ca \u0219i cum ar fi cod, ne confrunt\u0103m cu acelea\u0219i probleme ca dezvoltatorii. Cu c\u00e2teva luni \u00een urm\u0103, am dat peste o situa\u021bie \u00een care un coleg mi-a trimis un pull request cu 1.000 de linii de bash. \u0218i tu stai blocat la revizuire timp de 4 ore. Problemele sunt acelea\u0219i. Este tot cod. \u0218i este \u00een continuare un efort colaborativ. Ne bloc\u0103m cu pull request-ul \u0219i ne \u00eempotmolim cu acelea\u0219i conflicte de fuziune ale aceluia\u0219i bash, de exemplu. <\/p>\n<p><\/p>\n<p>Acum observ aceast\u0103 \u00eentreag\u0103 chestiune la un programare c\u00e2t mai frumoas\u0103 a infrastructurii. Am integrat acum Pulumi \u00een infrastructur\u0103. Aceasta este programare \u00een purul s\u0103u sens. Acolo este \u0219i mai dr\u0103gu\u021b, deoarece am toate posibilit\u0103\u021bile limbajului de programare, adic\u0103 am realizat toggles frumoase cu acelea\u0219i if-uri pe un teren plat \u0219i totul este bine. Adic\u0103 modificarea mea este deja \u00een master. Toat\u0103 lumea o vede deja. Al\u021bi ingineri sunt la curent cu ea. A avut deja un impact asupra a ceva. Dar a fost activat\u0103 nu pentru toat\u0103 infrastructura. A fost activat\u0103 pentru standurile mele de testare, de exemplu. Prin urmare, r\u0103spunz\u00e2nd din nou la \u00eentrebarea ta, este necesar\u0103. Ne simplific\u0103 via\u021ba, ca ingineri care lucr\u0103m cu cod. <\/p>\n<p><\/p>\n<p><em>Dac\u0103 mai are cineva \u00eentreb\u0103ri?<\/em> <\/p>\n<p><\/p>\n<p>Am o \u00eentrebare. Vreau s\u0103 continui discu\u021bia cu Oleg. \u00cen general, cred c\u0103 ai dreptate, c\u0103 dac\u0103 o sarcin\u0103 dureaz\u0103 o lun\u0103, ai o problem\u0103 cu arhitectura, ai o problem\u0103 cu analiza, decompozi\u021bia, planificarea etc. Dar am senza\u021bia c\u0103, dac\u0103 \u00eencepi s\u0103 \u00eencerci s\u0103 tr\u0103ie\u0219ti conform Continuous Integration, atunci vei \u00eencepe s\u0103 corectezi durerile cu planificarea, pentru c\u0103 nu po\u021bi sc\u0103pa de asta. <\/p>\n<p><\/p>\n<p><em>(Oleg) Da, e adev\u0103rat. \u00cen ceea ce prive\u0219te efortul, aceast\u0103 practic\u0103 este comparabil\u0103 cu orice alt\u0103 practic\u0103 serioas\u0103 care schimb\u0103 cultura. Cea mai dificil\u0103 parte a dep\u0103\u0219irii este obiceiurile, \u00een special obiceiurile proaste. \u0218i dac\u0103 pentru a implementa aceast\u0103 practic\u0103 este necesar\u0103 o schimbare serioas\u0103 a obiceiurilor celor din jur: dezvoltatori, conducere, manageri de produc\u021bie, v\u0103 a\u0219teapt\u0103 surprize.<\/em> <\/p>\n<p><\/p>\n<p><em>Ce surprize ar putea s\u0103 apar\u0103? S\u0103 presupunem c\u0103 a\u021bi decis s\u0103 face\u021bi integrarea mai des. \u0218i \u00een integrare sunt legate \u0219i alte lucruri, de exemplu, artefacte. Iar \u00een compania dumneavoastr\u0103 exist\u0103 o politic\u0103 conform c\u0103reia fiecare artefact trebuie s\u0103 fie \u00eenregistrat \u00eentr-un sistem de depozitare a artefactelor. \u0218i aceasta dureaz\u0103 un anumit timp. O persoan\u0103 trebuie s\u0103 bifeze c\u0103, \u00een calitate de manager de versiune, a verificat acest artefact pentru a fi preg\u0103tit pentru publica\u021bie \u00een produc\u021bie. Dac\u0103 dureaz\u0103 5-10-15 minute, dar \u00een acela\u0219i timp face\u021bi livr\u0103ri o dat\u0103 pe s\u0103pt\u0103m\u00e2n\u0103, atunci a pierde o jum\u0103tate de or\u0103 o dat\u0103 pe s\u0103pt\u0103m\u00e2n\u0103 este un impozit mic.<\/em> <\/p>\n<p><\/p>\n<p><em>Dac\u0103 face\u021bi Continuous Integration de 10 ori pe zi, atunci trebuie s\u0103 \u00eenmul\u021bi\u021bi 10 cu 30 de minute. \u0218i aceasta dep\u0103\u0219e\u0219te timpul de lucru al acestui manager de versiune. Pur \u0219i simplu se obose\u0219te s\u0103 fac\u0103 acest lucru. Exist\u0103 cheltuieli constante pentru anumite practici. \u0218i acesta este tot.<\/em> <\/p>\n<p><\/p>\n<p><em>\u0218i trebuie fie s\u0103 anula\u021bi aceast\u0103 regul\u0103, astfel \u00eenc\u00e2t s\u0103 nu mai face\u021bi astfel de lucruri, adic\u0103 s\u0103 nu mai atribui\u021bi manual un grad de conformitate a ceva cu altceva. V\u0103 baza\u021bi complet pe un set automatizat de teste de preg\u0103tire.<\/em> <\/p>\n<p><\/p>\n<p><em>\u0218i dac\u0103 ave\u021bi nevoie de o aprobat\u0103 de la cineva, astfel \u00eenc\u00e2t \u0219eful s\u0103 semneze, \u0219i nu intra\u021bi \u00een produc\u021bie f\u0103r\u0103 ca Vasya s\u0103 fi spus c\u0103 permite \u0219i a\u0219a mai departe \u2013 toate aceste prostii stau \u00een calea practic\u0103. Deoarece, dac\u0103 exist\u0103 activit\u0103\u021bi legate de o povar\u0103, atunci totul se amplific\u0103 de 100 de ori. Prin urmare, schimbarea va fi adesea perceput\u0103 cu re\u021binere de c\u0103tre to\u021bi. Pentru c\u0103 obiceiurile oamenilor sunt greu de corectat.<\/em> <\/p>\n<p><\/p>\n<p><em>C\u00e2nd o persoan\u0103 \u00ee\u0219i \u00eendepline\u0219te sarcinile obi\u0219nuite, le face aproape f\u0103r\u0103 s\u0103 se g\u00e2ndeasc\u0103. Carga sa cognitiv\u0103 este zero. Pur \u0219i simplu execut\u0103 pas cu pas, are deja un checklist \u00een minte, l-a f\u0103cut de o mie de ori. \u0218i de \u00eendat\u0103 ce vii \u0219i \u00eei spui: \u201eHai s\u0103 anul\u0103m aceast\u0103 practic\u0103 \u0219i de luni s\u0103 implement\u0103m una nou\u0103\u201d devine pentru el o mare povar\u0103 cognitiv\u0103. \u00cen plus, aceast\u0103 povar\u0103 se instaleaz\u0103 simultan pentru to\u021bi.<\/em> <\/p>\n<p><\/p>\n<p><em>A\u0219adar, cel mai simplu, de fapt, aceast\u0103 luxurie nu o poate permite oricine, dar eu \u00eentotdeauna fac a\u0219a, acesta este urm\u0103torul lucru. Dac\u0103 \u00eencepe un nou proiect, de obicei toate practicile neexperimentate sunt imediat integrate \u00een acest proiect. At\u00e2t timp c\u00e2t proiectul este t\u00e2n\u0103r, nu risipim nimic. Prod nu exist\u0103 \u00eenc\u0103, nu este nimic de distrus. A\u0219adar, ca antrenament, se poate utiliza. Aceast\u0103 abordare func\u021bioneaz\u0103. Dar nu toate companiile au posibilitatea de a lansa astfel de proiecte frecvent. De\u0219i este pu\u021bin ciudat, deoarece acum exist\u0103 o transformare digital\u0103 constant\u0103, to\u021bi ar trebui s\u0103 lanseze experimente pentru a \u021bine pasul cu concuren\u021ba.<\/em> <\/p>\n<p><\/p>\n<p>Aici ajungi la faptul c\u0103 mai \u00eent\u00e2i trebuie s\u0103 ai o \u00een\u021belegere a ceea ce trebuie s\u0103 faci. Lumea nu este perfect\u0103, nici prod nu este perfect. <\/p>\n<p><\/p>\n<p><em>Da, aceste lucruri sunt interconectate.<\/em><\/p>\n<p><\/p>\n<p>De asemenea, companiile nu au \u00eentotdeauna \u00een\u021belegerea c\u0103 trebuie s\u0103 mearg\u0103 tocmai acolo. <\/p>\n<p><\/p>\n<p><em>Exist\u0103 o situa\u021bie \u00een care nicio schimbare nu este posibil\u0103. Este o situa\u021bie \u00een care echipa este supus\u0103 unei presiuni mai mari. Echipa este deja destul de obosit\u0103. Nu are timp suplimentar pentru experimente. Ei dezvolt\u0103 caracteristici de diminea\u021ba p\u00e2n\u0103 seara. \u0218i conducerii i se cer din ce \u00een ce mai multe caracteristici. Este nevoie de din ce \u00een ce mai multe. \u00centr-o astfel de situa\u021bie, nicio schimbare nu este posibil\u0103. Echipei i se poate spune doar c\u0103 m\u00e2ine vor face la fel ca ieri, trebuie doar s\u0103 termine pu\u021bin mai multe caracteristici. Nicio tranzi\u021bie spre alte practici nu este posibil\u0103 \u00een acest sens. Este o situa\u021bie clasic\u0103, \u00een care nu este timp pentru a ascu\u021bi toporul, trebuie doar s\u0103 tai copacii, a\u0219a c\u0103 taie cu un topor bont. Aici nu exist\u0103 sfaturi simple.<\/em> <\/p>\n<p><\/p>\n<p><em>(Dmitrii) Voi citi o clarificare din chat: \u201eDar este necesar un mare grad de acoperire prin teste la diferite niveluri. C\u00e2t timp este dedicat test\u0103rii? Pare destul de scump, ia mult timp.\u201d<\/em><\/p>\n<p><\/p>\n<p><em>(Oleg) Aceasta este o concep\u021bie gre\u0219it\u0103 clasic\u0103. Trebuie s\u0103 existe suficiente teste pentru a avea \u00eencredere \u00een propriile abilit\u0103\u021bi. Integrarea Continu\u0103 nu este ceva unde trebuie s\u0103 ai 100% teste \u00eenainte de a \u00eencepe s\u0103 aplici aceast\u0103 practic\u0103. Integrarea Continu\u0103 \u00ee\u021bi reduce \u00eenc\u0103rc\u0103tura cognitiv\u0103 prin faptul c\u0103 fiecare modificare pe care o vezi cu ochii este at\u00e2t de evident\u0103 \u00eenc\u00e2t po\u021bi \u00een\u021belege dac\u0103 va provoca sau nu o problem\u0103, chiar \u0219i f\u0103r\u0103 teste. Po\u021bi testa rapid \u00een capul t\u0103u, deoarece modific\u0103rile sunt mici. Chiar \u0219i dac\u0103 ai doar testeri manuali, le este \u0219i lor mai u\u0219or. Ai lansat \u0219i ai spus: \u201eUit\u0103-te, nu s-a stricat nimic?\u201d. Ei verific\u0103 \u0219i spun: \u201eNu, nu s-a stricat nimic\u201d. Deoarece testerul \u0219tie unde s\u0103 se uite. Ai un commit legat de un singur fragment de cod. \u0218i acesta este exploatat printr-un comportament specific.<\/em><\/p>\n<p><\/p>\n<p>Aici ai, desigur, exagerat. <\/p>\n<p><\/p>\n<p><em>(Dmitry) Aici nu sunt de acord. Exist\u0103 practica dezvolt\u0103rii prin testare, care te va salva tocmai de asta.<\/em> <\/p>\n<p><\/p>\n<p><em>(Oleg) Aici nu am ajuns \u00eenc\u0103. Prima iluzie este c\u0103 trebuie s\u0103 scrii exact 100% teste sau s\u0103 nu te ocupi deloc de Integrarea Continu\u0103. Asta este fals. Acestea sunt dou\u0103 practici paralele \u0219i nu depind direct una de cealalt\u0103. Acoperirea ta cu teste ar trebui s\u0103 fie optim\u0103. Optim\u0103 \u00eenseamn\u0103 c\u0103 tu \u00eensu\u021bi e\u0219ti sigur c\u0103 calitatea maestrului, a\u0219a cum a r\u0103mas dup\u0103 commit, \u00ee\u021bi permite s\u0103 ape\u0219i butonul \u201eDeploy\u201d cu \u00eencredere \u00eentr-o sear\u0103 de vineri, chiar \u0219i b\u00e2nd. Cum ajungi la asta? Prin revizuire, prin acoperire, printr-un bun monitorizare.<\/em> <\/p>\n<p><\/p>\n<p><em>O bun\u0103 monitorizare este indistinguibil\u0103 de teste. Dac\u0103 execu\u021bi teste o singur\u0103 dat\u0103 \u00eenainte de produc\u021bie, atunci ele verific\u0103 toate scenariile tale utilizator \u00eentr-o singur\u0103 trecere. Dar dac\u0103 le execu\u021bi \u00eentr-un ciclu infinit, atunci aceasta este sistemul t\u0103u extins de monitorizare, care testeaz\u0103 constant \u2013 a c\u0103zut sau nu a c\u0103zut. \u00cen acest caz, diferen\u021ba este doar \u00een unicitate sau multiplicitate. Un set foarte bun de teste care \u2026, executate continuu, este monitorizare. \u0218i monitorizarea corect\u0103 ar trebui s\u0103 fie astfel.<\/em> <\/p>\n<p><\/p>\n<p><em>\u0218i, prin urmare, cum exact vei atinge aceast\u0103 stare \u00een care te vei desploa \u00eentr-o sear\u0103 de vineri \u0219i vei merge acas\u0103, este o alt\u0103 \u00eentrebare. Poate e\u0219ti doar un nebun curajos.<\/em> <\/p>\n<p><\/p>\n<p>S\u0103 ne \u00eentoarcem pu\u021bin la Continuous Integration. Ne-am ab\u0103tut pu\u021bin \u00eentr-o alt\u0103 practic\u0103 complicat\u0103. <\/p>\n<p><\/p>\n<p><em>\u0218i a doua iluzie este c\u0103 MVP trebuie realizat rapid, deci nu sunt necesare teste. Nu este chiar a\u0219a. C\u00e2nd scrii user story pentru MVP, o po\u021bi dezvolta fie pe negru, adic\u0103 ai auzit de o user story \u0219i ai \u00eenceput imediat s\u0103 o codifici, fie s\u0103 lucrezi conform TDD. Iar conform TDD, cum arat\u0103 practica, nu dureaz\u0103 mai mult, deci testele sunt un efect secundar. Practica TDD nu vizeaz\u0103 testarea. De\u0219i se nume\u0219te Test Driven Development, nu este vorba \u00een mod real despre teste. Este mai degrab\u0103 o abordare arhitectural\u0103. Este o metod\u0103 de a scrie exact ceea ce este necesar, f\u0103r\u0103 a scrie lucruri inutile. Aceast\u0103 practic\u0103 se concentreaz\u0103 pe urm\u0103toarea itera\u021bie a dezvolt\u0103rii tale \u00een ceea ce prive\u0219te arhitectura aplica\u021biei.<\/em> <\/p>\n<p><\/p>\n<p><em>De aceea, nu este at\u00e2t de simplu s\u0103 scapi de aceste iluzii. MVP \u0219i teste nu se contrazic reciproc. Chiar, din contr\u0103, dac\u0103 realizezi un MVP conform practicii TDD, o vei face mai bine \u0219i mai repede dec\u00e2t dac\u0103 nu aplici deloc practica, lucr\u00e2nd pe negru.<\/em><\/p>\n<p><\/p>\n<p>Este o idee foarte subtil\u0103 \u0219i complicat\u0103. C\u00e2nd auzi c\u0103 acum trebuie s\u0103 scrii teste \u0219i c\u0103, \u00een acela\u0219i timp, vei face ceva mai repede, pare absolut neloial. <\/p>\n<p><\/p>\n<p><em>(Dmitri) Multe persoane, c\u00e2nd vorbesc despre MVP, sunt pur \u0219i simplu lene\u0219e s\u0103 scrie ceva de calitate. \u0218i, totu\u0219i, aceste lucruri sunt diferite. Nu trebuie s\u0103 transformi MVP \u00eentr-o lucrare proast\u0103 care nu func\u021bioneaz\u0103.<\/em> <\/p>\n<p><\/p>\n<p>Da, ai dreptate.<\/p>\n<p><\/p>\n<p><em>\u0218i apoi, brusc, MVP ajunge \u00een produc\u021bie.<\/em><\/p>\n<p><\/p>\n<p>Pentru totdeauna. <\/p>\n<p><\/p>\n<p>\u0218i TDD sun\u0103 foarte neobi\u0219nuit, c\u00e2nd asculti c\u0103 scrii teste \u0219i, pe deasupra, faci mai mult\u0103 munc\u0103. Pare foarte ciudat, dar, de fapt, rezult\u0103 c\u0103 se face mai repede \u0219i mai frumos. C\u00e2nd scrii un test, deja \u00een minte \u00ee\u021bi faci multe g\u00e2nduri despre ce cod s\u0103 scrii \u0219i cum va fi apelat, precum \u0219i ce comportament a\u0219tept\u0103m de la el. Nu spui doar c\u0103 ai scris o anumit\u0103 func\u021bie \u0219i ea face ceva. Te-ai g\u00e2ndit mai \u00eent\u00e2i c\u0103 are anumite condi\u021bii, va fi apelat\u0103 \u00eentr-un anumit fel. Acoperi aceste aspecte cu teste \u0219i din asta \u00een\u021belegi cum vor ar\u0103ta interfe\u021bele din codul t\u0103u. Acest lucru influen\u021beaz\u0103 foarte mult arhitectura. Codul t\u0103u devine automat mai modular, deoarece mai \u00eent\u00e2i \u00eencerci s\u0103 \u00een\u021belegi cum s\u0103 \u00eel testezi, \u0219i abia apoi \u00eel scrii. <\/p>\n<p><\/p>\n<p>Am avut astfel de experien\u021be cu TDD, \u00eenc\u00e2t, la un moment dat, am angajat un mentor pentru Ruby, c\u00e2nd \u00eenc\u0103 eram programator Ruby. \u0218i el spune: \u201eHai s\u0103 aplici TDD\u201d. M-am g\u00e2ndit: \u201eWow, acum trebuie s\u0103 scriu ceva \u00een plus\u201d. Ne-am \u00een\u021beles c\u0103, timp de dou\u0103 s\u0103pt\u0103m\u00e2ni, voi scrie tot codul func\u021bional \u00een Python folosind TDD. Dup\u0103 dou\u0103 s\u0103pt\u0103m\u00e2ni, am realizat c\u0103 nu vreau s\u0103 m\u0103 \u00eentorc \u00eenapoi. \u00cencerc\u00e2nd s\u0103 aplic asta \u00een tot ce fac, \u00een\u021belegi c\u00e2t de mult \u00ee\u021bi simplific\u0103 g\u00e2ndirea. Dar nu este evident, a\u0219a c\u0103 recomand tuturor s\u0103 \u00eencerce TDD timp de dou\u0103 s\u0103pt\u0103m\u00e2ni. Mie mi-au fost suficiente dou\u0103 s\u0103pt\u0103m\u00e2ni pentru asta.<\/p>\n<p><\/p>\n<p><em>(Dmitri) Putem extinde aceast\u0103 idee din perspectiva exploat\u0103rii infrastructurii. \u00cenainte de a lansa ceva nou, facem monitorizare \u0219i abia apoi lans\u0103m. \u00cen acest caz, monitorizarea devine un test normal. \u0218i exist\u0103 dezvoltare prin monitorizare. Dar aproape toat\u0103 lumea spune c\u0103 dureaz\u0103 prea mult, c\u0103 este obositor, c\u0103 a f\u0103cut un draft temporar. Dac\u0103 am realizat o monitorizare corect\u0103, \u00een\u021belegem starea sistemului CI. Iar \u00een sistemul CI exist\u0103 mult\u0103 monitorizare. \u00cen\u021belegem starea sistemului \u0219i ceea ce se afl\u0103 \u00een interiorul s\u0103u. \u0218i \u00een timpul dezvolt\u0103rii, tocmai construim sistemul pentru a ajunge la starea dorit\u0103.<\/em> <\/p>\n<p><\/p>\n<p><em>Aceste practici sunt cunoscute de mult timp. Le-am discutat acum aproximativ 4 ani. Dar \u00een 4 ani aproape nimic nu s-a schimbat.<\/em> <\/p>\n<p><\/p>\n<p><em>Dar pe aceast\u0103 not\u0103 sugerez s\u0103 \u00eencheiem discu\u021bia oficial\u0103.<\/em><\/p>\n<p><\/p>\n<p>Video (inserat ca element media, dar dintr-un motiv oarecare nu func\u021bioneaz\u0103):<\/p>\n<p>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/youtu.be\/zZ3qXVN3Oic\">https:\/\/youtu.be\/zZ3qXVN3Oic<\/a><\/noindex><br \/>\n<br \/>Sursa: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/518406\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041e\u0431\u0441\u0443\u0434\u0438\u043c \u043f\u043e\u0447\u0435\u043c\u0443 CI-\u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442\u044b \u0438 CI \u2013 \u044d\u0442\u043e \u0441\u043e\u0432\u0441\u0435\u043c \u043f\u0440\u043e \u0440\u0430\u0437\u043d\u043e\u0435. \u041a\u0430\u043a\u0443\u044e \u0431\u043e\u043b\u044c CI \u043f\u0440\u0438\u0437\u0432\u0430\u043d\u043e \u0440\u0435\u0448\u0438\u0442\u044c, \u043e\u0442\u043a\u0443\u0434\u0430 \u0432\u043e\u0437\u043d\u0438\u043a\u043b\u0430 \u0438\u0434\u0435\u044f, \u043a\u0430\u043a\u0438\u0435 \u043f\u043e\u0441\u043b\u0435\u0434\u043d\u0438\u0435 \u043f\u043e\u0434\u0442\u0432\u0435\u0440\u0436\u0434\u0435\u043d\u0438\u044f \u0447\u0442\u043e \u043e\u043d\u043e \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442, \u043a\u0430\u043a \u043f\u043e\u043d\u044f\u0442\u044c \u0447\u0442\u043e \u0443 \u0432\u0430\u0441 \u0435\u0441\u0442\u044c \u0438\u043c\u0435\u043d\u043d\u043e \u043f\u0440\u0430\u043a\u0442\u0438\u043a\u0430, \u0430 \u043d\u0435 \u043f\u0440\u043e\u0441\u0442\u043e \u0443\u0441\u0442\u0430\u043d\u043e\u0432\u043b\u0435\u043d\u043d\u044b\u0439 Jenkins. \u041c\u044b\u0441\u043b\u044c \u0441\u0434\u0435\u043b\u0430\u0442\u044c \u0434\u043e\u043a\u043b\u0430\u0434 \u043f\u0440\u043e Continuous Integration \u043f\u043e\u044f\u0432\u0438\u043b\u0430\u0441\u044c \u0435\u0449\u0435 \u0433\u043e\u0434 \u043d\u0430\u0437\u0430\u0434, \u043a\u043e\u0433\u0434\u0430 \u044f \u0445\u043e\u0434\u0438\u043b \u043f\u043e \u0441\u043e\u0431\u0435\u0441\u0435\u0434\u043e\u0432\u0430\u043d\u0438\u044f\u043c \u0438\u0441\u043a\u0430\u043b \u0440\u0430\u0431\u043e\u0442\u0443. \u041f\u043e\u043e\u0431\u0449\u0430\u043b\u0441\u044f [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":93886,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-93885","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.2.1 - aioseo.com -->\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/continuous-integration-kak-praktika-a-ne-jenkins-andrej-aleksandrov\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.2.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"ro_RO\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47Continuous Integration \u043a\u0430\u043a \u043f\u0440\u0430\u043a\u0442\u0438\u043a\u0430, \u0430 \u043d\u0435 Jenkins. \u0410\u043d\u0434\u0440\u0435\u0439 \u0410\u043b\u0435\u043a\u0441\u0430\u043d\u0434\u0440\u043e\u0432 | ProHoster\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/continuous-integration-kak-praktika-a-ne-jenkins-andrej-aleksandrov\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-09-10T17:42:23+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-09-10T17:42:23+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Continuous Integration ca practic\u0103, nu ca Jenkins. Andrei Alexandrov | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/continuous-integration-kak-praktika-a-ne-jenkins-andrej-aleksandrov","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"ro_RO","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47Continuous Integration \u043a\u0430\u043a \u043f\u0440\u0430\u043a\u0442\u0438\u043a\u0430, \u0430 \u043d\u0435 Jenkins. \u0410\u043d\u0434\u0440\u0435\u0439 \u0410\u043b\u0435\u043a\u0441\u0430\u043d\u0434\u0440\u043e\u0432 | ProHoster","og:url":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/continuous-integration-kak-praktika-a-ne-jenkins-andrej-aleksandrov","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-09-10T17:42:23+00:00","article:modified_time":"2020-09-10T17:42:23+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"93885","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 11:37:31","updated":"2022-09-27 15:57:30","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts\/93885","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/comments?post=93885"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts\/93885\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/media\/93886"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/media?parent=93885"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/categories?post=93885"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/tags?post=93885"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}