Dhe ti ende nuk p\u00ebrgjigje p\u00ebr pyetjen: \"A \u00ebsht\u00eb Jenkins i nevojsh\u00ebm apo jo?\"<\/em><\/p>\n<\/p>\n
Jenkins n\u00eb t\u00eb v\u00ebrtet\u00eb nuk \u00ebsht\u00eb i nevojsh\u00ebm n\u00eb asnj\u00eb rast. N\u00ebse flasim seriozisht, mjetet: Jenkins, Gitlab do t'ju sjellin leht\u00ebsi. Do t\u00eb shihni n\u00ebse nd\u00ebrtimi \u00ebsht\u00eb b\u00ebr\u00eb apo jo. Ato mund t'ju ndihmojn\u00eb, por nuk do t'ju japin praktik\u00eb. Ato mund t'ju japin vet\u00ebm nj\u00eb rreth \u2013 OK, nuk OK. Dhe kjo, n\u00ebse ende shkruani teste, sepse n\u00ebse nuk ka teste, at\u00ebher\u00eb kjo \u00ebsht\u00eb pothuajse e pafalshme. Pra, \u00ebsht\u00eb i nevojsh\u00ebm, sepse \u2013 \u00ebsht\u00eb m\u00eb e leht\u00eb, por n\u00eb p\u00ebrgjith\u00ebsi mund t\u00eb jetoni edhe pa t\u00eb, nuk do humbni shum\u00eb. <\/p>\n
<\/p>\n
Pra, n\u00ebse keni praktika, at\u00ebher\u00eb do t\u00eb thot\u00eb se nuk ju nevojitet?<\/em><\/p>\n<\/p>\n
E drejt\u00eb. Un\u00eb rekomandoj testin Jez Humble. Atje kam nj\u00eb q\u00ebndrim t\u00eb dyfisht\u00eb mbi pik\u00ebn e fundit. Por n\u00eb p\u00ebrgjith\u00ebsi, n\u00ebse keni tri gj\u00ebra, po bashkoni vazhdimisht, po ekzekutoni teste t\u00eb angazhimeve n\u00eb master, shpejt rregulloni nd\u00ebrtimin n\u00eb master, ndoshta nuk keni nevoj\u00eb p\u00ebr ndonj\u00eb gj\u00eb tjet\u00ebr. <\/p>\n
<\/p>\n
Nd\u00ebrsa presim pyetje nga pjes\u00ebmarr\u00ebsit, kam nj\u00eb pyetje. Ne tani po flisnim p\u00ebr kodin produktor. A e ke p\u00ebrdorur p\u00ebr kodin e infrastruktur\u00ebs? A \u00ebsht\u00eb i nj\u00ebjti kod, ka t\u00eb nj\u00ebjtat principe dhe t\u00eb nj\u00ebjtin cik\u00ebl jet\u00ebsor, apo aty ka cikle dhe principe t\u00eb tjera? Zakonisht, kur t\u00eb gjith\u00eb flasin p\u00ebr Integrimin dhe Zhvillimin e Vazhdush\u00ebm, ata harrojn\u00eb se ka edhe kod infrastrukturor. Dhe n\u00eb koh\u00ebt e fundit po b\u00ebhet gjithnj\u00eb e m\u00eb shum\u00eb. A duhet t\u00eb sjellim t\u00eb gjitha k\u00ebto rregulla atje?<\/em><\/p>\n<\/p>\n
Madje jo vet\u00ebm se duhet, kjo do t\u00eb ishte n\u00eb t\u00eb v\u00ebrtet\u00eb e shk\u00eblqyer, sepse me siguri do t\u00eb thjeshtoj\u00eb jet\u00ebn. Sa m\u00eb shpejt t\u00eb punojm\u00eb me kodin, jo me skriptet n\u00eb bash, por kur kemi kod t\u00eb mir\u00eb.<\/p>\n
<\/p>\n
Stop-stop, skripti n\u00eb bash \u2013 \u00ebsht\u00eb gjithashtu kod. Mos e prek dashurin\u00eb time t\u00eb vjet\u00ebr.<\/em> <\/p>\n<\/p>\n
Mir\u00eb, nuk do t\u00eb shtyp kujtimet tua. Kam nj\u00eb antipati personale ndaj bash-it. Ai shpesh d\u00ebshtonte n\u00eb m\u00ebnyr\u00eb t\u00eb frikshme dhe t\u00eb sh\u00ebmtuar. Dhe d\u00ebshtonte shpesh n\u00eb m\u00ebnyr\u00eb t\u00eb papritur, prandaj nuk e p\u00eblqej. Por mir\u00eb, le t\u00eb supozojm\u00eb se ke kod n\u00eb bash. Mund t\u00eb jet\u00eb q\u00eb un\u00eb v\u00ebrtet nuk e kuptoj dhe ndoshta ka korniza normale p\u00ebr testim aty. Un\u00eb thjesht nuk jam n\u00eb k\u00ebt\u00eb fush\u00eb. Dhe ne po marrim t\u00eb nj\u00ebjtat p\u00ebrfitime.<\/p>\n
<\/p>\n
Sa her\u00eb q\u00eb punojm\u00eb me infrastruktur\u00ebn si kod, ne hasim t\u00eb nj\u00ebjtat probleme si zhvilluesit. Disa muaj m\u00eb par\u00eb u p\u00ebrballa me nj\u00eb situat\u00eb ku nj\u00eb koleg m\u00eb d\u00ebrgoi nj\u00eb pull request me 1,000 rreshta n\u00eb bash. Dhe ti ngec n\u00eb rishikim p\u00ebr 4 or\u00eb. Problemet jan\u00eb t\u00eb nj\u00ebjta. Akoma \u00ebsht\u00eb kod. Edhe \u00ebsht\u00eb akoma pun\u00eb n\u00eb bashk\u00ebpunim. Ne ngecim me pull request dhe ngecim me ato konflikte t\u00eb p\u00ebrzierjes t\u00eb bash-it, p\u00ebr shembull. <\/p>\n
<\/p>\n
Aktualisht po e shoh k\u00ebt\u00eb gj\u00eb me programimin m\u00eb t\u00eb bukur t\u00eb infrastruktur\u00ebs. Kam futur Pulumi n\u00eb infrastruktur\u00ebn time. Ky \u00ebsht\u00eb programim i past\u00ebr. Aty \u00ebsht\u00eb shum\u00eb m\u00eb e bukur, sepse kam t\u00eb gjitha mund\u00ebsit\u00eb e gjuh\u00ebs s\u00eb programimit, dmth. kam b\u00ebr\u00eb toggles t\u00eb bukura me t\u00eb nj\u00ebjtat if-e. V\u00ebrtet, ndryshimi im \u00ebsht\u00eb tashm\u00eb n\u00eb master. T\u00eb gjith\u00eb e shohin at\u00eb. Inxhinier\u00eb t\u00eb tjer\u00eb jan\u00eb t\u00eb informuar. Ai tashm\u00eb ka ndikuar n\u00eb di\u00e7ka. Por, p\u00ebrve\u00e7 k\u00ebsaj, ai nuk \u00ebsht\u00eb aktivizuar p\u00ebr t\u00eb gjith\u00eb infrastrukturat. Ai \u00ebsht\u00eb aktivizuar p\u00ebr stolat e mia t\u00eb testit, p\u00ebr shembull. Prandaj, p\u00ebr t'u p\u00ebrgjigjur pyetjes t\u00ebnde edhe nj\u00ebher\u00eb, \u00ebsht\u00eb e nevojshme. Kjo, si inxhinier\u00eb q\u00eb punojm\u00eb me kod, gjithashtu na leht\u00ebson jet\u00ebn. <\/p>\n
<\/p>\n
A ka ndokush pyetje tjet\u00ebr?<\/em> <\/p>\n<\/p>\n
Kam nj\u00eb pyetje. Dua t\u00eb vazhdoj diskutimin me Olegun. N\u00eb p\u00ebrgjith\u00ebsi, mendoj se ke t\u00eb drejt\u00eb, se n\u00ebse nj\u00eb detyr\u00eb t\u00eb merr nj\u00eb muaj, at\u00ebher\u00eb ke problem me arkitektur\u00ebn, ke problem me analiz\u00ebn, dekompozimin, planifikimin etj. Por kam ndjesin\u00eb se n\u00ebse fillon t\u00eb jetosh sipas Continuous Integration, at\u00ebher\u00eb do t\u00eb fillosh t\u00eb korrigjosh dhimbjet e planifikimit, sepse nuk mund t\u00eb ik\u00ebsh nga kjo. <\/p>\n
<\/p>\n
(Oleg) Po, gjith\u00e7ka \u00ebsht\u00eb si\u00e7 thoni. N\u00eb nivelin e pun\u00ebs, kjo praktik\u00eb \u00ebsht\u00eb e krahasueshme me \u00e7do praktik\u00eb tjet\u00ebr serioze q\u00eb ndryshon kultur\u00ebn. E gjith\u00eb v\u00ebshtir\u00ebsia n\u00eb tejkalimin ndodhet n\u00eb zakonet, ve\u00e7an\u00ebrisht zakonet e k\u00ebqija. Dhe n\u00ebse p\u00ebr t\u00eb arritur k\u00ebt\u00eb praktik\u00eb k\u00ebrkohet nj\u00eb ndryshim i r\u00ebnd\u00ebsish\u00ebm i zakonit t\u00eb atyre q\u00eb ju rrethojn\u00eb: zhvilluesve, menaxhmentit, menaxherit t\u00eb prodhimit, prisni befasi.<\/em> <\/p>\n<\/p>\n
Cilat mund t\u00eb jen\u00eb befasi? Le t\u00eb themi, se vendos\u00ebt q\u00eb do t\u00eb realizoni integrimin m\u00eb shpesh. Dhe n\u00eb integrimin tuaj \u00ebsht\u00eb lidhur di\u00e7ka tjet\u00ebr, le t\u00eb themi artefaktet. Dhe n\u00eb kompanin\u00eb tuaj, p\u00ebr shembull, ka nj\u00eb politik\u00eb q\u00eb \u00e7do artefakt duhet t\u00eb jet\u00eb n\u00eb nj\u00eb m\u00ebnyr\u00eb t\u00eb regjistruar n\u00eb nj\u00eb sistem ruajtjeje artefaktesh. Dhe kjo merr nj\u00eb sasi t\u00eb caktuar kohe. Nj\u00eb njeri duhet t\u00eb v\u00ebr\u00eb nj\u00eb shenj\u00eb, q\u00eb si menaxher i l\u00ebshimit e ka provuar k\u00ebt\u00eb artefakt p\u00ebr gatishm\u00ebri p\u00ebr t\u00eb kaluar n\u00eb prodhim. N\u00ebse kjo zgjat 5-10-15 minuta, por lidhur me k\u00ebt\u00eb b\u00ebni nj\u00eb l\u00ebshim nj\u00eb her\u00eb n\u00eb jav\u00eb, at\u00ebher\u00eb nj\u00eb her\u00eb n\u00eb jav\u00eb t\u00eb shpenzoni gjysm\u00eb ore, nuk \u00ebsht\u00eb nj\u00eb tatim i madh.<\/em> <\/p>\n<\/p>\n
N\u00ebse b\u00ebni Continuous Integration 10 her\u00eb n\u00eb dit\u00eb, at\u00ebher\u00eb 10 her\u00eb duhet t\u00eb mnoheni me 30 minuta. Dhe kjo e kalon koh\u00ebn e pun\u00ebs s\u00eb k\u00ebtij menaxheri t\u00eb l\u00ebshimit. Ai thjesht lodhet t\u00eb b\u00ebj k\u00ebt\u00eb. Ka shpenzime t\u00eb vazhdueshme p\u00ebr disa praktika. Dhe ashtu.<\/em> <\/p>\n<\/p>\n
Dhe ju duhet ose t\u00eb anuloni k\u00ebt\u00eb rregull, q\u00eb t\u00eb mos merresh m\u00eb me k\u00ebt\u00eb gj\u00eb, dmth. nuk jepni manualisht nivelin e p\u00ebrputhshm\u00ebris\u00eb s\u00eb di\u00e7kaje me di\u00e7ka tjet\u00ebr. Ju besoni plot\u00ebsisht n\u00eb nj\u00eb grup t\u00eb automatizuar testesh gatishm\u00ebrie.<\/em> <\/p>\n<\/p>\n
Dhe n\u00ebse ju nevojitet ndonj\u00eb prov\u00eb nga dikush, q\u00eb kryesori t\u00eb n\u00ebnshkruaj\u00eb, dhe ju nuk hyni n\u00eb prodhim pa at\u00eb q\u00eb Vasia tha se lejohet etj. \u2013 e gjith\u00eb kjo marr\u00ebzi ndalon praktikat. Sepse n\u00ebse ka aktivitete t\u00eb lidhura si nj\u00eb tatim, at\u00ebher\u00eb gjith\u00e7ka rritet n\u00eb 100 her\u00eb. Pra, ndryshimi shpesh do t\u00eb merret jo me g\u00ebzim nga t\u00eb gjith\u00eb. Sepse \u00ebsht\u00eb e v\u00ebshtir\u00eb t\u00eb korrigjohen zakonet e njer\u00ebzve.<\/em> <\/p>\n<\/p>\n
Kur nj\u00eb person b\u00ebn nj\u00eb pun\u00eb t\u00eb zakonshme, ai e b\u00ebn at\u00eb, praktikisht, pa menduar. Ngarkesa e tij kognitive \u00ebsht\u00eb zero. Ai thjesht punon me t\u00eb gatshmen, ai ka nj\u00eb list\u00eb kontrolli n\u00eb kok\u00eb, e ka b\u00ebr\u00eb k\u00ebt\u00eb nj\u00eb mij\u00eb her\u00eb. Dhe sapo t\u00eb vij\u00eb dhe i thoni: \"Le t\u00eb anulojm\u00eb k\u00ebt\u00eb praktik\u00eb dhe nga e h\u00ebna t\u00eb zbatojm\u00eb nj\u00eb t\u00eb re\", p\u00ebr t\u00eb kjo b\u00ebhet nj\u00eb ngarkes\u00eb e madhe kognitive. Dhe kjo ndodh menj\u00ebher\u00eb p\u00ebr t\u00eb gjith\u00eb.<\/em> <\/p>\n<\/p>\n
Prandaj, m\u00ebnyra m\u00eb e thjesht\u00eb, e v\u00ebrteta, \u00ebsht\u00eb se kjo luks nuk e lejojn\u00eb t\u00eb gjith\u00eb, por un\u00eb gjithmon\u00eb e b\u00ebj k\u00ebshtu. N\u00ebse nis nj\u00eb projekt t\u00eb ri, zakonisht t\u00eb gjitha praktikat e paprovuar futen menj\u00ebher\u00eb n\u00eb k\u00ebt\u00eb projekt. Nd\u00ebrsa projekti \u00ebsht\u00eb i ri, nuk rrezikojm\u00eb shum\u00eb. Prod nuk \u00ebsht\u00eb ende aty, nuk ka asgj\u00eb q\u00eb mund t\u00eb prishet. Prandaj, mund ta p\u00ebrdorim si st\u00ebrvitje. Ky qasje funksionon. Por nuk t\u00eb gjitha kompanit\u00eb kan\u00eb mund\u00ebsi ta nisin k\u00ebt\u00eb lloj projektesh shpesh. Megjithat\u00eb, kjo \u00ebsht\u00eb disi e \u00e7uditshme sepse tani ka nj\u00eb transformim t\u00eb plot\u00eb digital, t\u00eb gjith\u00eb duhet t\u00eb fillojn\u00eb eksperimente p\u00ebr t\u00eb mbetur n\u00eb hap me konkurrent\u00ebt.<\/em> <\/p>\n<\/p>\n
K\u00ebtu e gjen veten para faktit se m\u00eb par\u00eb duhet t\u00eb kesh nj\u00eb kuptim t\u00eb asaj q\u00eb duhet t\u00eb b\u00ebsh. Bota nuk \u00ebsht\u00eb ideale, as prodhimi nuk \u00ebsht\u00eb ideal. <\/p>\n
<\/p>\n
Po, k\u00ebto gj\u00ebra jan\u00eb t\u00eb lidhura ngusht\u00eb.<\/em><\/p>\n<\/p>\n
Biznesi gjithashtu nuk ka gjithmon\u00eb nj\u00eb kuptim se duhet t\u00eb shkojn\u00eb n\u00eb k\u00ebt\u00eb drejtim. <\/p>\n
<\/p>\n
Ka nj\u00eb situat\u00eb ku asnj\u00eb ndryshim nuk \u00ebsht\u00eb i mundur. Kjo \u00ebsht\u00eb nj\u00eb situat\u00eb kur presioni mbi ekip \u00ebsht\u00eb m\u00eb i madh. Ekipi \u00ebsht\u00eb tashm\u00eb mjaft i shteruar. Ai nuk ka asnj\u00eb koh\u00eb rezerv\u00eb p\u00ebr eksperimente. Ata punojn\u00eb p\u00ebr t\u00eb zhvilluar karakteristika nga m\u00ebngjesi deri n\u00eb mbr\u00ebmje. Dhe drejtuesit k\u00ebrkojn\u00eb gjithnj\u00eb e m\u00eb shum\u00eb karakteristika. N\u00eb k\u00ebt\u00eb situat\u00eb, asnj\u00eb ndryshim nuk \u00ebsht\u00eb i mundur. Ekipit mund t'i thuhet vet\u00ebm se nes\u00ebr do ta b\u00ebjm\u00eb ashtu si dje, duhet vet\u00ebm t\u00eb b\u00ebjm\u00eb pak m\u00eb shum\u00eb karakteristika. Asnj\u00eb kalim n\u00eb asnj\u00eb praktik\u00eb n\u00eb k\u00ebt\u00eb sens nuk \u00ebsht\u00eb i mundur. Kjo \u00ebsht\u00eb nj\u00eb situat\u00eb klasike, kur nuk ka koh\u00eb p\u00ebr t\u00eb sharpen the axe, duhet prer\u00eb pem\u00ebt, prandaj prehen me nj\u00eb aks t\u00eb mpreht\u00eb. K\u00ebtu nuk ka k\u00ebshilla t\u00eb thjeshta.<\/em> <\/p>\n<\/p>\n
(Dmitri) Un\u00eb do t\u00eb lexoj nj\u00eb sqarim nga biseda: \"Por nevojitet nj\u00eb mbulim i madh me teste n\u00eb nivele t\u00eb ndryshme. Sa koh\u00eb i kushtohet testeve? Duket disi e shtrenjt\u00eb, merr shum\u00eb koh\u00eb.\"<\/em><\/p>\n<\/p>\n
(Oleg) Kjo \u00ebsht\u00eb nj\u00eb keqkuptim klasik. Duhet t\u00eb keni mjaft teste n\u00eb m\u00ebnyr\u00eb q\u00eb t\u00eb keni vet\u00ebbesim. Continuous Integration nuk \u00ebsht\u00eb nj\u00eb gj\u00eb ku s\u00eb pari b\u00ebni 100% teste dhe vet\u00ebm pastaj filloni ta aplikoni k\u00ebt\u00eb praktik\u00eb. Continuous Integration e ul barr\u00ebn kognitive mbi ju, sepse \u00e7do ndryshim q\u00eb shihni me sy \u00ebsht\u00eb aq i qart\u00eb sa q\u00eb kuptoni n\u00ebse do t\u00eb d\u00ebshtoj\u00eb di\u00e7ka apo jo, edhe pa teste. Ju mund ta testoni shpejt n\u00eb mendje, sepse ndryshimet jan\u00eb t\u00eb vogla. Edhe n\u00ebse keni vet\u00ebm testues manual\u00eb, atyre gjithashtu u leht\u00ebsohet. Ju e keni lan\u00e7uar dhe thoni: \"Shiko, a ka ndodhur ndonj\u00eb d\u00ebshtim?\" Ata kontrollojn\u00eb dhe thon\u00eb: \"Jo, nuk ka ndodhur asgj\u00eb.\" Sepse testuesi e di se ku t\u00eb shikoj\u00eb. Keni nj\u00eb commit t\u00eb lidhur me nj\u00eb fragment t\u00eb vet\u00ebm kodit. Dhe kjo eksploitohet me nj\u00eb sjellje konkrete.<\/em><\/p>\n<\/p>\n
K\u00ebtu, sigurisht, e ke zbukuruar disi. <\/p>\n
<\/p>\n
(Dmitry) K\u00ebtu nuk jam dakord. Ekziston praktika \u2013 zhvillimi p\u00ebrmes testimit, e cila pik\u00ebrisht do t'ju shp\u00ebtoj\u00eb nga kjo.<\/em> <\/p>\n<\/p>\n
(Oleg) K\u00ebt\u00eb nuk e kam arritur akoma. Iluzioni i par\u00eb \u00ebsht\u00eb se duhet t\u00eb shkruani pik\u00ebrisht 100% teste ose nuk duhet fare ta praktikoni Continuous Integration. Kjo \u00ebsht\u00eb e pav\u00ebrtet\u00eb. K\u00ebto jan\u00eb dy praktika paralele. Dhe ato nuk varen drejtp\u00ebrdrejt nj\u00ebra nga tjetra. Mbulesa juaj me teste duhet t\u00eb jet\u00eb optimale. Optimumi do t\u00eb thot\u00eb q\u00eb jeni t\u00eb sigurt se cil\u00ebsia e masterit, n\u00eb t\u00eb cilin ka mbetur pas commit-it tuaj, ju lejon t\u00eb klikoni me besim butonin \u201cDeploy\u201d t\u00eb premten n\u00eb mbr\u00ebmje, kur jeni duke pir\u00eb. Si e arrini k\u00ebt\u00eb? N\u00ebp\u00ebrmjet rishikimeve, mbules\u00ebs, n\u00ebp\u00ebrmjet monitorimit t\u00eb mir\u00eb.<\/em> <\/p>\n<\/p>\n
Monitorimi i mir\u00eb \u2013 nuk \u00ebsht\u00eb i dalluesh\u00ebm nga testet. N\u00ebse ju i ekzekutoni testet nj\u00eb her\u00eb n\u00eb pre prod, ato kontrollojn\u00eb nj\u00eb her\u00eb t\u00eb gjitha skenar\u00ebt tuaj t\u00eb p\u00ebrdoruesit dhe asgj\u00eb m\u00eb shum\u00eb. Por n\u00ebse i ekzekutoni ato n\u00eb nj\u00eb cik\u00ebl t\u00eb pafund, at\u00ebher\u00eb ky \u00ebsht\u00eb sistemi juaj i zgjeruar i monitorimit, i cili e teston gjith\u00e7ka n\u00eb m\u00ebnyr\u00eb t\u00eb pafund \u2013 ka r\u00ebn\u00eb apo nuk ka r\u00ebn\u00eb. N\u00eb k\u00ebt\u00eb rast, ndryshimi \u00ebsht\u00eb vet\u00ebm n\u00eb nj\u00eb her\u00eb ose n\u00eb shum\u00eb her\u00eb. Nj\u00eb set i shk\u00eblqyer testesh ... t\u00eb ekzekutuara pafund\u00ebsisht, jan\u00eb monitorim. Dhe monitorimi i duhur duhet t\u00eb jet\u00eb k\u00ebshtu.<\/em> <\/p>\n<\/p>\n
Dhe prandaj, si do ta arrini k\u00ebt\u00eb gjendje, kur t\u00eb b\u00ebni deploy t\u00eb premten n\u00eb mbr\u00ebmje dhe t\u00eb largoheni p\u00ebr n\u00eb sht\u00ebpi, \u00ebsht\u00eb nj\u00eb \u00e7\u00ebshtje tjet\u00ebr. Mund t\u00eb jeni thjesht nj\u00eb i guximsh\u00ebm i \u00e7mendur.<\/em> <\/p>\n<\/p>\n
Le t\u00eb kthehemi pak pas te Integrimi i Vazhduesh\u00ebm. Ne u shp\u00ebrngul\u00ebm n\u00eb nj\u00eb praktik\u00eb tjet\u00ebr t\u00eb komplikuar. <\/p>\n
<\/p>\n
Iluzione t\u00eb dyta jan\u00eb se MVP, thon\u00eb, duhet t\u00eb b\u00ebhet shpejt, prandaj testet nuk jan\u00eb t\u00eb nevojshme. Nuk \u00ebsht\u00eb gjithmon\u00eb k\u00ebshtu. E v\u00ebrteta \u00ebsht\u00eb se kur shkruani nj\u00eb tregim p\u00ebrdoruesi p\u00ebr MVP, mund ta zhvilloni at\u00eb n\u00eb m\u00ebnyr\u00eb t\u00eb lir\u00eb, dmth, e d\u00ebgjuat q\u00eb ekziston nj\u00eb tregim p\u00ebrdoruesi dhe menj\u00ebher\u00eb u nxit\u00ebt ta kodoni, ose t\u00eb punoni sipas TDD. N\u00eb praktik\u00ebn TDD, si\u00e7 tregon p\u00ebrvoja, nuk merr m\u00eb shum\u00eb koh\u00eb, dmth testet jan\u00eb nj\u00eb efekt an\u00ebsor. Praktika TDD nuk ka t\u00eb b\u00ebj\u00eb vet\u00ebm me testimin. Pavar\u00ebsisht se quhet Zhvillim i Drejtuar nga Testet, aty nuk flitet p\u00ebr testet. Kjo \u00ebsht\u00eb nj\u00eb qasje arkitektonike m\u00eb shum\u00eb. \u00cbsht\u00eb nj\u00eb m\u00ebnyr\u00eb se si t\u00eb shkruani pik\u00ebrisht at\u00eb q\u00eb nevojitet dhe t\u00eb mos shkruani at\u00eb q\u00eb nuk nevojitet. Kjo praktik\u00eb fokusohet n\u00eb iteracionin tuaj t\u00eb ardhsh\u00ebm t\u00eb zhvillimit t\u00eb mendjes n\u00eb lidhje me nd\u00ebrtimin e arkitektur\u00ebs s\u00eb aplikacionit.<\/em> <\/p>\n<\/p>\n
Prandaj, nuk \u00ebsht\u00eb kaq e leht\u00eb t\u00eb lirohemi nga k\u00ebto iluzione. MVP dhe testet nuk jan\u00eb n\u00eb kund\u00ebrshtim me nj\u00ebra-tjetr\u00ebn. M\u00eb shum\u00eb, n\u00eb fakt, n\u00ebse b\u00ebni MVP sipas praktik\u00ebs TDD, do ta b\u00ebni at\u00eb m\u00eb mir\u00eb dhe m\u00eb shpejt sesa n\u00ebse e b\u00ebni krejt\u00ebsisht lirisht, pa praktik\u00eb.<\/em><\/p>\n<\/p>\n
Kjo \u00ebsht\u00eb nj\u00eb mendim shum\u00eb i paqart\u00eb dhe i komplikuar. Kur d\u00ebgoni q\u00eb tani do t\u00eb shkruani edhe teste dhe p\u00ebr k\u00ebt\u00eb arsye do t\u00eb b\u00ebni di\u00e7ka m\u00eb shpejt, ting\u00ebllon krejt\u00ebsisht e pabesueshme. <\/p>\n
<\/p>\n
(Dmitri) K\u00ebtu shum\u00eb, kur p\u00ebrmendin MVP, e b\u00ebjn\u00eb at\u00eb sepse jan\u00eb len\u00eb t\u00eb shkruajn\u00eb di\u00e7ka normale. Dhe kjo \u00ebsht\u00eb ende gj\u00ebra t\u00eb ndryshme. Mos e shnd\u00ebrroni MVP n\u00eb di\u00e7ka t\u00eb keqe q\u00eb nuk funksionon.<\/em> <\/p>\n<\/p>\n
Po, po, ke t\u00eb drejt\u00eb.<\/p>\n
<\/p>\n
Dhe pastaj papritur MVP n\u00eb prodhim.<\/em><\/p>\n<\/p>\n
P\u00ebrher\u00eb. <\/p>\n
<\/p>\n
TDD ting\u00ebllon shum\u00eb e pazakont\u00eb, kur d\u00ebgjon q\u00eb po shkruan teste dhe duket se po b\u00ebn m\u00eb shum\u00eb pun\u00eb. Kjo ting\u00ebllon shum\u00eb e \u00e7uditshme, por n\u00eb t\u00eb v\u00ebrtet\u00eb kjo ndihmon q\u00eb t\u00eb b\u00ebsh gj\u00ebrat m\u00eb shpejt dhe m\u00eb bukur. Kur shkruan nj\u00eb test, tashm\u00eb mendon shum\u00eb p\u00ebr at\u00eb se \u00e7far\u00eb kodi do t\u00eb jet\u00eb dhe si do t\u00eb thirret, si dhe sjelljen q\u00eb presim prej tij. Nuk thua thjesht q\u00eb kam shkruar nj\u00eb funksion dhe ai b\u00ebn di\u00e7ka. S\u00eb pari mendon se ka k\u00ebto kushte dhe do t\u00eb thirret n\u00eb k\u00ebt\u00eb m\u00ebnyr\u00eb. K\u00ebt\u00eb e mbulon me teste dhe prej k\u00ebsaj kupton si do t\u00eb duken nd\u00ebrfaqet brenda kodit t\u00ebnd. Kjo ndikon shum\u00eb n\u00eb arkitektur\u00eb. Kodi yt automatikisht b\u00ebhet m\u00eb modular, sepse s\u00eb pari p\u00ebrpiqesh t\u00eb kuptosh si do ta testosh, dhe pastaj e shkruan. <\/p>\n
<\/p>\n
Kisha ime ndodhur me TDD q\u00eb n\u00eb nj\u00eb moment un\u00eb kam marr\u00eb nj\u00eb mentor p\u00ebr Ruby, kur ende isha programues n\u00eb Ruby. Ai tha: \"Le t'i b\u00ebjm\u00eb gj\u00ebrat sipas TDD.\" Dhe un\u00eb mendoja: \"Oj, tani do t\u00eb shkruaj di\u00e7ka shtes\u00eb.\" Ne u dakorduam q\u00eb p\u00ebr dy jav\u00eb t\u00eb shkruaja t\u00eb gjith\u00eb kodin funksional n\u00eb Python duke p\u00ebrdorur TDD. Pas dy jav\u00ebsh kuptova se nuk doja t\u00eb kthehesha mbrapsht. Pas dy jav\u00ebsh duke u p\u00ebrpjekur ta aplikoj kudo, kuptova sa m\u00eb e leht\u00eb ishte t\u00eb mendosh. Por kjo nuk \u00ebsht\u00eb e dukshme, prandaj e rekomandoj t\u00eb gjith\u00ebve, n\u00ebse keni ndjesin\u00eb se TDD \u00ebsht\u00eb e v\u00ebshtir\u00eb, e gjat\u00eb dhe e panevojshme, provoni ta mbani p\u00ebr dy jav\u00eb. Mua m\u00eb mjaftoi dy jav\u00eb p\u00ebr k\u00ebt\u00eb.<\/p>\n
<\/p>\n
(Dmitrij) Ne mund ta zhvillojm\u00eb k\u00ebt\u00eb mendim nga pik\u00ebpamja e funksionimit t\u00eb infrastruktur\u00ebs. Para se t\u00eb lancojm\u00eb di\u00e7ka t\u00eb re, ne b\u00ebjm\u00eb monitoring dhe pastaj e lan\u00e7ojm\u00eb. N\u00eb k\u00ebt\u00eb rast, monitorimi yn\u00eb b\u00ebhet nj\u00eb testim i zakonsh\u00ebm. Edhe zhvillimi p\u00ebrmes monitoring-ut. Por pothuajse t\u00eb gjith\u00eb thon\u00eb se \u00ebsht\u00eb e gjat\u00eb, m\u00eb len\u00eb, kam b\u00ebr\u00eb nj\u00eb skic\u00eb t\u00eb p\u00ebrkohshme. N\u00ebse e kemi b\u00ebr\u00eb monitoring-un si\u00e7 duhet, kuptojm\u00eb gjendjen e sistemit CI. N\u00eb sistemin CI ka shum\u00eb monitorim. Ne kuptojm\u00eb gjendjen e sistemit, kuptojm\u00eb \u00e7far\u00eb ka brenda. Dhe gjat\u00eb zhvillimit ne pik\u00ebrisht krijojm\u00eb sistemin q\u00eb ta sjellim n\u00eb gjendjen e d\u00ebshiruar.<\/em> <\/p>\n<\/p>\n
K\u00ebto praktika jan\u00eb t\u00eb njohura prej koh\u00ebsh. Ne e kemi diskutuar k\u00ebt\u00eb rreth 4 vjet m\u00eb par\u00eb. Por p\u00ebr 4 vjet praktikisht nuk ka ndryshuar asgj\u00eb.<\/em> <\/p>\n<\/p>\n
Por n\u00eb k\u00ebt\u00eb not\u00eb propozoj t\u00eb mbyllim diskutimin zyrtar.<\/em><\/p>\n<\/p>\n
Video (e futur si element media, por pse nuk funksionon):<\/p>\n
\nhttps:\/\/youtu.be\/zZ3qXVN3Oic<\/a><\/noindex> habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\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 […]<\/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\n\t
![\"Integrimi](\"\/wp-content\/uploads\/2020\/09\/ed8a32ae63b8dccfc8b4893ab27f1527.jpg\")
<\/p>\n