{"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\/sq\/blog\/administrirovanie\/continuous-integration-kak-praktika-a-ne-jenkins-andrej-aleksandrov","title":{"rendered":"Continuous Integration si praktik\u00eb, e jo Jenkins. Andrey Aleksandrov","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Continuous<\/p>\n

<\/p>\n

Le t\u00eb diskutojm\u00eb pse mjetet CI dhe CI jan\u00eb krejt\u00ebsisht gj\u00ebra t\u00eb ndryshme.<\/p>\n

<\/p>\n

Cila \u00ebsht\u00eb dhimbja q\u00eb CI synon t\u00eb zgjidh\u00eb, nga ka ardhur idea, \u00e7far\u00eb konfirmimesh t\u00eb fundit ka q\u00eb funksionon, si t\u00eb kuptoni q\u00eb keni praktik\u00eb dhe jo thjesht Jenkins t\u00eb instaluar.<\/p>\n

<\/a><\/noindex><\/p>\n

Ideja p\u00ebr t\u00eb b\u00ebr\u00eb nj\u00eb prezantim mbi Integrimin e Vazhduesh\u00ebm lindi nj\u00eb vit m\u00eb par\u00eb, kur isha n\u00eb intervista p\u00ebr t\u00eb k\u00ebrkuar pun\u00eb. Kam biseduar me 10-15 kompani, dhe vet\u00ebm nj\u00ebra arriti t\u00eb shpjegoj\u00eb qart\u00eb se \u00e7far\u00eb \u00ebsht\u00eb CI dhe si ata kuptuan q\u00eb nuk e kishin at\u00eb. T\u00eb tjerat thoshin gj\u00ebra t\u00eb paqarta rreth Jenkins \ud83d\ude42 Po, ne kemi Jenkins, ai b\u00ebn nd\u00ebrtimet, CI! N\u00eb k\u00ebt\u00eb prezantim do t\u00eb p\u00ebrpiqem t\u00eb shpjegoj se \u00e7far\u00eb \u00ebsht\u00eb n\u00eb t\u00eb v\u00ebrtet\u00eb Integrimi i Vazhduesh\u00ebm dhe pse Jenkins dhe mjetet e ngjashme kan\u00eb nj\u00eb lidhje shum\u00eb t\u00eb dob\u00ebt me k\u00ebt\u00eb.<\/p>\n

<\/p>\n

\"Continuous<\/p>\n

<\/p>\n

Pra, \u00e7far\u00eb vjen zakonisht n\u00eb mendje kur mendoni p\u00ebr CI? Shumic\u00ebs s\u00eb njer\u00ebzve u vjen n\u00eb mendje Jenkins, Gitlab CI, Travis, etj.<\/p>\n

<\/p>\n

\"Continuous<\/p>\n

<\/p>\n

Edhe n\u00ebse ne e gjejm\u00eb n\u00eb Google, do t\u00eb na tregojn\u00eb k\u00ebto mjete.<\/p>\n

<\/p>\n

\"Continuous<\/p>\n

<\/p>\n

N\u00ebse pyesni njer\u00ebzit n\u00ebse jan\u00eb t\u00eb njohur, menj\u00ebher\u00eb pas p\u00ebrmendjes s\u00eb mjeteve do t'ju tregojn\u00eb se CI \u00ebsht\u00eb kur ndodh nd\u00ebrtimi dhe provojn\u00eb testet n\u00eb Pull Request p\u00ebr commit.<\/p>\n

<\/p>\n

\"Continuous<\/p>\n

<\/p>\n

Integrimi i Vazhduesh\u00ebm nuk ka t\u00eb b\u00ebj\u00eb me mjetet, as me nd\u00ebrtimet me teste n\u00eb deg\u00eb! Integrimi i Vazhduesh\u00ebm \u00ebsht\u00eb nj\u00eb praktik\u00eb e integrimit t\u00eb shpesht\u00eb t\u00eb kodit t\u00eb ri dhe p\u00ebr ta zbatuar k\u00ebt\u00eb nuk \u00ebsht\u00eb e nevojshme t\u00eb zhvilloni Jenkins, GitLab, etj.<\/p>\n

<\/p>\n

\"Continuous<\/p>\n

<\/p>\n

Para se t\u00eb kuptojm\u00eb si duket nj\u00eb CI i plot\u00eb, le t\u00eb zhytim fillimisht n\u00eb kontekstin e njer\u00ebzve q\u00eb e shpik\u00ebn at\u00eb dhe t\u00eb ndjejm\u00eb dhimbjen q\u00eb ata p\u00ebrpiqeshin t\u00eb zgjidhnin.<\/p>\n

<\/p>\n

\"Continuous<\/p>\n

<\/p>\n

Ata po zgjidhnin dhimbjen e bashk\u00ebpunimit n\u00eb ekip!<\/p>\n

<\/p>\n

\"Continuous<\/p>\n

<\/p>\n

Le t\u00eb shohim disa shembuj, me cilat sfida p\u00ebrballen zhvilluesit gjat\u00eb zhvillimit n\u00eb grup. Kemi nj\u00eb projekt, dega master n\u00eb git dhe dy zhvillues.<\/p>\n

<\/p>\n

\"Continuous<\/p>\n

<\/p>\n

Dhe ata filluan t\u00eb punojn\u00eb si\u00e7 kan\u00eb b\u00ebr\u00eb gjithmon\u00eb. Merrnin nj\u00eb detyr\u00eb n\u00eb Jira, krijonin nj\u00eb feature branch dhe shkruanin kod.<\/p>\n

<\/p>\n

\"Continuous<\/p>\n

<\/p>\n

Nj\u00ebri p\u00ebrfundoi ve\u00e7orin\u00eb m\u00eb shpejt dhe e bashkoi n\u00eb master.<\/p>\n

<\/p>\n

\"Continuous<\/p>\n

<\/p>\n

Tjetri pati m\u00eb shum\u00eb koh\u00eb, ai u bashkua m\u00eb von\u00eb dhe mori nj\u00eb konflikt. Tani, n\u00eb vend q\u00eb t\u00eb shkruante funksionalitete t\u00eb nevojshme p\u00ebr biznesin, zhvilluesi kalon koh\u00eb dhe energji p\u00ebr t\u00eb zgjidhur konfliktet.<\/p>\n

<\/p>\n

\"Continuous<\/p>\n

<\/p>\n

Sa m\u00eb e komplikuar t\u00eb jet\u00eb bashkimi i funksionalitetit tuaj me masterin e p\u00ebrbashk\u00ebt, aq m\u00eb shum\u00eb koh\u00eb do t\u00eb harxhoni n\u00eb k\u00ebt\u00eb. Dhe kjo \u00ebsht\u00eb ende nj\u00eb shembull mjaft i thjesht\u00eb. Ky \u00ebsht\u00eb nj\u00eb shembull ku p\u00ebrfshihen vet\u00ebm 2 zhvillues. Imagjinoni n\u00ebse 10, 15 ose 100 njer\u00ebz n\u00eb kompani shkruajn\u00eb n\u00eb nj\u00eb depo. Do t\u00eb \u00e7mendeni duke zgjidhur t\u00eb gjitha k\u00ebto konflikte. <\/p>\n

<\/p>\n

\"Continuous<\/p>\n

<\/p>\n

Ka nj\u00eb rast pak ndryshe. Ne kemi masterin dhe disa zhvillues q\u00eb po b\u00ebjn\u00eb di\u00e7ka.<\/p>\n

<\/p>\n

\"Continuous<\/p>\n

<\/p>\n

Ata krijuan nga nj\u00eb deg\u00eb.<\/p>\n

<\/p>\n

\"Continuous<\/p>\n

<\/p>\n

Nj\u00ebri u bashkua, gjith\u00e7ka ishte n\u00eb rregull, dor\u00ebzoi detyr\u00ebn.<\/p>\n

<\/p>\n

\"Continuous<\/p>\n

<\/p>\n

Zhvilluesi tjet\u00ebr n\u00eb t\u00eb nj\u00ebjt\u00ebn koh\u00eb dor\u00ebzoi detyr\u00ebn e tij. Supozoni se ai e dha at\u00eb p\u00ebr rishikim. N\u00eb shum\u00eb kompani ekziston praktika - rishikimi. Nga nj\u00ebra an\u00eb, kjo \u00ebsht\u00eb nj\u00eb praktik\u00eb e mir\u00eb dhe e dobishme, nga ana tjet\u00ebr, na pengon n\u00eb shum\u00eb raste. Nuk do t\u00eb thellohemi n\u00eb k\u00ebt\u00eb, por ja nj\u00eb shembull i shk\u00eblqyer se \u00e7far\u00eb mund t\u00eb sjell\u00eb nj\u00eb histori e komplikuar me rishikimin. Keni dor\u00ebzuar nj\u00eb pull request p\u00ebr rishikim. Zhvilluesit nuk kan\u00eb gj\u00eb tjet\u00ebr p\u00ebr t\u00eb b\u00ebr\u00eb. \u00c7far\u00eb fillon ai t\u00eb b\u00ebj\u00eb? Ai fillon t\u00eb marr\u00eb detyra t\u00eb tjera. <\/p>\n

<\/p>\n

\"Continuous<\/p>\n

<\/p>\n

N\u00eb k\u00ebt\u00eb koh\u00eb, zhvilluesi i dyt\u00eb ka b\u00ebr\u00eb di\u00e7ka tjet\u00ebr. <\/p>\n

<\/p>\n

\"Continuous<\/p>\n

<\/p>\n

I pari p\u00ebrfundoi nj\u00eb detyr\u00eb tjet\u00ebr. <\/p>\n

<\/p>\n

\"Continuous<\/p>\n

<\/p>\n

Dhe pas nj\u00eb kohe, rishikimi i tij \u00ebsht\u00eb provuar dhe ai p\u00ebrpiqet t\u00eb bashkohet. \u00c7far\u00eb ndodh? Ai p\u00ebrjeton nj\u00eb num\u00ebr t\u00eb madh konfliktesh. Pse? Sepse derisa pull requesti i tij t\u00eb ishte n\u00eb rishikim, n\u00eb kod pati shum\u00eb ndryshime. <\/p>\n

<\/p>\n

P\u00ebrve\u00e7 historis\u00eb me konflikti, ka dhe nj\u00eb histori me komunikimin. Pasi q\u00eb dega juaj \u00ebsht\u00eb n\u00eb rishikim, ndalon s\u00eb ndjekuri se \u00e7far\u00eb tjet\u00ebr po ndryshon n\u00eb baz\u00ebn e kodit tuaj t\u00eb sh\u00ebrbimit. Mund t\u00eb jet\u00eb q\u00eb ajo q\u00eb po p\u00ebrpiqeni t\u00eb zgjidhni tani \u00ebsht\u00eb zgjidhur nga dje dhe mund t\u00eb merrni nj\u00eb metod\u00eb p\u00ebr ta ri p\u00ebrdorur. Por nuk do ta shihni k\u00ebt\u00eb, sepse gjithmon\u00eb punoni me nj\u00eb deg\u00eb t\u00eb vjet\u00ebr. Dhe kjo deg\u00eb e vjet\u00ebr gjithmon\u00eb sjell si pasoj\u00eb se do t\u00eb keni t\u00eb nevojshme t\u00eb zgjidhni konflikte bashkimi. <\/p>\n

<\/p>\n

K\u00ebshtu, n\u00ebse punojm\u00eb si nj\u00eb ekip, dmth. jo vet\u00ebm nj\u00eb njeri merret me depozit\u00ebn, por 5-10 njer\u00ebz, sa m\u00eb gjat\u00eb q\u00eb ne nuk e shtojm\u00eb kodin ton\u00eb n\u00eb master, aq m\u00eb shum\u00eb vuajm\u00eb nga fakti se n\u00eb fund duhet t\u00eb bashkojm\u00eb di\u00e7ka. Dhe sa m\u00eb shum\u00eb konflikte t\u00eb kemi, dhe sa m\u00eb shum\u00eb me nj\u00eb version t\u00eb vjet\u00ebr punojm\u00eb, aq m\u00eb tep\u00ebr probleme kemi.<\/p>\n

<\/p>\n

\"Continuous<\/p>\n

<\/p>\n

Bashk\u00ebpunimi \u00ebsht\u00eb i dhimbsh\u00ebm! Ne gjithmon\u00eb pengojm\u00eb nj\u00ebri-tjetrin. <\/p>\n

<\/p>\n

\"Continuous<\/p>\n

<\/p>\n

Kjo problematik\u00eb \u00ebsht\u00eb v\u00ebn\u00eb re mbi 20 vjet m\u00eb par\u00eb. P\u00ebr her\u00eb t\u00eb par\u00eb, un\u00eb e gjet\u00ebm p\u00ebrmendjen e praktik\u00ebs s\u00eb Integrimit t\u00eb Vazhduesh\u00ebm n\u00eb programimin ekstrem.<\/p>\n

<\/p>\n

Programimi ekstrem \u00ebsht\u00eb korniza e par\u00eb agile. Faqa u shfaq n\u00eb vitin 96. Ideja ishte t\u00eb p\u00ebrdoren disa praktika programimi, planifikimi dhe t\u00eb tjer\u00eb, q\u00eb zhvillimi t\u00eb jet\u00eb sa m\u00eb fleksib\u00ebl, p\u00ebr t\u00eb ndihmuar n\u00eb reagimin m\u00eb t\u00eb shpejt\u00eb ndaj ndryshimeve dhe k\u00ebrkesave nga klient\u00ebt tan\u00eb. Dymb\u00ebdhjet\u00eb vjet m\u00eb par\u00eb filluan t\u00eb p\u00ebrballen me faktin se, n\u00ebse b\u00ebn di\u00e7ka p\u00ebr nj\u00eb koh\u00eb t\u00eb gjat\u00eb dhe n\u00eb m\u00ebnyr\u00eb t\u00eb ndar\u00eb, konsumon m\u00eb shum\u00eb koh\u00eb p\u00ebr shkak t\u00eb konflikteve. <\/p>\n

<\/p>\n

\"Continuous<\/p>\n

<\/p>\n

Tani do ta shqyrtojm\u00eb fraz\u00ebn \"Integrimi i vazhduesh\u00ebm\" fjal\u00eb p\u00ebr fjal\u00eb. N\u00ebse e p\u00ebrkthejm\u00eb dosido, na del integrim i vazhduesh\u00ebm. Por sa vazhdimisht \u00ebsht\u00eb kjo, nuk \u00ebsht\u00eb shum\u00eb e qart\u00eb; ajo \u00ebsht\u00eb shum\u00eb e nd\u00ebrprer\u00eb. Por sa \u00ebsht\u00eb \"integration\" gjithashtu nuk \u00ebsht\u00eb shum\u00eb e dukshme. <\/p>\n

<\/p>\n

Dhe p\u00ebr k\u00ebt\u00eb arsye po sjell tani citate nga programimi ekstrem. T\u00eb dy fjal\u00ebt do t'i shqyrtojm\u00eb ve\u00e7mas. <\/p>\n

<\/p>\n

Integrimi - Si\u00e7 e thash\u00eb, ne synojm\u00eb q\u00eb \u00e7do inxhinier t\u00eb punoj\u00eb me versionin m\u00eb t\u00eb fundit t\u00eb kodit, q\u00eb ai t\u00eb p\u00ebrpiqet t\u00eb shtoj\u00eb kodin e tij sa m\u00eb shpesh n\u00eb deg\u00ebn e p\u00ebrbashk\u00ebt, q\u00eb t\u00eb jen\u00eb dega t\u00eb vogla. Sepse n\u00ebse ato jan\u00eb t\u00eb m\u00ebdha, mund t\u00eb ngecim leht\u00ebsisht p\u00ebr nj\u00eb jav\u00eb me konflikte t\u00eb bashkimit. Sidomos n\u00ebse kemi nj\u00eb cik\u00ebl t\u00eb gjat\u00eb zhvillimi si waterfall, ku programuesi largohet p\u00ebr nj\u00eb muaj p\u00ebr t\u00eb punuar n\u00eb nj\u00eb karakteristik\u00eb t\u00eb madhe. Dhe ai n\u00eb faz\u00ebn e integrimit mund t\u00eb ngec\u00eb p\u00ebr nj\u00eb koh\u00eb t\u00eb gjat\u00eb. <\/p>\n

<\/p>\n

Integrimi \u00ebsht\u00eb kur marrim deg\u00ebn ton\u00eb dhe e integrojm\u00eb me masterin, e bashkojm\u00eb at\u00eb. Ka nj\u00eb variant ultimativ, kur ne jemi \"transbase developer\", ku p\u00ebrpiqemi t\u00eb shkruajm\u00eb direkt n\u00eb master pa deg\u00eb t\u00eb panevojshme.<\/p>\n

<\/p>\n

N\u00eb thelb, integrimi \u00ebsht\u00eb t\u00eb marr\u00ebsh kodin t\u00ebnd dhe ta \u00e7osh n\u00eb master. <\/p>\n

<\/p>\n

\"Continuous<\/p>\n

<\/p>\n

\u00c7far\u00eb n\u00ebnkuptohet k\u00ebtu me fjal\u00ebn \"continuous\", \u00e7far\u00eb quhet vazhdim\u00ebsi? Praktika n\u00ebnkupton q\u00eb programuesi synon t\u00eb integroj\u00eb kodin e tij sa m\u00eb shpejt. Kjo \u00ebsht\u00eb q\u00ebllimi gjat\u00eb p\u00ebrfundimit t\u00eb \u00e7do detyre \u2013 t\u00eb b\u00ebj\u00eb q\u00eb kodi i tij t\u00eb shfaqet n\u00eb master sa m\u00eb shpejt. N\u00eb nj\u00eb bot\u00eb ideale, programuesit do ta b\u00ebnin k\u00ebt\u00eb \u00e7do disa or\u00eb. Do thot\u00eb, merr nj\u00eb detyr\u00eb t\u00eb vog\u00ebl, e bashkon n\u00eb master. E gjitha \u00ebsht\u00eb e shk\u00eblqyer. K\u00ebshtu q\u00eb duhet ta b\u00ebni vazhdimisht. Sa her\u00eb q\u00eb b\u00ebni di\u00e7ka, menj\u00ebher\u00eb e \u00e7oni n\u00eb master. <\/p>\n

<\/p>\n

Dhe programuesi, i cili b\u00ebn di\u00e7ka, \u00ebsht\u00eb p\u00ebrgjegj\u00ebs p\u00ebr at\u00eb q\u00eb ka b\u00ebr\u00eb, q\u00eb t\u00eb funksionoj\u00eb dhe t\u00eb mos prish\u00eb asgj\u00eb. K\u00ebtu zakonisht dalin historit\u00eb me testet. Ne d\u00ebshirojm\u00eb t\u00eb ekzekutojm\u00eb disa teste mbi commit-in ton\u00eb, mbi bashkimin ton\u00eb, p\u00ebr t'u siguruar q\u00eb ajo funksionon. Dhe k\u00ebtu Jenkins mund t'ju ndihmoj\u00eb.<\/p>\n

<\/p>\n

Por p\u00ebr historit\u00eb: a t\u00eb b\u00ebjm\u00eb ndryshimet t\u00eb vogla, a t\u00eb b\u00ebjm\u00eb q\u00eb detyrat t\u00eb jen\u00eb t\u00eb vogla, a t\u00eb b\u00ebjm\u00eb q\u00eb detyra ta p\u00ebrfundojm\u00eb dhe menj\u00ebher\u00eb t\u00eb p\u00ebrpiqemi ta bashkojm\u00eb n\u00eb master \u2013 k\u00ebtu nuk do t'ju ndihmojn\u00eb asnj\u00eb Jenkins. Sepse Jenkins do t'ju ndihmojn\u00eb vet\u00ebm p\u00ebr t\u00eb ekzekutuar testet. <\/p>\n

<\/p>\n

Mund t\u00eb kaloni edhe pa to. Nuk do t'ju pengojn\u00eb fare. Sepse q\u00ebllimi i praktik\u00ebs \u00ebsht\u00eb t\u00eb bashkoni sa m\u00eb shpesh, p\u00ebr t\u00eb mos humbur nj\u00eb sasi t\u00eb madhe kohe p\u00ebr disa konflikte n\u00eb t\u00eb ardhmen. <\/p>\n

<\/p>\n

Imagjinoni se vitin 2020 ndodhemi pa internet. Dhe ne punojm\u00eb lokal. Nuk kemi Jenkins. Kjo \u00ebsht\u00eb n\u00eb rregull. Ende mund t\u00eb merrni dhe t\u00eb krijoni nj\u00eb deg\u00eb lokale. Keni shkruar ndonj\u00eb kod. Keni p\u00ebrfunduar nj\u00eb detyr\u00eb pas 3-4 or\u00ebsh. Kaloni n\u00eb master, b\u00ebni git pull, e bashkoni deg\u00ebn tuaj atje. Gati. N\u00ebse e b\u00ebni k\u00ebt\u00eb shpesh \u2013 p\u00ebrsh\u00ebndetje, keni integrim t\u00eb vazhduesh\u00ebm!<\/p>\n

<\/p>\n

\"Continuous<\/p>\n

<\/p>\n

Cilat jan\u00eb provat n\u00eb bot\u00ebn moderne q\u00eb tregojn\u00eb se duhet t\u00eb investoni energjin\u00eb tuaj n\u00eb k\u00ebt\u00eb? Sepse n\u00eb p\u00ebrgjith\u00ebsi kjo \u00ebsht\u00eb e nd\u00ebrlikuar. N\u00ebse p\u00ebrpiqeni t\u00eb punoni k\u00ebshtu, do t\u00eb kuptoni se kjo do t\u00eb prek\u00eb ndonj\u00eb planifikim, do t'ju duhet t\u00eb p\u00ebrkushtoni m\u00eb shum\u00eb koh\u00eb p\u00ebr dekompozimin e detyrave. Sepse n\u00ebse b\u00ebni man\u2026, nuk do t\u00eb b\u00ebni bashkimin shpejt dhe p\u00ebr rrjedhoj\u00eb do t\u00eb bini n\u00eb nj\u00eb situat\u00eb t\u00eb v\u00ebshtir\u00eb. Praktikat tuaja do t\u00eb humbasin. <\/p>\n

<\/p>\n

Dhe kjo do t\u00eb jet\u00eb e shtrenjt\u00eb. Nuk do t\u00eb arrini t'i kaloni menj\u00ebher\u00eb praktik\u00eb aktuale t\u00eb integrimit t\u00eb vazhduesh\u00ebm. T\u00eb gjith\u00eb do t'ju duhen shum\u00eb koh\u00eb p\u00ebr t'u adaptuar, shum\u00eb koh\u00eb p\u00ebr t'u m\u00ebsuar t\u00eb dekompozoni detyrat, shum\u00eb koh\u00eb p\u00ebr t'u m\u00ebsuar t\u00eb rishikoni praktikat, n\u00ebse ato ekzistojn\u00eb. Sepse q\u00ebllimi yn\u00eb \u00ebsht\u00eb q\u00eb ta bashkojm\u00eb sot. Dhe n\u00ebse e b\u00ebni rishikimin n\u00eb tre dit\u00eb, at\u00ebher\u00eb keni probleme dhe integrimi i vazhduesh\u00ebm nuk funksionon. <\/p>\n

<\/p>\n

Por a kemi ndonj\u00eb prov\u00eb aktuale tani q\u00eb na thot\u00eb se investimi n\u00eb k\u00ebt\u00eb praktik\u00eb ka kuptim?<\/p>\n

<\/p>\n

\"Continuous<\/p>\n

<\/p>\n

E para q\u00eb m\u00eb erdhi n\u00eb mendje \u2013 \u00ebsht\u00eb State of DevOps. Ky \u00ebsht\u00eb nj\u00eb studim q\u00eb ekipi e ka zhvilluar p\u00ebr 7 vjet. Tani ata e b\u00ebjn\u00eb si nj\u00eb organizat\u00eb t\u00eb pavarur, por n\u00ebn Google.<\/p>\n

<\/p>\n

Dhe studimi i tyre n\u00eb vitin 2018 tregoi nj\u00eb korrelacion midis kompanive q\u00eb p\u00ebrpiqen t\u00eb p\u00ebrdorin deg\u00eb t\u00eb shkurtra, t\u00eb cilat integrohen shpejt, integrohen shpesh, ato kan\u00eb t\u00eb dh\u00ebna m\u00eb t\u00eb mira t\u00eb performanc\u00ebs IT.<\/p>\n

<\/p>\n

\u00c7far\u00eb jan\u00eb k\u00ebto t\u00eb dh\u00ebna? K\u00ebto jan\u00eb 4 metrika q\u00eb ata shkencojn\u00eb nga t\u00eb gjitha kompanit\u00eb n\u00eb anketat e tyre: frekuenca e lansimit, koh\u00ebzgjatja p\u00ebr ndryshime, koha p\u00ebr t\u00eb rikthyer sh\u00ebrbimin, shkalla e d\u00ebshtimit t\u00eb ndryshimit.<\/p>\n

<\/p>\n

S\u00eb pari, ekziston ky korrelacion, e dim\u00eb se kompanit\u00eb q\u00eb b\u00ebjn\u00eb bashkime shpesh, kan\u00eb k\u00ebto metrika shum\u00eb m\u00eb t\u00eb mira. Dhe ata kan\u00eb b\u00ebr\u00eb nj\u00eb ndarje t\u00eb kompanive n\u00eb disa kategori: ato kompani t\u00eb ngadalta q\u00eb prodhojn\u00eb di\u00e7ka ngadal\u00eb, performer\u00eb mesatar\u00eb, performer\u00eb t\u00eb lart\u00eb dhe elita. Elita jan\u00eb Netflix, Amazon, t\u00eb cilat jan\u00eb jasht\u00ebzakonisht t\u00eb shpejta, gjith\u00eb\u00e7ka e b\u00ebjn\u00eb shpejt, bukur dhe me cil\u00ebsi.<\/p>\n

<\/p>\n

\"Continuous<\/p>\n

<\/p>\n

Historia tjet\u00ebr, q\u00eb ndodhi vet\u00ebm nj\u00eb muaj m\u00eb par\u00eb. N\u00eb Technology Radar u shfaq nj\u00eb sh\u00ebnim i shk\u00eblqyer rreth Gitflow. Gitflow dallon nga t\u00eb gjitha t\u00eb tjerat sepse deg\u00ebt e tij jetojn\u00eb p\u00ebr nj\u00eb koh\u00eb t\u00eb gjat\u00eb. Ka deg\u00eb l\u00ebshimi q\u00eb jetojn\u00eb p\u00ebr nj\u00eb koh\u00eb t\u00eb gjat\u00eb, deg\u00eb funksionesh q\u00eb gjithashtu jetojn\u00eb gjat\u00eb. Kjo praktik\u00eb n\u00eb Technology Radar kaloi n\u00eb HOLD. Pse? Sepse njer\u00ebzit p\u00ebrballen me dhimbjen e integrimit. <\/p>\n

<\/p>\n

N\u00ebse nj\u00eb deg\u00eb jeton p\u00ebr nj\u00eb koh\u00eb shum\u00eb t\u00eb gjat\u00eb, ajo ngec, skadon, ne fillojm\u00eb t\u00eb harxhojm\u00eb m\u00eb shum\u00eb koh\u00eb p\u00ebr t\u00eb b\u00ebr\u00eb nj\u00eb ndryshim n\u00eb t\u00eb. <\/p>\n

<\/p>\n

Dhe s\u00eb fundmi, autori i Gitflow tha se n\u00ebse ju p\u00ebrpiqeni p\u00ebr Integrim t\u00eb Vazhdush\u00ebm, n\u00ebse ju d\u00ebshironi t\u00eb l\u00ebvizni sa m\u00eb shpesh, at\u00ebher\u00eb Gitflow \u00ebsht\u00eb nj\u00eb ide e keqe. Ai ve\u00e7ant\u00ebsh n\u00eb artikullin e tij shtoi se n\u00ebse keni nj\u00eb backend, ku mund t\u00eb synoni k\u00ebt\u00eb, at\u00ebher\u00eb Gitflow \u00ebsht\u00eb e tep\u00ebrt p\u00ebr ju, sepse Gitflow do t'ju ngadal\u00ebsoj\u00eb dhe do t'ju krijoj\u00eb probleme me integrimin. <\/p>\n

<\/p>\n

Kjo nuk do t\u00eb thot\u00eb q\u00eb Gitflow \u00ebsht\u00eb i keq dhe nuk duhet ta p\u00ebrdorni. Ai \u00ebsht\u00eb p\u00ebr raste t\u00eb tjera. P\u00ebr shembull, kur ju nevojitet t\u00eb mb\u00ebshtesni disa versione t\u00eb sh\u00ebrbimit, aplikacionit, pra ku duhet t\u00eb mb\u00ebshtetni p\u00ebr nj\u00eb periudh\u00eb m\u00eb t\u00eb zgjatur kohore. <\/p>\n

<\/p>\n

Por n\u00ebse flisni me njer\u00ebzit q\u00eb mb\u00ebshtesin k\u00ebto sh\u00ebrbime, do t\u00eb d\u00ebgjoni shum\u00eb dhimbje p\u00ebr faktin se kjo version ishte 3.2, q\u00eb ishte 4 muaj m\u00eb par\u00eb, dhe se kjo p\u00ebrmir\u00ebsim nuk u p\u00ebrfshi dhe tani, p\u00ebr ta treguar, duhet t\u00eb b\u00ebni shum\u00eb ndryshime. Dhe tani ata mbeten p\u00ebrs\u00ebri t\u00eb bllokuar, dhe kalojn\u00eb nj\u00eb jav\u00eb duke u zvarritur p\u00ebr t\u00eb marr\u00eb dhe b\u00ebr\u00eb bashkimin e ndonj\u00eb funksionaliteti t\u00eb ri. <\/p>\n

<\/p>\n

Si\u00e7 e vuri n\u00eb dukje Aleksand\u00ebr Koval\u00ebv n\u00eb bised\u00eb, korrelacioni nuk do t\u00eb thot\u00eb lidhje shkaku-pasoj\u00eb. Kjo \u00ebsht\u00eb e v\u00ebrtet\u00eb. Pra, nuk ka ndonj\u00eb lidhje t\u00eb drejtp\u00ebrdrejt\u00eb se n\u00ebse keni Integrim t\u00eb Vazhdush\u00ebm, at\u00ebher\u00eb t\u00eb gjitha metrikat do t\u00eb jen\u00eb shk\u00eblqyese, jo. Por ekziston nj\u00eb korrelacion pozitiv q\u00eb n\u00ebse nj\u00eb \u00ebsht\u00eb e v\u00ebrtet\u00eb, at\u00ebher\u00eb me siguri tjetra \u00ebsht\u00eb gjithashtu e till\u00eb. Nuk \u00ebsht\u00eb fakt, por me siguri. Ky \u00ebsht\u00eb thjesht nj\u00eb korrelacion. <\/p>\n

<\/p>\n

\"Continuous<\/p>\n

<\/p>\n

Duket se ne tashm\u00eb po b\u00ebjm\u00eb di\u00e7ka, duket se po bashkohemi, por si t\u00eb kuptojm\u00eb n\u00ebse ne n\u00eb t\u00eb v\u00ebrtet\u00eb kemi Integrim t\u00eb Vazhdush\u00ebm, se po bashkohemi mjaft shpesh?<\/p>\n

<\/p>\n

Jez Humble \u00ebsht\u00eb autori i Manualit, Accelerate, faqeve t\u00eb Integrimit t\u00eb Vazhdush\u00ebm dhe librit \"Integrimi i Vazhdush\u00ebm\". Ai ofron k\u00ebt\u00eb test:<\/p>\n

<\/p>\n