{"id":33725,"date":"2019-10-31T21:54:21","date_gmt":"2019-10-31T18:54:21","guid":{"rendered":"https:\/\/prohoster.info\/blog\/chto-takoe-devops\/"},"modified":"2019-10-31T21:54:21","modified_gmt":"2019-10-31T18:54:21","slug":"chto-takoe-devops","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sq\/blog\/administrirovanie\/chto-takoe-devops","title":{"rendered":"\u00c7far\u00eb \u00ebsht\u00eb DevOps","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

P\u00ebrcaktimi i DevOps \u00ebsht\u00eb shum\u00eb i nd\u00ebrlikuar, dhe p\u00ebr k\u00ebt\u00eb arsye ne duhet ta fillojm\u00eb diskutimin mbi k\u00ebt\u00eb tem\u00eb \u00e7do her\u00eb nga fillimi. Vet\u00ebm n\u00eb Habr ka mij\u00ebra publikime mbi k\u00ebt\u00eb \u00e7\u00ebshtje. Por n\u00ebse jeni duke e lexuar k\u00ebt\u00eb, me siguri e dini se \u00e7far\u00eb \u00ebsht\u00eb DevOps. Sepse un\u00eb \u2013 nuk e di. P\u00ebrsh\u00ebndetje, emri im \u00ebsht\u00eb Aleksand\u00ebr Titov (@osminog<\/a><\/noindex><\/b>), dhe ne thjesht do t\u00eb flasim p\u00ebr DevOps dhe un\u00eb do t\u00eb ndaj p\u00ebrvoj\u00ebn time.<\/p>\n

\"\u00c7far\u00eb
\n
\nKam menduar gjat\u00eb se si ta b\u00ebj tregimin tim t\u00eb dobish\u00ebm, prandaj do t\u00eb ket\u00eb shum\u00eb pyetje \u2013 ato q\u00eb i b\u00ebj vetes dhe ato q\u00eb u b\u00ebj klient\u00ebve t\u00eb kompanis\u00eb son\u00eb. Duke iu p\u00ebrgjigjur k\u00ebtyre pyetjeve, kuptimi b\u00ebhet m\u00eb i qart\u00eb. Do t\u00eb flas p\u00ebrse \u00ebsht\u00eb e nevojshme DevOps nga k\u00ebndv\u00ebshtrimi im, \u00e7far\u00eb \u00ebsht\u00eb kjo, s\u00ebrish nga pozita ime, dhe si t\u00eb kuptoni n\u00ebse po l\u00ebvizni drejt DevOps p\u00ebrs\u00ebri nga k\u00ebndv\u00ebshtrimi im. Pika e fundit do t\u00eb jet\u00eb p\u00ebrmes pyetjeve. Duke iu p\u00ebrgjigjur atyre vetes, do t\u00eb mundeni t\u00eb kuptoni n\u00ebse kompania juaj po l\u00ebviz drejt DevOps apo ka ndonj\u00eb problem.
\n<\/a><\/noindex>
\n

\r\n \"Luaj\r\n
<\/div>\r\n <\/div><\/center>
\nNj\u00eb periudh\u00eb, kam ndjekur dallg\u00ebt e shk\u00ebrmoqjes dhe blerjeve. Fillimisht punova n\u00eb nj\u00eb startup t\u00eb vog\u00ebl Qik, pastaj e bleu nj\u00eb kompani pak m\u00eb t\u00eb madhe Skype, e cila m\u00eb pas u ble nga nj\u00eb kompani edhe m\u00eb e madhe Microsoft. N\u00eb k\u00ebt\u00eb moment, m\u00eb u b\u00eb e qart\u00eb si transformohet p\u00ebrceptimi i DevOps n\u00eb kompani t\u00eb ndryshme sipas madh\u00ebsis\u00eb. Pas k\u00ebsaj, u b\u00ebra i interesuar p\u00ebr DevOps nga pik\u00ebpamja e tregut, dhe me koleg\u00ebt e mi organizuam kompanin\u00eb Ekspress 42. Tani e kat\u00ebr vjet ne l\u00ebvizim n\u00ebp\u00ebr dallg\u00ebt e tregut.<\/p>\n

P\u00ebrve\u00e7 t\u00eb gjitha, un\u00eb jam nj\u00eb nga organizator\u00ebt e komunitetit DevOps Moscow dhe organizator i DevOps -Days 2017, por n\u00eb 2018 nuk kam organizuar. Ekspress 42 punon me shum\u00eb kompani. Ne zhvillojm\u00eb atje DevOps, shikojm\u00eb si ndodh kjo, nxjerrim p\u00ebrfundime, analizojm\u00eb, tregojm\u00eb p\u00ebrfundimet tona t\u00eb gjith\u00eb, dhe fuqizojm\u00eb njer\u00ebzit me praktikat DevOps. N\u00eb p\u00ebrgjith\u00ebsi, ne po rrisim p\u00ebrvoj\u00ebn dhe ekspertiz\u00ebn n\u00eb k\u00ebt\u00eb drejtim.<\/p>\n

Pse DevOps<\/h2>\n

\nPyetja e par\u00eb q\u00eb ndjek t\u00eb gjith\u00eb \u00ebsht\u00eb \u2013 pse? Shum\u00eb konsiderojn\u00eb se DevOps \u00ebsht\u00eb thjesht automatizim ose nj\u00eb gj\u00eb e ngjashme q\u00eb tashm\u00eb ka qen\u00eb n\u00eb \u00e7do kompani.<\/p>\n

- Kishim Continuous Integration \u2013 do t\u00eb thot\u00eb se m\u00eb par\u00eb kishte DevOps, dhe p\u00ebrse na nevojitet e gjith\u00eb kjo? Aty jasht\u00eb arg\u00ebtohen, nd\u00ebrsa ne pengohemi nga puna!<\/i><\/p>\n

Pas 9 vjet\u00ebsh zhvillimi t\u00eb komunitetit dhe metodologjis\u00eb, tashm\u00eb \u00ebsht\u00eb e qart\u00eb se nuk jan\u00eb thjesht shk\u00eblqimet marketinguese, por akoma nuk \u00ebsht\u00eb plot\u00ebsisht e qart\u00eb pse \u00ebsht\u00eb e nevojshme. Si \u00e7do mjet dhe proces, DevOps ka objektiva t\u00eb caktuara q\u00eb n\u00eb fund zgjidh.<\/p>\n

E gjith\u00eb kjo \u00ebsht\u00eb e lidhur me faktin se bota po ndryshon. Ajo po largohet nga qasja enterprise, ku kompanit\u00eb shkojn\u00eb menj\u00ebher\u00eb drejt \u00ebndrr\u00ebs, si\u00e7 k\u00ebndonte klasiku yn\u00eb nga Peterburg, nga pika A n\u00eb pik\u00ebn B sipas nj\u00eb strategjie t\u00eb caktuar, me nj\u00eb struktur\u00eb t\u00eb nd\u00ebrtuar p\u00ebr k\u00ebt\u00eb. <\/p>\n

\"\u00c7far\u00eb
\n<\/p>\n

N\u00eb parim, gjith\u00e7ka n\u00eb IT duhet t\u00eb jet\u00eb nd\u00ebrtuar sipas k\u00ebtij qasjeje. K\u00ebtu IT p\u00ebrdoret ekskluzivisht p\u00ebr automatizimin e proceseve.<\/p><\/blockquote>\n

\nAutomatizimi nuk ndryshon shpesh, sepse kur nj\u00eb kompani po l\u00ebviz n\u00eb nj\u00eb rrug\u00eb t\u00eb njohur - \u00e7far\u00eb ka p\u00ebr t\u00eb ndryshuar? Funksionon - mos e prek. Tani n\u00eb bot\u00eb qasjet po ndryshojn\u00eb, dhe ajo q\u00eb quhet Agile flet p\u00ebr faktin se pika e fundit B nuk \u00ebsht\u00eb menj\u00ebher\u00eb e dukshme.<\/p>\n

\"\u00c7far\u00eb
\n
\nKur nj\u00eb kompani ec\u00ebn n\u00ebp\u00ebr treg, punon me klient\u00eb - ajo vazhdimisht eksploron tregun dhe ndryshon pik\u00ebn e fundit B. Dhe p\u00ebr sa m\u00eb shpesh kompani t\u00eb ndryshoj\u00eb drejtimin e saj, aq m\u00eb e suksesshme \u00ebsht\u00eb n\u00eb fund, sepse zgjedh m\u00eb shum\u00eb segmente tregu.<\/p>\n

Nj\u00eb strategji interesante e tregon nj\u00eb kompani q\u00eb mora vesh rishtazi. One Box Shave - nj\u00eb sh\u00ebrbim p\u00ebr dor\u00ebzimin e razorave dhe pajisjeve p\u00ebr kujdesin e trupit me abone n\u00eb nj\u00eb kuti. Ata din\u00eb t\u00eb personalizojn\u00eb \"kutin\u00eb\" e tyre p\u00ebr klient\u00eb t\u00eb ndrysh\u00ebm. Kjo merret me nj\u00eb softuer t\u00eb caktuar, i cili m\u00eb pas d\u00ebrgon porosin\u00eb n\u00eb nj\u00eb fabrik\u00eb koreane q\u00eb prodhon mallin.<\/p>\n

Ky produkt u ble nga kompania Unilever p\u00ebr 1 miliard dollar\u00eb. Tani ai konkurron me Gillette dhe ka marr\u00eb nj\u00eb pjes\u00eb t\u00eb konsiderueshme t\u00eb konsumator\u00ebve n\u00eb tregun amerikan. One Box Shave thot\u00eb:<\/p>\n

\u2014 4 blades? A jeni serioz? Pse ju nevojitet kjo - nuk p\u00ebrmir\u00ebson cil\u00ebsin\u00eb e rruajtjes. Nj\u00eb krem i ve\u00e7ant\u00eb, nj\u00eb arom\u00eb dhe nj\u00eb razor cil\u00ebsor me dy blades zgjidhin shum\u00eb m\u00eb tep\u00ebr se k\u00ebto kat\u00ebr blades budallaqe t\u00eb Gillette! K\u00ebshtu do t\u00eb arrijm\u00eb s\u00eb shpejti deri n\u00eb 10?<\/i><\/p>\n

K\u00ebshtu po ndryshon bota. Unilever deklaron se kan\u00eb nj\u00eb sistem IT t\u00eb shk\u00eblqyer q\u00eb e b\u00ebn k\u00ebt\u00eb t\u00eb mundur. N\u00eb fund, kjo duket si nj\u00eb koncept Time-to-market<\/b>, p\u00ebr t\u00eb cilin tashm\u00eb ka folur kushdo.<\/p>\n

\"\u00c7far\u00eb
\n
\nKonteksti i Time-to-market nuk q\u00ebndron n\u00eb frekuenc\u00ebn e publikimeve tona. Mund t\u00eb publikojm\u00eb shpesh, por ciklet e lan\u00e7imeve mund t\u00eb jen\u00eb t\u00eb gjata. N\u00ebse ciklet e lan\u00e7imeve me tre muaj mbivendosen, duke u shtyr\u00eb p\u00ebr nj\u00eb jav\u00eb, ndodhemi n\u00eb nj\u00eb situat\u00eb ku kompania duket se po publikon nj\u00eb her\u00eb n\u00eb jav\u00eb. Por, koha nga ideja deri n\u00eb realizimin final merr 3 muaj.<\/p>\n

Time-to-market \u00ebsht\u00eb p\u00ebr minimizimin e koh\u00ebs nga ideja deri n\u00eb realizimin p\u00ebrfundimtar.<\/p><\/blockquote>\n

\nN\u00eb k\u00ebt\u00eb rast, softi nd\u00ebrvepron me tregun. K\u00ebshtu, One Box Shave ka nj\u00eb faqe interneti p\u00ebr nd\u00ebrveprimin me klient\u00ebt. Ata nuk kan\u00eb shit\u00ebs \u2014 thjesht nj\u00eb faqe, ku vizitori klikoni dhe l\u00eb d\u00ebshira. Prandaj, faqja duhet t\u00eb nxjerr\u00eb vazhdimisht p\u00ebrmbajtje t\u00eb re, p\u00ebr t\u00eb p\u00ebrdit\u00ebsuar n\u00eb p\u00ebrputhje me d\u00ebshirat e klient\u00ebve. P\u00ebr shembull, n\u00eb Koren\u00eb e Jugut, njer\u00ebzit nuk rruhen nj\u00eblloj si n\u00eb Rusi, dhe ata preferojn\u00eb q\u00eb aroma e sapunit t\u00eb mos jet\u00eb ajo e pishave, por, p\u00ebr shembull, e karotave me vanilje.<\/p>\n

Duke qen\u00eb se nevojitet t\u00eb ndryshojm\u00eb shpejt p\u00ebrmbajtjen e faqes, zhvillimi i softit ndryshon ndjesh\u00ebm. N\u00ebp\u00ebrmjet softit, ne duhet t\u00eb kuptojm\u00eb se \u00e7far\u00eb d\u00ebshiron klienti. M\u00eb par\u00eb, e merrnim k\u00ebt\u00eb informacion p\u00ebrmes rrug\u00ebve alternative, p\u00ebr shembull, p\u00ebrmes menaxhimit t\u00eb biznesit. Pastaj projektinim, vendosnim k\u00ebrkesat n\u00eb sistemin IT dhe gjith\u00e7ka shkonin mir\u00eb. Tani \u00ebsht\u00eb ndryshe \u2014 softi projektizohet nga t\u00eb gjith\u00eb ata q\u00eb jan\u00eb t\u00eb p\u00ebrfshir\u00eb n\u00eb proces, p\u00ebrfshir\u00eb inxhinier\u00ebt, sepse ata kuptojn\u00eb p\u00ebrmes specifikave teknike se si funksionon tregu dhe gjithashtu ndajn\u00eb me biznesin njohurit\u00eb e tyre.<\/p>\n

P\u00ebr shembull, n\u00eb kompanin\u00eb Qik, papritur m\u00ebsuam se njer\u00ebzit e p\u00eblqejn\u00eb t\u00eb ngarkojn\u00eb lista kontaktesh n\u00eb server, dhe ata na ofruan nj\u00eb aplikacion. Fillimisht, ne nuk ishim menduar p\u00ebr k\u00ebt\u00eb. N\u00eb nj\u00eb kompani klasike, t\u00eb gjith\u00eb do t\u00eb kishin vendosur se \u00ebsht\u00eb nj\u00eb bug, sepse n\u00eb spesifikimet nuk \u00ebsht\u00eb shkruar se kjo duhet t\u00eb funksionoj\u00eb mir\u00eb, dhe n\u00eb p\u00ebrgjith\u00ebsi e kishim implementuar me shpejt\u00ebsi, do ta kishin \u00e7aktivizuar k\u00ebt\u00eb ve\u00e7ori dhe do t\u00eb thoshin: 'Kjo nuk \u00ebsht\u00eb e nevojshme p\u00ebr ask\u00ebnd, m\u00eb e r\u00ebnd\u00ebsishme \u00ebsht\u00eb se funksionaliteti kryesor punon.' Por, nj\u00eb kompani teknologjike e sheh k\u00ebt\u00eb si nj\u00eb mund\u00ebsi dhe fillon t\u00eb ndryshoj\u00eb softin n\u00eb p\u00ebrputhje me k\u00ebt\u00eb.<\/p>\n

\"\u00c7far\u00eb
\n
\nN\u00eb vitin 1968, nj\u00eb djal\u00eb i men\u00e7ur Melvin Conway formuloj\u00eb iden\u00eb e m\u00ebposhtme.<\/p>\n

Organizata q\u00eb krijon nj\u00eb sistem \u00ebsht\u00eb e kufizuar nga dizajni, i cili kopjon struktur\u00ebn e komunikimit n\u00eb k\u00ebt\u00eb organizat\u00eb.<\/p><\/blockquote>\n

\nN\u00ebse flasim m\u00eb holl\u00ebsisht, p\u00ebr t\u00eb prodhuar sisteme t\u00eb tjera, ju nevojitet gjithashtu nj\u00eb struktur\u00eb komunikimi brenda kompanis\u00eb q\u00eb \u00ebsht\u00eb e ndryshme. N\u00ebse keni nj\u00eb struktur\u00eb komunikimi t\u00eb lart\u00eb hierarkike, kjo nuk do t'ju lejoj\u00eb t\u00eb krijoni sisteme q\u00eb mund t\u00eb ofrojn\u00eb nj\u00eb nivel shum\u00eb t\u00eb lart\u00eb t\u00eb Time-to-market.<\/p>\n

Lexoni p\u00ebr ligjin e Conway<\/a><\/noindex> mund t\u00eb n\u00eb lidhje me<\/a><\/noindex>. Ai \u00ebsht\u00eb i r\u00ebnd\u00ebsish\u00ebm p\u00ebr t\u00eb kuptuar kultur\u00ebn ose filozofin\u00eb DevOps, pasi e vetmja gj\u00eb q\u00eb ndryshon bazikisht n\u00eb DevOps \u00ebsht\u00eb struktura e komunikimit midis ekipeve<\/b>.<\/p>\n

Nga pik\u00ebpamja e procesit, deri n\u00eb DevOps t\u00eb gjitha fazat: analiza, zhvillimi, testimi, operimi, kan\u00eb kaluar n\u00eb m\u00ebnyr\u00eb lineare.\"\u00c7far\u00eb
\nN\u00eb rastin e DevOps, t\u00eb gjith\u00eb k\u00ebto procese ndodhin nj\u00ebkoh\u00ebsisht.<\/p>\n

\"\u00c7far\u00eb
\n
\nTime-to-market mund t\u00eb p\u00ebrmbush\u00ebt vet\u00ebm k\u00ebshtu. P\u00ebr njer\u00ebzit q\u00eb kan\u00eb punuar n\u00eb procesin e vjet\u00ebr, kjo duket disi ndryshe, dhe n\u00eb p\u00ebrgjith\u00ebsi jo e leht\u00eb.<\/p>\n

Pra, p\u00ebrse nevojitet DevOps?<\/h3>\n

\nP\u00ebr zhvillimin e produkteve digjitale<\/b>. N\u00ebse n\u00eb kompanin\u00eb tuaj nuk ka nj\u00eb produkt digjital, DevOps nuk \u00ebsht\u00eb i nevojsh\u00ebm - kjo \u00ebsht\u00eb shum\u00eb e r\u00ebnd\u00ebsishme.<\/p>\n

DevOps kalon kufijt\u00eb e shpejt\u00ebsis\u00eb s\u00eb nj\u00eb skeme prodhimi lineare t\u00eb softuerit<\/b>. N\u00eb t\u00eb, t\u00eb gjitha proceset ndodhin nj\u00ebkoh\u00ebsisht.<\/p>\n

Rritet kompleksiteti.<\/b> Kur evangelist\u00ebt e DevOps flasin se me t\u00eb do t'ju b\u00ebhet m\u00eb e leht\u00eb t\u00eb publikoni softuer - kjo \u00ebsht\u00eb nj\u00eb marr\u00ebzi.<\/p>\n

Me DevOps, gjith\u00e7ka do t\u00eb jet\u00eb m\u00eb e komplikuar.<\/p><\/blockquote>\n

\nN\u00eb konferenc\u00eb, n\u00eb stend\u00ebn e Avito, mund t\u00eb shihni se \u00e7far\u00eb do t\u00eb thot\u00eb t\u00eb dezdeployosh nj\u00eb kontejner Docker - nj\u00eb detyr\u00eb e pamundshme. Kompleksiteti b\u00ebhet jasht\u00ebzakonisht i lart\u00eb, duhet t\u00eb luani me shum\u00eb tops nj\u00ebkoh\u00ebsisht.<\/p>\n

DevOps ndryshon plot\u00ebsisht procesin dhe organizat\u00ebn n\u00eb kompani<\/b>\u00a0n\u00eb fakt, nuk e ndryshon DevOps, por produkti digjital. P\u00ebr t\u00eb arritur n\u00eb DevOps, duhet t\u00eb ndryshoni plot\u00ebsisht k\u00ebt\u00eb proces.<\/p>\n

Pyetje p\u00ebr specialistin<\/h3>\n

\nDhe \u00e7far\u00eb p\u00ebr ju? Pyetje q\u00eb mund t'i b\u00ebni vetes, duke punuar n\u00eb kompani dhe duke u zhvilluar si specialist.<\/p>\n

A keni strategji p\u00ebr krijimin e nj\u00eb produkti digjital?<\/b> N\u00ebse po - \u00ebsht\u00eb mir\u00eb. Kjo do t\u00eb thot\u00eb se kompanis\u00eb tuaj po ec\u00ebn drejt DevOps.<\/p>\n

A po krijon kompania juaj nj\u00eb produkt digjital?<\/b> Kjo do t\u00eb thot\u00eb se mund t\u00eb ngjiteni edhe nj\u00eb shkall\u00eb m\u00eb lart, t\u00eb angazhoheni n\u00eb aktivitete m\u00eb interesante - nga pik\u00ebpamja e DevOps p\u00ebrs\u00ebri. Un\u00eb flas vet\u00ebm nga ky k\u00ebndv\u00ebshtrim.<\/p>\n

A \u00ebsht\u00eb kompania juaj nj\u00eb nga lider\u00ebt e tregut n\u00eb ni\u0161\u00ebn e produkteve digjitale?<\/b> Spotify, Yandex, Uber \u2014 kompani q\u00eb jan\u00eb n\u00eb kulmin e p\u00ebrparimit teknologjik tanim\u00eb.<\/p>\n

Beni vet\u00eb k\u00ebto pyetje dhe n\u00ebse t\u00eb gjitha p\u00ebrgjigjet jan\u00eb negative, ndoshta nuk duhet t\u00eb angazhoheni me DevOps n\u00eb k\u00ebt\u00eb kompani. Megjithat\u00eb, n\u00ebse tema e DevOps \u00ebsht\u00eb me t\u00eb v\u00ebrtet\u00eb interesante p\u00ebr ju, ndoshta\u2026 duhet t\u00eb kaloni n\u00eb nj\u00eb kompani tjet\u00ebr? N\u00ebse kompania juaj d\u00ebshiron t\u00eb hyj\u00eb n\u00eb DevOps, por ju p\u00ebrgjithsisht keni p\u00ebrgjigjur \"Jo\", at\u00ebher\u00eb ajo i ngjan k\u00ebtij rhinoceros-i t\u00eb shk\u00eblqyer q\u00eb kurr\u00eb nuk do t\u00eb ndryshoj\u00eb.<\/p>\n

\"\u00c7far\u00eb
\n<\/p>\n

Organizata<\/h2>\n

\nSi\u00e7 e thash\u00eb, sipas ligjit t\u00eb Conway-t, organizimi n\u00eb kompani ndryshon. Filloj me at\u00eb q\u00eb pengon DevOps t\u00eb hyj\u00eb brenda kompanis\u00eb pik\u00ebrisht nga k\u00ebndv\u00ebshtrimi i organizat\u00ebs.<\/p>\n

Problemi i \"kolonave\"<\/h3>\n

\nFjala angleze \"Silo\" \u00ebsht\u00eb p\u00ebrkthyer k\u00ebtu n\u00eb rusisht si \"kolon\u00eb\". Kuptimi i k\u00ebtij problemi \u00ebsht\u00eb se nuk ka shk\u00ebmbim informacioni midis ekipeve.<\/b>\u00c7do ekip thellon ekspertiz\u00ebn e vet, duke mos nd\u00ebrtuar nj\u00eb hart\u00eb t\u00eb p\u00ebrbashk\u00ebt, n\u00eb t\u00eb cil\u00ebn mund t\u00eb orientohesh.<\/p>\n

Kjo i ngjan nj\u00eb njeriu q\u00eb sapo ka mb\u00ebrritur n\u00eb Mosk\u00eb dhe ende nuk di t\u00eb orientoheshe sipas hart\u00ebs s\u00eb metros\u00eb. Moskvat zakonisht e din\u00eb mir\u00eb rajonin e tyre, nd\u00ebrsa n\u00eb t\u00eb gjith\u00eb Mosk\u00ebn orientohen sipas hart\u00ebs s\u00eb metros\u00eb. Kur arrin n\u00eb Mosk\u00eb p\u00ebr her\u00eb t\u00eb par\u00eb, nuk e ke k\u00ebt\u00eb aft\u00ebsi, dhe thjesht je i humbur.<\/p>\n

DevOps ofron t\u00eb kalosh k\u00ebt\u00eb moment t\u00eb dezinformimit dhe t\u00eb nd\u00ebrtosh s\u00eb bashku nj\u00eb hart\u00eb t\u00eb p\u00ebrbashk\u00ebt t\u00eb bashk\u00ebpunimit nga t\u00eb gjitha n\u00ebn-nj\u00ebsit\u00eb.<\/p><\/blockquote>\n

\nDy faktor\u00eb pengojn\u00eb k\u00ebt\u00eb.<\/p>\n

Pasojat e sistemit korporativ t\u00eb menaxhimit.<\/b> Ai \u00ebsht\u00eb nd\u00ebrtuar me \"kolona\" hierarkike t\u00eb ve\u00e7anta. P\u00ebr shembull, ka KPI t\u00eb caktuara n\u00eb kompani q\u00eb e mb\u00ebshtesin k\u00ebt\u00eb sistem. Nga ana tjet\u00ebr, pengon edhe truri i njeriut, i cili ka v\u00ebshtir\u00ebsi t\u00eb dal\u00eb jasht\u00eb ekspertiz\u00ebs s\u00eb tij dhe t\u00eb orientohet n\u00eb t\u00ebr\u00eb sistemin. Kjo \u00ebsht\u00eb thjesht e pak\u00ebndshme. Imagjinoni se keni shkuar n\u00eb aeroportin e Bangkokut \u2014 atje nuk orientohesh leht\u00ebsisht. Po ashtu \u00ebsht\u00eb e v\u00ebshtir\u00eb t\u00eb orientohesh n\u00eb DevOps, ndaj njer\u00ebzit thon\u00eb se duhet t\u00eb gjesh nj\u00eb udh\u00ebrr\u00ebfyes p\u00ebr t\u00eb hyr\u00eb atje.<\/p>\n

Por gj\u00ebja m\u00eb e r\u00ebnd\u00ebsishme \u00ebsht\u00eb se problemi i \"kolonave\" p\u00ebr inxhinierin q\u00eb ka p\u00ebrqafuar shpirtin e DevOps-it, ka lexuar Fowler-in dhe nj\u00eb s\u00ebr\u00eb librash t\u00eb tjer\u00eb, shprehet n\u00eb k\u00ebt\u00eb m\u00ebnyr\u00eb \"kolonat\" nuk lejojn\u00eb t\u00eb b\u00ebhen gj\u00ebra \"t\u00eb dukshme\"<\/b>. Ne shpesh mblidhemi pas DevOps Moscow, flasim me nj\u00ebri-tjetrin dhe njer\u00ebzit ankojn\u00eb:<\/p>\n

\u2014 Ne dojaht\u00ebm vet\u00ebm t\u00eb nisim CI, por rezultoi q\u00eb menaxhmenti nuk e do at\u00eb.<\/i><\/p>\n

Kjo ndodh pik\u00ebrisht p\u00ebr shkak se\u00a0CI <\/b>dhe\u00a0Procesi i D\u00ebrges\u00ebs s\u00eb P\u00ebrhershme<\/b> jan\u00eb n\u00eb kufirin e shum\u00eb ekspertizave. Thjesht, duke mos e kaluar problemin e \"pushtimin\" n\u00eb nivelin organizativ, nuk do t\u00eb mund t\u00eb p\u00ebrparoni m\u00eb tej, pavar\u00ebsisht se \u00e7far\u00eb b\u00ebni dhe sa t\u00eb trishtuesh\u00ebm \u00ebsht\u00eb kjo.<\/p>\n

\"\u00c7far\u00eb
\n
\n\u00c7do pjes\u00ebmarr\u00ebs n\u00eb proces n\u00eb kompani: zhvilluesit e backend dhe frontend, testimi, DBA, operimi, rrjeti, punon n\u00eb drejtimin e tij, nd\u00ebrsa askush nuk ka nj\u00eb hart\u00eb t\u00eb p\u00ebrbashk\u00ebt, p\u00ebrve\u00e7 menaxherit, i cili i v\u00eb re dhe menaxhon me metod\u00ebn \"ndaje dhe sundo\".<\/p>\n

Njer\u00ebzit luftojn\u00eb p\u00ebr disa yje ose flamuj, secili punon n\u00eb ekspertiz\u00ebn e tij.<\/p><\/blockquote>\n

\nSi rezultat, kur shfaqet detyra p\u00ebr t'i lidhur t\u00eb gjitha k\u00ebto s\u00eb bashku dhe p\u00ebr t\u00eb nd\u00ebrtuar nj\u00eb pipeline t\u00eb p\u00ebrbashk\u00ebt, dhe e t\u00ebra p\u00ebr yjet dhe flamujt tashm\u00eb nuk ka nevoj\u00eb p\u00ebr luft\u00eb, lind pyetja - \u00e7far\u00eb t\u00eb b\u00ebjm\u00eb gjithsesi? Duhet t\u00eb arrijm\u00eb nj\u00eb marr\u00ebveshje, por si ta b\u00ebjm\u00eb k\u00ebt\u00eb, askush n\u00eb shkoll\u00eb nuk na m\u00ebsoi. Edhe nga shkolla, ne jemi m\u00ebsuar: klasa e tet\u00eb - oh! - n\u00eb krahasim me klas\u00ebn e shtat\u00eb! K\u00ebtu \u00ebsht\u00eb e nj\u00ebjta gj\u00eb.<\/p>\n

A \u00ebsht\u00eb ndryshe n\u00eb kompanin\u00eb tuaj?<\/h3>\n

\nP\u00ebr ta verifikuar k\u00ebt\u00eb, mund t\u00eb b\u00ebni k\u00ebto pyetje p\u00ebr veten.<\/p>\n

A p\u00ebrdorin ekipet mjete t\u00eb p\u00ebrbashk\u00ebta, a kontribuojn\u00eb n\u00eb ndryshimet e k\u00ebtyre mjeteve t\u00eb p\u00ebrbashk\u00ebta?<\/p>\n

Sa shpesh p\u00ebrshtaten ekipet - a ka ndonj\u00ebher\u00eb specialist\u00eb t\u00eb nj\u00eb ekipi q\u00eb kalojn\u00eb n\u00eb nj\u00eb ekip tjet\u00ebr?<\/b> N\u00eb mjedisin DevOps, kjo b\u00ebhet normale, sepse ndonj\u00ebher\u00eb nj\u00eb person thjesht nuk mund t\u00eb kuptoj\u00eb se \u00e7far\u00eb b\u00ebn nj\u00eb zon\u00eb tjet\u00ebr ekspertize. Ai kalon n\u00eb nj\u00eb departament tjet\u00ebr, punon atje p\u00ebr dy jav\u00eb p\u00ebr t\u00eb krijuar nj\u00eb hart\u00eb orientimi dhe bashk\u00ebpunimi me k\u00ebt\u00eb departament.<\/p>\n

A \u00ebsht\u00eb e mundur t\u00eb krijohet nj\u00eb komitet p\u00ebr ndryshime dhe t\u00eb b\u00ebhet ndonj\u00eb ndryshim? <\/b>Apo p\u00ebr k\u00ebt\u00eb k\u00ebrkohet nj\u00eb dor\u00eb e fort\u00eb e udh\u00ebheqjes m\u00eb t\u00eb lart\u00eb dhe nj\u00eb urdh\u00ebr? S\u00eb fundmi kam shkruar n\u00eb Facebook, si nj\u00eb bank\u00eb e panjohur, p\u00ebrmes urdh\u00ebresave implementon mjete: shkruan nj\u00eb urdh\u00ebr, nj\u00eb vit e implementojm\u00eb, shohim \u00e7far\u00eb ndodh. Kjo, sigurisht, \u00ebsht\u00eb e gjat\u00eb dhe e trishtueshme.<\/p>\n

Sa e r\u00ebnd\u00ebsishme \u00ebsht\u00eb p\u00ebr menaxher\u00ebt t\u00eb marrin arritje personale pa marr\u00eb parasysh arritjet e kompanis\u00eb? <\/b><\/p>\n

N\u00ebse ju p\u00ebrgjigjeni k\u00ebtyre pyetjeve, do t\u00eb kuptoni m\u00eb mir\u00eb n\u00ebse keni nj\u00eb problem t\u00eb till\u00eb n\u00eb kompani.<\/p>\n

Infrastruktura si kod<\/h2>\n

\nPas k\u00ebtij problemi, praktika e par\u00eb e r\u00ebnd\u00ebsishme, pa t\u00eb cil\u00ebn \u00ebsht\u00eb e v\u00ebshtir\u00eb t\u00eb avancosh m\u00eb tej n\u00eb DevOps, \u00ebsht\u00eb infrastruktura si kod<\/b>. <\/p>\n

Shpesh infrastruktura si kod perceptohet si:<\/p>\n

- Le t\u00eb automatizojm\u00eb gjith\u00e7ka me bash, t\u00eb mbushim me skripte, n\u00eb m\u00ebnyr\u00eb q\u00eb admin\u00ebt t\u00eb ken\u00eb m\u00eb pak pun\u00eb manuale!<\/i><\/p>\n

Por kjo nuk \u00ebsht\u00eb ashtu.<\/p>\n

Infrastruktura si kod n\u00ebnkupton q\u00eb sistemin IT me t\u00eb cilin punoni, e p\u00ebrshkruani n\u00eb form\u00eb kodi, p\u00ebr t\u00eb kuptuar vazhdimisht gjendjen e tij.<\/p><\/blockquote>\n

\nN\u00eb bashk\u00ebpunim me ekipet e tjera, krijoni nj\u00eb hart\u00eb n\u00eb form\u00eb kodi, e cila \u00ebsht\u00eb e qart\u00eb p\u00ebr t\u00eb gjith\u00eb dhe n\u00eb t\u00eb cil\u00ebn mund t\u00eb orientoheni, t\u00eb navigoni. Nuk ka r\u00ebnd\u00ebsi se me \u00e7far\u00eb \u00ebsht\u00eb b\u00ebr\u00eb - Chef, Ansible, Salt, ose n\u00ebse p\u00ebrdoren skedar\u00ebt YAML n\u00eb Kubernetes - nuk ka ndryshim.<\/p>\n

N\u00eb konferenc\u00eb, nj\u00eb koleg nga 2GIS tregoi se si ata krijuan mjetin e tyre t\u00eb brendsh\u00ebm p\u00ebr Kubernetes, i cili p\u00ebrshkruan struktur\u00ebn e sistemeve t\u00eb ve\u00e7anta. P\u00ebr t\u00eb p\u00ebrshkruar 500 sisteme, ata kishin nevoj\u00eb p\u00ebr nj\u00eb mjet t\u00eb ve\u00e7ant\u00eb q\u00eb e gjeneron k\u00ebt\u00eb p\u00ebrshkrim. Kur ka k\u00ebt\u00eb p\u00ebrshkrim, secili mund t\u00eb kontrolloj\u00eb nj\u00ebri-tjetrin, t\u00eb monitoroj\u00eb ndryshimet, si mund t\u00eb ndryshohet dhe p\u00ebrmir\u00ebsohet, \u00e7far\u00eb mungon. <\/p>\n

Pranojeni, skriptet e ve\u00e7anta bash zakonisht nuk ofrojn\u00eb k\u00ebt\u00eb kuptim. N\u00eb nj\u00eb nga kompanit\u00eb ku kam punuar, kishte madje nj\u00eb em\u00ebr \"write only\"-skript - kur skripti shkruhet, por q\u00eb leximi i tij b\u00ebhet i pamundur. Mendoj se kjo \u00ebsht\u00eb e njohur p\u00ebr ju gjithashtu.<\/p>\n

Infrastruktura si kod \u00ebsht\u00eb kodi q\u00eb p\u00ebrshkruan gjendjen aktuale t\u00eb infrastruktur\u00ebs<\/b>. Ky kod punon n\u00eb m\u00ebnyr\u00eb bashk\u00ebpunuese nga shum\u00eb ekipe produktesh, infrastrukture dhe sh\u00ebrbimi, dhe, m\u00eb e r\u00ebnd\u00ebsishmja, t\u00eb gjitha duhet t\u00eb kuptojn\u00eb se si funksionon ky kod.<\/p>\n

Kodi shoq\u00ebrohet sipas praktikave m\u00eb t\u00eb mira t\u00eb pun\u00ebs me kodin<\/b>: zhvillimi i p\u00ebrbashk\u00ebt, rivler\u00ebsimi i kodit, XP-programim, testimi, k\u00ebrkesat p\u00ebr t\u00ebrheqje, CI p\u00ebr infrastrukturat e kodit - t\u00eb gjitha k\u00ebto jan\u00eb t\u00eb dobishme dhe mund t\u00eb p\u00ebrdoren.<\/p>\n

Kodi b\u00ebhet nj\u00eb gjuh\u00eb e p\u00ebrbashk\u00ebt p\u00ebr t\u00eb gjith\u00eb inxhinier\u00ebt.<\/p><\/blockquote>\n

\nNdryshimi i infrastruktur\u00ebs n\u00eb kod nuk merr shum\u00eb koh\u00eb<\/b>. Po, n\u00eb kodin e infrastruktur\u00ebs gjithashtu mund t\u00eb ket\u00eb borxhe teknike. Zakonisht ekipet p\u00ebrballen me to rreth nj\u00eb vit e gjysm\u00eb pasi filluan t\u00eb implementojn\u00eb \"infrastrukturen si kod\" n\u00eb form\u00ebn e nj\u00eb grumbulli skriptesh ose madje Ansible, t\u00eb cilin e shkruajn\u00eb si kod spaghetti, dhe p\u00ebr m\u00eb tep\u00ebr hedhin skripte bash n\u00eb t\u00eb! <\/p>\n

\u00cbht\u00eb e r\u00ebnd\u00ebsishme<\/b>: n\u00ebse nuk e keni provuar akoma k\u00ebt\u00eb, mbani mend se Ansible - nuk \u00ebsht\u00eb bash<\/b>! Lexoni me kujdes dokumentacionin, studioni se \u00e7far\u00eb shkruhet n\u00eb lidhje me k\u00ebt\u00eb.<\/p>\n

Infrastruktura si kod \u00ebsht\u00eb ndarja e kodit Infrastrukturor n\u00eb shtresa t\u00eb ve\u00e7anta.<\/p><\/blockquote>\n

\nNe n\u00eb kompanin\u00eb ton\u00eb dallojm\u00eb 3 shtresa baz\u00eb, t\u00eb cilat jan\u00eb shum\u00eb t\u00eb qarta dhe t\u00eb thjeshta, por mund t\u00eb ket\u00eb m\u00eb shum\u00eb. Mund t\u00eb shqyrtoni kodin tuaj infrastrukturore dhe t\u00eb thoni, a keni k\u00ebt\u00eb kusht apo jo. N\u00ebse nuk ka asnj\u00eb shtres\u00eb t\u00eb ndar\u00eb, at\u00ebher\u00eb duhet t\u00eb gjeni koh\u00eb dhe t\u00eb refaktoroni pak.
\n\"\u00c7far\u00eb
\n
\nShtresa e baz\u00ebs<\/b>\u00a0\u00ebsht\u00eb si t\u00eb konfigurohet OS, backup-et dhe gj\u00ebra t\u00eb tjera me nivel t\u00eb ul\u00ebt, p\u00ebr shembull, si t\u00eb veproni Kubernetes n\u00eb nivelin themelor.<\/p>\n

Niveli i sh\u00ebrbimeve<\/b>\u00a0\u00ebsht\u00eb ato sh\u00ebrbime q\u00eb ju ofroni zhvilluesit: logim si sh\u00ebrbim, monitorim si sh\u00ebrbim, baz\u00eb t\u00eb dh\u00ebnash si sh\u00ebrbim, balancues si sh\u00ebrbim, radh\u00eb si sh\u00ebrbim, Continuous Delivery si sh\u00ebrbim - nj\u00eb mori sh\u00ebrbimesh q\u00eb ekipet e ve\u00e7anta mund t\u00eb ofrojn\u00eb p\u00ebr zhvillimin. T\u00eb gjitha k\u00ebto nevojitet t\u00eb p\u00ebrshkruhen si module t\u00eb ve\u00e7anta n\u00eb sistemin tuaj t\u00eb menaxhimit t\u00eb konfigurimeve.<\/p>\n

Shtresa, ku b\u00ebhen aplikacionet<\/b> dhe p\u00ebrshkruhet se si do t\u00eb implementohen mbi dy shtresat e m\u00ebparshme.<\/p>\n

Pyetje kontrolluese<\/h3>\n

\nA keni n\u00eb kompanin\u00eb tuaj nj\u00eb depozit\u00eb infrastrukurale t\u00eb p\u00ebrgjithshme? A kontrolloni borxhin teknik n\u00eb infrastruktur\u00eb? A p\u00ebrdorni praktikat e zhvillimit n\u00eb depozit\u00ebn infrastrukurale? A \u00ebsht\u00eb infrastruktura juaj e ndar\u00eb n\u00eb shtresa? Mund t\u00eb kontrolloni me diagramin Base-service-APP. Sa e v\u00ebshtir\u00eb \u00ebsht\u00eb t\u00eb b\u00ebni nj\u00eb ndryshim? <\/p>\n

N\u00ebse keni pasur p\u00ebrvoj\u00ebn se ndryshimi ka zgjatur nj\u00eb dit\u00eb e gjysm\u00eb, do t\u00eb thot\u00eb se ju keni p\u00ebrdorur borxhin teknik dhe me t\u00eb duhet punuar. Ju sapo keni hasur pengesat e borxhit teknik n\u00eb kodin infrastruktural. Un\u00eb e mbaj mend shum\u00eb storie t\u00eb tilla, kur p\u00ebr t\u00eb ndryshuar ndonj\u00eb CCTL, duhet t\u00eb riprogramoni gjysm\u00ebn e kodit infrastruktural, sepse krijimtarin\u00eb dhe d\u00ebshir\u00ebn p\u00ebr t\u00eb automatizuar gjith\u00e7ka e kan\u00eb \u00e7uar n\u00eb at\u00eb q\u00eb \u00ebsht\u00eb bllokuar \u00e7do gj\u00eb, t\u00eb gjitha duart jan\u00eb larguar, dhe duhet refaktoruara.<\/p>\n

Dharja e vazhdueshme<\/h2>\n

\nDo t\u00eb b\u00ebjm\u00eb nj\u00eb trajtim t\u00eb debiti dhe krediti. Fillimisht prezantohet p\u00ebrshkrimi i infrastruktur\u00ebs, i cili mund t\u00eb jet\u00eb mjaft bazik. Nuk \u00ebsht\u00eb e nevojshme t\u00eb p\u00ebrshkruani gjith\u00e7ka n\u00eb detaje, por ndonj\u00eb p\u00ebrshkrim bazik k\u00ebrkohet q\u00eb t\u00eb mund t\u00eb punoni me t\u00eb. Ndryshe, nuk kuptohet mbi \u00e7far\u00eb do t\u00eb b\u00ebni m\u00eb tej p\u00ebr shp\u00ebrndarjen e vazhdueshme. T\u00eb gjitha k\u00ebto praktika zhvillohen n\u00eb t\u00eb nj\u00ebjt\u00ebn koh\u00eb kur kaloni n\u00eb DevOps, por duhet t\u00eb filloni nga kuptimi i asaj q\u00eb keni dhe si ta menaxhoni at\u00eb. Kjo \u00ebsht\u00eb pika e praktikes 'infrastruktur\u00eb si kod'.<\/p>\n

Pas asaj q\u00eb keni kuptuar se \u00e7far\u00eb keni, si ta menaxhoni at\u00eb, filloni t\u00eb mendoni se si ta d\u00ebrgoni kodin e zhvilluesit sa m\u00eb shpejt n\u00eb prodhim. Kam parasysh s\u00eb bashku me zhvilluesit - kujtojm\u00eb problemin e 'pushtimeve', dmth nuk jan\u00eb njer\u00ebz t\u00eb ve\u00e7ant\u00eb q\u00eb e mendojn\u00eb k\u00ebt\u00eb, por ekip.<\/p>\n

Kur ne\u00a0me Vanya Evtuhoichin<\/b> pash\u00eb librin e par\u00eb t\u00eb Jez Hambles<\/b> dhe grupit t\u00eb autor\u00ebve \u2018Continuous Delivery\u2019<\/b>, i cili doli n\u00eb vitin 2009, menduam gjat\u00eb p\u00ebr si ta p\u00ebrkthejm\u00eb titullin e tij n\u00eb gjuh\u00ebn ruse. Donim ta p\u00ebrkthenim si \u2018P\u00ebrcjellje t\u00eb vazhdueshme\u2019, por, p\u00ebr fat t\u00eb keq, e p\u00ebrkthyem si \u2018D\u00ebrges\u00eb e vazhdueshme\u2019. M\u00eb duket se n\u00eb titullin ton\u00eb ka di\u00e7ka ruse, me forc\u00eb.<\/p>\n

T\u00eb d\u00ebrgosh vazhdimisht do t\u00eb thot\u00eb<\/h3>\n

\nKodi, q\u00eb ndodhet n\u00eb depo produkti, gjithmon\u00eb mund t\u00eb d\u00ebrgohet n\u00eb prodhim<\/b>. Ai mund t\u00eb mos d\u00ebrgohet, por gjithmon\u00eb \u00ebsht\u00eb gati p\u00ebr k\u00ebt\u00eb. Prandaj, ju gjithmon\u00eb shkruani kod me nj\u00eb ndjenj\u00eb t\u00eb v\u00ebshtir\u00eb p\u00ebr t\u00eb shpjeguar e shqet\u00ebsim n\u00ebn kock\u00ebn e pasme. Kjo ndjenj\u00eb shqet\u00ebsimi duhet t\u00eb jet\u00eb e pranishme - ajo shkakton procese mendore q\u00eb lejojn\u00eb t\u00eb shkruani kod ndryshe. Kjo duhet t\u00eb regjistrohet n\u00eb rregullat brenda zhvillimit.<\/p>\n

P\u00ebr t\u00eb d\u00ebrguar vazhdimisht, k\u00ebrkohet nj\u00eb format arti q\u00eb kalon n\u00ebp\u00ebr platform\u00ebn infrastrukturore. <\/b>N\u00ebse ju hedhin \u2018mbeturina\u2019 me formate t\u00eb ndryshme n\u00ebp\u00ebr platform\u00ebn infrastrukturore, at\u00ebher\u00eb ajo b\u00ebhet jo e unifikuar, b\u00ebhet e v\u00ebshtir\u00eb p\u00ebr t'u mbajtur, lind problemi i borxhit teknik. Formati i artefaktit duhet t\u00eb rregullohet - kjo \u00ebsht\u00eb gjithashtu nj\u00eb detyr\u00eb kolektive: duhet t\u00eb mblidhemi t\u00eb gjith\u00eb bashk\u00eb, t\u00eb k\u00ebshillohemi dhe t\u00eb imagjinojm\u00eb k\u00ebt\u00eb format.<\/p>\n

Artefakti vazhdon t\u00eb p\u00ebrmir\u00ebsohet dhe ndryshoj\u00eb sipas mjedisit t\u00eb prodhimit gjat\u00eb kalimit p\u00ebrmes pipeline-it t\u00eb dor\u00ebzimit. <\/b>Kur artefakti l\u00ebviz p\u00ebrmes pipeline-it, ai p\u00ebrballet vazhdimisht me disa gj\u00ebra q\u00eb jan\u00eb t\u00eb pak\u00ebndshme p\u00ebr t\u00eb, t\u00eb cilat i ngjajn\u00eb asaj q\u00eb ndodh me artefaktin q\u00eb e publikoni n\u00eb prodhim. N\u00eb zhvillimin klasik, k\u00ebt\u00eb e b\u00ebn administrator sistemi q\u00eb realizon p\u00ebrdit\u00ebsimin, nd\u00ebrsa n\u00eb procesin DevOps, kjo ndodh vazhdimisht: k\u00ebtu ai kalon n\u00ebp\u00ebr disa teste, aty \u2013 hidhet n\u00eb klasterin Kubernetes, i cili \u00ebsht\u00eb m\u00eb shum\u00eb-m\u00eb pak si prodhimi, dhe aty papritur fillon testimi me ngarkes\u00eb.<\/p>\n

Kjo ndonj\u00ebher\u00eb i ngjan loj\u00ebs Pacman \u2013 artefakti kalon nj\u00eb histori. Aty \u00ebsht\u00eb e r\u00ebnd\u00ebsishme t\u00eb kontrolloni n\u00ebse kodi realisht kalon historin\u00eb dhe n\u00ebse ajo lidhet me prodhimin tuaj. Historit\u00eb nga prodhimi mund t\u00eb p\u00ebrfshihen brenda procesit t\u00eb Continuous Delivery: ndodhi k\u00ebshtu, kur di\u00e7ka d\u00ebshtoi, tani le t\u00eb programojm\u00eb k\u00ebt\u00eb skenar brenda sistemit. \u00c7do her\u00eb kodi do t\u00eb kaloj\u00eb k\u00ebt\u00eb skenar gjithashtu, dhe ju nuk do t\u00eb p\u00ebrballeni s\u00ebrish me k\u00ebt\u00eb problem. Do ta m\u00ebsoni p\u00ebr t\u00eb shum\u00eb m\u00eb her\u00ebt se sa t\u00eb dal\u00eb te klienti juaj.<\/p>\n

Strategjit\u00eb e ndryshme t\u00eb publikimit. <\/b>P\u00ebr shembull, ju p\u00ebrdorni testimin AB ose publikime kanarie, p\u00ebr t\u00eb \"exploruar\" ndryshe kodin te klient\u00eb t\u00eb ndrysh\u00ebm, duke e marr\u00eb informacionin se si funksionon kodi, dhe shum\u00eb m\u00eb p\u00ebrpara se t\u00eb publikohet p\u00ebr 100 milion p\u00ebrdorues.<\/p>\n

\"Dor\u00ebzimi i vazhduesh\u00ebm\" duket k\u00ebshtu.<\/p>\n

\"\u00c7far\u00eb
\n<\/p>\n

Procesi i dor\u00ebzimit Dev, CI, Test, PreProd, Prod \u2013 ato nuk jan\u00eb mjedise t\u00eb ndara, jan\u00eb faza ose stacione me vlera t\u00eb pap\u00ebrfshira, p\u00ebrmes t\u00eb cilave kalon artefakti juaj.<\/p><\/blockquote>\n

\nN\u00ebse keni nj\u00eb kod infrastrukture i cili p\u00ebrshkruhet si Base Service APP, at\u00ebher\u00eb ai ndihmon t\u00eb mos harrosh t\u00eb gjitha skenar\u00ebt<\/b>, dhe t\u2019i regjistrosh ata gjithashtu n\u00eb form\u00ebn e kodit p\u00ebr k\u00ebt\u00eb artefakt, t\u00eb promovosh artefaktin<\/b> dhe ta ndryshosh at\u00eb gjat\u00eb rrug\u00ebs.<\/p>\n

Pyetje p\u00ebr vet\u00ebkontroll<\/h3>\n

\nA \u00ebsht\u00eb koha nga p\u00ebrshkrimi i ve\u00e7oris\u00eb deri n\u00eb publikimin n\u00eb prodhim m\u00eb e vog\u00ebl se nj\u00eb jav\u00eb n\u00eb 95% t\u00eb rasteve? A rritet cil\u00ebsia e artefaktit n\u00eb \u00e7do faz\u00eb t\u00eb pipeline-it? A ka nj\u00eb histori p\u00ebr t\u00eb kaluar? A p\u00ebrdorni strategji t\u00eb ndryshme t\u00eb publikimit?<\/p>\n

N\u00ebse t\u00eb gjitha p\u00ebrgjigjet jan\u00eb po, at\u00ebher\u00eb ju jeni me t\u00eb v\u00ebrtet\u00eb t\u00eb mrekulluesh\u00ebm! Shkruani p\u00ebrgjigjet n\u00eb komentet \u2013 do t\u00eb isha i g\u00ebzuar).<\/p>\n

Kthimi i informacionit<\/h3>\n

\nKjo \u00ebsht\u00eb praktika m\u00eb e v\u00ebshtir\u00eb nga t\u00eb gjitha. N\u00eb konferenc\u00ebn DevOpsConf, nj\u00eb koleg nga Infobip, duke folur p\u00ebr t\u00eb, u ngat\u00ebrrua pak n\u00eb fjal\u00eb, sepse \u00ebsht\u00eb v\u00ebrtet nj\u00eb praktik\u00eb shum\u00eb e komplikuar n\u00eb lidhje me at\u00eb q\u00eb duhet t\u00eb monitorosh gjith\u00e7ka!<\/p>\n

\"\u00c7far\u00eb
\n
\nP\u00ebr shembull, nj\u00eb koh\u00eb t\u00eb gjat\u00eb m\u00eb par\u00eb, kur punoja n\u00eb Qik dhe ne kuptuam se duhej t\u00eb monitoronim gjith\u00e7ka. E b\u00ebm\u00eb k\u00ebt\u00eb, dhe n\u00eb Zabbix kishim 150,000 item-e q\u00eb monitoroheshin vazhdimisht. Ishte frikshme, drejtoresha teknike po na shikonte me dyshim:<\/p>\n

\u2014 Djem, pse po e p\u00ebrdorni serverin pa kuptim?<\/i><\/p>\n

Por pastaj ndodhi nj\u00eb rast q\u00eb tregoi se kjo \u00ebsht\u00eb v\u00ebrtet nj\u00eb strategji shum\u00eb e shk\u00eblqyer.<\/p>\n

Nj\u00eb nga sh\u00ebrbimet filloi t\u00eb binte vazhdimisht. N\u00eb fillim, ai nuk binte, \u00e7udit\u00ebrisht, atje nuk ishin b\u00ebr\u00eb ndryshime t\u00eb kodit, sepse ishte nj\u00eb broker baz\u00eb, i cili n\u00eb thelb nuk kishte funksionalitet biznesi \u2014 ai thjesht transmetonte mesazhe midis sh\u00ebrbimeve. Sh\u00ebrbimi nuk kishte ndryshuar p\u00ebr 4 muaj dhe papritmas filloi t\u00eb binte me nj\u00eb gabim \"Segmentation fault\".<\/p>\n

Ishim t\u00eb tronditur, hap\u00ebm grafik\u00ebt tan\u00eb n\u00eb Zabbix dhe zbuluam se, n\u00eb fakt, kat\u00ebrmb\u00ebdhjet\u00eb dit\u00eb m\u00eb par\u00eb kishte ndryshuar ndjesh\u00ebm sjellja e k\u00ebrkesave n\u00eb API-sh\u00ebrbimin q\u00eb shfryt\u00ebzonte k\u00ebt\u00eb broker. M\u00eb pas, shikuam se pati ndryshime n\u00eb frekuenc\u00ebn e d\u00ebrgimit t\u00eb nj\u00eb tipi t\u00eb caktuar mesazhesh. Pas k\u00ebsaj, zbuluam se ishin klient\u00ebt android. Ne pyet\u00ebm:<\/p>\n

\u2014 Djem, \u00e7far\u00eb ndodhi kat\u00ebrmb\u00ebdhjet\u00eb dit\u00eb m\u00eb par\u00eb?<\/i><\/p>\n

N\u00eb p\u00ebrgjigje d\u00ebgjuam nj\u00eb histori interesante rreth faktit se ata e kishin riprojektuar UI-n\u00eb. \u00cbsht\u00eb e pamundur q\u00eb dikush t\u00eb thot\u00eb menj\u00ebher\u00eb se kan\u00eb ndryshuar bibliotek\u00ebn HTTP. P\u00ebr klient\u00ebt android, ky \u00ebsht\u00eb nj\u00eb ndryshim si t\u00eb ndryshosh sapun n\u00eb banj\u00eb \u2014 ata thjesht nuk e mbajn\u00eb mend. N\u00eb fund, pas 40 minutash bised\u00eb, zbuluam se ata p\u00ebrfundimisht kishin ndryshuar bibliotek\u00ebn HTTP dhe ajo kishte ndryshuar parametrat e saj default. Kjo \u00e7oi n\u00eb ndryshimin e sjelljes s\u00eb trafik t\u00eb API serverit, gj\u00eb q\u00eb krijoi nj\u00eb gar\u00eb brenda brokerit dhe ai filloi t\u00eb binte.<\/p>\n

Pa nj\u00eb monitorim t\u00eb thell\u00eb, kjo do t\u00eb ishte e pamundur t\u00eb zbulohej.<\/b>. N\u00ebse organizata ka nj\u00eb tjet\u00ebr problem \"pushtimesh\", kur \u00e7do person e kalon p\u00ebrgjegj\u00ebsin\u00eb te tjetri, kjo mund t\u00eb zgjas\u00eb gjat\u00eb. Ju thjesht e restartoni serverin, sepse \u00ebsht\u00eb e pamundur t\u00eb zgjidhet problemi. Kur monitoroni, ndjekni, trackoni t\u00eb gjitha ngjarjet q\u00eb keni, dhe p\u00ebrdorni monitorimin si testim \u2014 shkruani kod dhe menj\u00ebher\u00eb specifikoni si ta monitoroni, gjithashtu n\u00eb form\u00eb kodi (ne tashm\u00eb kemi infrastruktur\u00eb si kod), gjith\u00e7ka b\u00ebhet e qart\u00eb si n\u00eb p\u00ebll\u00ebmb\u00eb. Edhe problemet kaq t\u00eb komplikuara ndjekin leht\u00ebsisht.<\/p>\n

\"\u00c7far\u00eb
\n<\/p>\n

Mblidhni t\u00eb gjitha informacionet mbi at\u00eb q\u00eb ndodh me artefaktin n\u00eb \u00e7do faz\u00eb t\u00eb procesit t\u00eb d\u00ebrgimit \u2014 jo n\u00eb prodhim.<\/p><\/blockquote>\n

\nNgarkoni monitorimin n\u00eb CI, dhe atje do t\u00eb shihen disa gj\u00ebra t\u00eb bazueshme. M\u00eb pas do t'i shihni edhe n\u00eb Test, n\u00eb PredProd, dhe n\u00eb testimin e ngarkes\u00ebs. Mblidhni informacionin n\u00eb t\u00eb gjitha fazat, p\u00ebrfshir\u00eb jo vet\u00ebm metrikat, statistik\u00ebn, por edhe logjet: si u l\u00ebshua aplikacioni, anomali \u2014 mblidhni gjith\u00e7ka. <\/p>\n

N\u00eb t\u00eb kund\u00ebrt, do t\u00eb jet\u00eb e v\u00ebshtir\u00eb t\u00eb kuptoni. Kam th\u00ebn\u00eb m\u00eb par\u00eb se DevOps \u00ebsht\u00eb nj\u00eb kompleksitet m\u00eb i madh. P\u00ebr t\u00eb p\u00ebrballuar k\u00ebt\u00eb kompleksitet, nevojitet nj\u00eb analitik\u00eb e mir\u00eb.<\/b>.<\/p>\n

Pyetje p\u00ebr vet\u00ebkontroll.<\/h3>\n

\nA \u00ebsht\u00eb monitorimi dhe logimi juaj nj\u00eb mjet zhvillimi p\u00ebr ju?<\/b> A mendojn\u00eb zhvilluesit tuaj, dhe ju gjithashtu, kur shkruajn\u00eb kod, se si ta monitorojn\u00eb at\u00eb?<\/p>\n

A e merrni vesh p\u00ebr problemet nga klient\u00ebt? A e kuptoni klientin m\u00eb mir\u00eb nga monitorimi dhe logimi?<\/b> A e kuptoni sistemin m\u00eb mir\u00eb nga monitorimi dhe logimi?<\/b> A e ndryshoni sistemin thjesht sepse keni par\u00eb se trendi n\u00eb sistem rritet dhe kuptoni se pas 3 jav\u00ebsh do t\u00eb d\u00ebshtoj\u00eb? <\/p>\n

Kur keni k\u00ebto tre komponent\u00eb, mund t\u00eb mendoni p\u00ebr platform\u00ebn infrastrukturale q\u00eb keni n\u00eb kompanin\u00eb tuaj.<\/p>\n

Platforma infrastrukturore. <\/h2>\n

\nKuptimi nuk \u00ebsht\u00eb se kjo \u00ebsht\u00eb nj\u00eb grup veglash t\u00eb ndara, q\u00eb ka \u00e7do kompani.<\/p>\n

Kuptimi i platform\u00ebs infrastrukturore \u00ebsht\u00eb q\u00eb t\u00eb gjitha ekipet t\u00eb p\u00ebrdorin k\u00ebto vegla dhe t'i zhvillojn\u00eb ato s\u00eb bashku.<\/p><\/blockquote>\n

\nE qart\u00eb, ka ekipe t\u00eb ve\u00e7anta q\u00eb mbajn\u00eb p\u00ebrgjegj\u00ebsin\u00eb p\u00ebr zhvillimin e pjes\u00ebve t\u00eb ve\u00e7anta t\u00eb platform\u00ebs infrastrukturore. Por p\u00ebrgjegj\u00ebsia p\u00ebr zhvillimin, funksionimin, dhe promovimin e platform\u00ebs infrastrukturore \u00ebsht\u00eb e \u00e7do inxhinieri. N\u00eb nivelin e brendsh\u00ebm, kjo b\u00ebhet nj\u00eb mjet i p\u00ebrgjithsh\u00ebm<\/b>. <\/p>\n

T\u00eb gjitha ekipet zhvillojn\u00eb platform\u00ebn infrastrukturore, e trajtojn\u00eb at\u00eb me kujdes si IDE-n\u00eb e tyre<\/b>. N\u00eb IDE-n\u00eb tuaj vendosni plugina t\u00eb ndryshme p\u00ebr t'i b\u00ebr\u00eb gj\u00ebrat t\u00eb duken bukur dhe t\u00eb shpejta, konfiguroni \u00e7el\u00ebsat e nxeht\u00eb. Kur hapni Sublime, Atom ose Visual Studio Code, aty shihni shum\u00eb gabime kodi dhe kuptoni se \u00ebsht\u00eb krejt e pamundur t\u00eb punoni, menj\u00ebher\u00eb b\u00ebheni t\u00eb trishtuar dhe vraponi p\u00ebr t\u00eb rregulluar IDE-n\u00eb tuaj.<\/p>\n

Trajtojeni platform\u00ebn tuaj infrastrukturore n\u00eb t\u00eb nj\u00ebjt\u00ebn m\u00ebnyr\u00eb. N\u00ebse kuptoni se di\u00e7ka nuk shkon me t\u00eb, b\u00ebni nj\u00eb k\u00ebrkes\u00eb, n\u00ebse nuk mund ta rregulloni vet\u00eb. N\u00ebse \u00ebsht\u00eb di\u00e7ka e thjesht\u00eb, rregulloni at\u00eb vet\u00eb, d\u00ebrgoni pull request \u2013 djemt\u00eb shqyrtojn\u00eb, e shtojn\u00eb. Kjo \u00ebsht\u00eb nj\u00eb qasje disi e ndryshme p\u00ebr mjetet inxhinierike n\u00eb mendjen e zhvilluesit.<\/p>\n

Platforma infrastrukturore siguron kalimin e artefaktit nga zhvillimi te klienti me nj\u00eb rritje t\u00eb vazhdueshme t\u00eb cil\u00ebsis\u00eb<\/b>. N\u00eb IP ka nj\u00eb set historish t\u00eb programuar q\u00eb ndodhin me kodin n\u00eb prodhim. Me kalimin e viteve t\u00eb zhvillimit, k\u00ebto histori b\u00ebhen shum\u00eb, disa prej tyre jan\u00eb unike dhe i p\u00ebrkasin vet\u00ebm juve \u2013 nuk mund t'i gjejm\u00eb n\u00eb Google. <\/p>\n

N\u00eb k\u00ebt\u00eb moment, platforma infrastrukturore b\u00ebhet avantazhi juaj konkurrues<\/b>, sepse aty ka at\u00eb q\u00eb nuk ka mjeti i konkurrenc\u00ebs. Sa m\u00eb thell\u00eb t\u00eb jet\u00eb IP juaj, aq m\u00eb shum\u00eb avantazh konkurrues keni n\u00eb lidhje me koh\u00ebn p\u00ebr treg. K\u00ebtu paraqitet problemi i bllokimit nga shit\u00ebsi<\/b>: mund t\u00eb merrni nj\u00eb platform\u00eb t\u00eb huaj, por duke p\u00ebrdorur p\u00ebrvoj\u00ebn e huaj, nuk do t\u00eb kuptoni se sa i p\u00ebrshtatsh\u00ebm \u00ebsht\u00eb p\u00ebr ju. Po, nuk \u00e7do kompani mund t\u00eb nd\u00ebrtoj\u00eb nj\u00eb platform\u00eb si Amazon. Kjo \u00ebsht\u00eb nj\u00eb kufi i nd\u00ebrlikuar, ku p\u00ebrvoja e kompanis\u00eb \u00ebsht\u00eb relevante p\u00ebr pozit\u00ebn e saj n\u00eb treg, dhe nuk duhet lejuar bllokimi vendor. \u00cbsht\u00eb gjithashtu e r\u00ebnd\u00ebsishme t\u00eb mendoni p\u00ebr k\u00ebt\u00eb.<\/p>\n

Skema<\/h3>\n

\nKy \u00ebsht\u00eb nj\u00eb skem\u00eb e baz\u00ebs s\u00eb platform\u00ebs infrastrukturore, q\u00eb do t'ju ndihmoj\u00eb t\u00eb organizoni t\u00eb gjitha praktikat dhe proceset n\u00eb nj\u00eb kompani DevOps.<\/p>\n

\"\u00c7far\u00eb
\n
\nLe t\u00eb shohim se \u00e7far\u00eb p\u00ebrb\u00ebhet.<\/p>\n

Sistemi i orkestrimit t\u00eb burimeve<\/b>, q\u00eb ofron CPU, memorie, disk p\u00ebr aplikacionet dhe sh\u00ebrbime t\u00eb tjera. N\u00eb sip\u00ebrfaqe t\u00eb saj \u2013 sh\u00ebrbime t\u00eb nivelit t\u00eb ul\u00ebt<\/b>: monitorimi, regjistrimi, CI\/CD Engine, depoja e artefakteve, infrastruktura si kod sistemet.<\/p>\n

Sh\u00ebrbime t\u00eb nivelit m\u00eb t\u00eb lart\u00eb<\/b>: baza e t\u00eb dh\u00ebnave si sh\u00ebrbim, radhitje si sh\u00ebrbim, Load Balance si sh\u00ebrbim, rResize i imazheve si sh\u00ebrbim, Big Data fabrika si sh\u00ebrbim. M\u00eb sip\u00ebr \u00ebsht\u00eb pipeline q\u00eb shp\u00ebrndan kodin e modifikuar vazhdimisht tek klienti tuaj<\/b>.<\/p>\n

Ju merrni informacion mbi m\u00ebnyr\u00ebn se si softueri juaj funksionon tek klienti, e ndryshoni, e shkarkoni s\u00ebrish k\u00ebt\u00eb kod, merrni informacion \u2013 dhe k\u00ebshtu zhvilloni vazhdimisht si platform\u00ebn infrastrukturore ashtu edhe softuerin tuaj.<\/p>\n

N\u00eb diagramin delivery pipeline p\u00ebrb\u00ebhet nga shum\u00eb faza. Por kjo \u00ebsht\u00eb nj\u00eb skem\u00eb themelore, e cila \u00ebsht\u00eb e paraqitur p\u00ebr shembull \u2013 nuk duhet ta p\u00ebrs\u00ebrisni nj\u00ebsoj. Faza nd\u00ebrveprojn\u00eb me sh\u00ebrbimet, si sh\u00ebrbime \u2013 \u00e7do bllok i platform\u00ebs ka historin\u00eb e tij: si ndahen burimet, si aplikacioni nis, punon me burimet, monitorohet, ndryshohet.<\/p>\n

\u00cbsht\u00eb e r\u00ebnd\u00ebsishme t\u00eb kuptoni se \u00e7do pjes\u00eb e platform\u00ebs ka nj\u00eb histori dhe duhet t\u00eb pyesni veten \u2013 \u00e7far\u00eb historie ka ky bllok, ndoshta ia vlen ta heqim dhe ta z\u00ebvend\u00ebsojm\u00eb me nj\u00eb sh\u00ebrbim t\u00eb jasht\u00ebm. P\u00ebr shembull, a mund t\u00eb vendosim Okmeter n\u00eb vend t\u00eb k\u00ebtij blloku? Ndoshta ata kan\u00eb zhvilluar k\u00ebt\u00eb ekspertiz\u00eb m\u00eb shum\u00eb se ne. Por ndoshta jo \u2013 ndoshta ne kemi ekspertiz\u00eb unike, dhe duhet t\u00eb vendosim Prometheus dhe ta zhvillojm\u00eb at\u00eb m\u00eb tej.<\/p>\n

Krijimi i platform\u00ebs<\/h3>\n

\nKy \u00ebsht\u00eb nj\u00eb proces kompleks komunikimi. Kur keni praktikat baz\u00eb, filloni komunikimin midis inxhinier\u00ebve dhe specialist\u00ebve t\u00eb ndrysh\u00ebm, t\u00eb cil\u00ebt zhvillojn\u00eb k\u00ebrkesat dhe standardet dhe vazhdimisht i modifikojn\u00eb ato p\u00ebr mjete dhe qasje t\u00eb ndryshme. K\u00ebtu kultura, q\u00eb ekziston n\u00eb DevOps, \u00ebsht\u00eb e r\u00ebnd\u00ebsishme.<\/p>\n

\"\u00c7far\u00eb
\nMe kultur\u00ebn gjith\u00e7ka \u00ebsht\u00eb shum\u00eb e thjesht\u00eb \u2013 \u00ebsht\u00eb bashk\u00ebpunimi dhe komunikimi<\/b>, dmth d\u00ebshira p\u00ebr t\u00eb punuar n\u00eb nj\u00eb fush\u00eb t\u00eb p\u00ebrbashk\u00ebt me nj\u00ebri-tjetrin, d\u00ebshira p\u00ebr t\u00eb zot\u00ebruar nj\u00eb mjet s\u00eb bashku. Nuk ka asgj\u00eb shkenc\u00eb raketash \u2013 gjith\u00e7ka \u00ebsht\u00eb shum\u00eb e thjesht\u00eb, banale. P\u00ebr shembull, ne t\u00eb gjith\u00eb jetojm\u00eb n\u00eb nj\u00eb pallat dhe ruajm\u00eb past\u00ebrtin\u00eb e tij \u2013 nj\u00eb nivel i till\u00eb kulture.<\/p>\n

Dhe p\u00ebr ju?<\/h3>\n

\nS\u00ebrish pyetje q\u00eb mund t'i b\u00ebni vetes.<\/p>\n

A \u00ebsht\u00eb ndar\u00eb platforma infrastrukturore? Kush \u00ebsht\u00eb p\u00ebrgjegj\u00ebs p\u00ebr zhvillimin e saj? A e kuptoni avantazhet konkurruese t\u00eb platform\u00ebs suaj infrastrukturore?<\/p>\n

K\u00ebto pyetje duhet t'i b\u00ebni vazhdimisht vetes. N\u00ebse ka di\u00e7ka q\u00eb mund t\u00eb transferohet n\u00eb sh\u00ebrbime t\u00eb jashtme, duhet ta transferoni; n\u00ebse nj\u00eb sh\u00ebrbim i jasht\u00ebm fillon t\u00eb bllokoj\u00eb aktivitetin tuaj, at\u00ebher\u00eb duhet t\u00eb nd\u00ebrtoni nj\u00eb sistem brenda vetes.<\/p>\n

Pra, DevOps...<\/h2>\n

\n... \u00ebsht\u00eb nj\u00eb sistem kompleks, q\u00eb duhet t\u00eb ket\u00eb:<\/p>\n