{"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 komplikuar, prandaj \u00e7do her\u00eb duhet t\u00eb nisim nj\u00eb diskutim t\u00eb ri rreth k\u00ebsaj teme. Vet\u00ebm n\u00eb Habr ka mij\u00ebra publikime mbi k\u00ebt\u00eb tem\u00eb. Por n\u00ebse jeni duke e lexuar k\u00ebt\u00eb, me siguri e dini se \u00e7far\u00eb \u00ebsht\u00eb DevOps. Sepse un\u00eb - nuk e di. P\u00ebrsh\u00ebndetje, un\u00eb quhem Aleksand\u00ebr Titov (@osminog<\/a><\/noindex><\/b>), dhe ne do t\u00eb flasim thjesht p\u00ebr DevOps dhe do t\u00eb ndaj p\u00ebrvoj\u00ebn time.<\/p>\n

\"\u00c7far\u00eb
\n
\nKam menduar p\u00ebr nj\u00eb koh\u00eb t\u00eb gjat\u00eb se si ta b\u00ebj tregimin tim t\u00eb dobish\u00ebm, prandaj k\u00ebtu do t\u00eb ket\u00eb shum\u00eb pyetje - ato q\u00eb vet\u00eb i b\u00ebj dhe ato q\u00eb iu 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\u00ebr pse \u00ebsht\u00eb e nevojshme DevOps nga k\u00ebndv\u00ebshtrimi im, \u00e7far\u00eb \u00ebsht\u00eb kjo, p\u00ebrs\u00ebri, nga pozita ime, dhe si ta 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 vet\u00eb, do t\u00eb jeni n\u00eb gjendje t\u00eb kuptoni n\u00ebse kompanit\u00eb tuaja po shkojn\u00eb drejt DevOps apo ka ndonj\u00eb problem.
\n<\/a><\/noindex>
\n

\r\n \"Luaj\r\n
<\/div>\r\n <\/div><\/center>
\nNj\u00eb her\u00eb, un\u00eb sh\u00ebtita n\u00eb val\u00ebt e bashkimeve dhe blerjeve. Fillimisht punova n\u00eb nj\u00eb startup t\u00eb vog\u00ebl, Qik, pastaj e bleu nj\u00eb kompani pak m\u00eb e madhe, Skype, e cila m\u00eb von\u00eb u bleu nga nj\u00eb kompani akoma m\u00eb e madhe, Microsoft. N\u00eb at\u00eb moment, pata nj\u00eb vizion se si transformohet perceptimi p\u00ebr DevOps n\u00eb kompani t\u00eb ndryshme n\u00eb madh\u00ebsi. Pas k\u00ebsaj, m\u00eb interesoi t\u00eb shikoj DevOps nga k\u00ebndv\u00ebshtrimi i tregut, dhe s\u00eb bashku me koleg\u00ebt, organizuam kompanin\u00eb Ekspress 42. Tani jemi 6 vjet n\u00eb k\u00ebt\u00eb rrug\u00eb n\u00eb val\u00ebt e tregut.<\/p>\n

P\u00ebrve\u00e7 k\u00ebsaj, un\u00eb jam nj\u00eb nga organizator\u00ebt e komunitetit DevOps Moscow dhe organizator i DevOps Days 2017, por n\u00eb 2018 nuk e organizova. Ekspress 42 punon me shum\u00eb kompani. Ne zhvillojm\u00eb DevOps aty, shohim si ndodh, nxjerrim p\u00ebrfundime, analizojm\u00eb, ndajm\u00eb p\u00ebrfundimet tona me t\u00eb gjith\u00eb, dhe i m\u00ebsojm\u00eb njer\u00ebzit n\u00eb praktikat DevOps. N\u00eb p\u00ebrgjith\u00ebsi, 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 dhe gjithmon\u00eb \u00ebsht\u00eb \u2013 pse? Shum\u00eb mendojn\u00eb se DevOps \u00ebsht\u00eb thjesht automatizim ose ndonj\u00eb gj\u00eb e ngjashme q\u00eb tashm\u00eb ka qen\u00eb n\u00eb \u00e7do kompani.<\/p>\n

\u2014 Ne kemi pasur Continuous Integration \u2014 do t\u00eb thot\u00eb q\u00eb tashm\u00eb ka qen\u00eb DevOps, dhe p\u00ebrse \u00ebsht\u00eb e nevojshme gjith\u00eb kjo? Aty jasht\u00eb arg\u00ebtohen, nd\u00ebrsa ne na pengojn\u00eb t\u00eb punojm\u00eb!<\/i><\/p>\n

Pas 9 vjet\u00ebsh t\u00eb zhvillimit t\u00eb komunitetit dhe metodologjis\u00eb, tashm\u00eb \u00ebsht\u00eb e qart\u00eb se k\u00ebto nuk jan\u00eb thjesht shk\u00eblqime marketingu, por akoma nuk e kuptojm\u00eb plot\u00ebsisht p\u00ebrse \u00ebsht\u00eb i nevojsh\u00ebm. Sikurse \u00e7do mjet dhe proces, DevOps ka objektiva t\u00eb caktuara q\u00eb ai n\u00eb fund zgjidh.<\/p>\n

E gjith\u00eb kjo lidhet me faktin se bota po ndryshon. Po largohet nga qasja enterprise, kur kompanit\u00eb l\u00ebvizin direkt drejt \u00ebndrr\u00ebs, si\u00e7 k\u00ebndonte klasiku yn\u00eb nga Sh\u00ebn Peterburgu, 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 principe, n\u00eb IT gjith\u00e7ka duhet t\u00eb nd\u00ebrt exposedt mbi k\u00ebt\u00eb qasje. K\u00ebtu IT p\u00ebrdoret ekskluzivisht p\u00ebr automatizimin e proceseve.<\/p><\/blockquote>\n

\nAutomatizimi nuk ndryshon shpesh, sepse kur nj\u00eb kompani \u00ebsht\u00eb duke ecur n\u00eb shtegun e p\u00ebrshkruar \u2014 \u00e7far\u00eb do t\u00eb ndryshosh? Funksionon \u2014 mos e prek. Tani n\u00eb bot\u00eb qasjet po ndryshojn\u00eb, dhe ajo q\u00eb quhet Agile tregon se pika p\u00ebrfundimtare B nuk \u00ebsht\u00eb e dukshme menj\u00ebher\u00eb.<\/p>\n

\"\u00c7far\u00eb
\n
\nKur kompanit shkon n\u00eb treg, punon me klientin \u2014 ajo vazhdimisht hulumton tregun dhe ndryshon pik\u00ebn p\u00ebrfundimtare B. Sa m\u00eb shpesh t\u00eb ndryshoj\u00eb drejtimin e saj, aq m\u00eb e suksesshme b\u00ebhet, sepse zgjat m\u00eb shum\u00eb ni\u0161a tregu.<\/p>\n

Strategjin\u00eb e tregon nj\u00eb kompani interesante, p\u00ebr t\u00eb cil\u00ebn m\u00ebsova s\u00eb fundmi. One Box Shave \u2014 nj\u00eb sh\u00ebrbim q\u00eb ofron d\u00ebrges\u00eb t\u00eb razor\u00ebve dhe pajisjeve p\u00ebr rruajtje n\u00eb \u00e7\u00ebshtje abonimi brenda nj\u00eb kuti. Ata din\u00eb t\u00eb personalizojn\u00eb \"kutin\u00eb\" e tyre p\u00ebr klient\u00eb t\u00eb ndrysh\u00ebm. K\u00ebt\u00eb e b\u00ebn nj\u00eb software i caktuar q\u00eb pastaj d\u00ebrgon porosin\u00eb n\u00eb fabrik\u00ebn 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 lam\u00eb? A seriozisht? Pse ju nevoitet kjo \u2014 kjo asnj\u00ebher\u00eb nuk p\u00ebrmir\u00ebson cil\u00ebsin\u00eb e rruajtjes. Nj\u00eb krem i p\u00ebrzgjedhur, nj\u00eb arom\u00eb dhe nj\u00eb razor cil\u00ebsor me dy lama zgjidhin shum\u00eb m\u00eb tep\u00ebr \u00e7\u00ebshtje sesa k\u00ebto kat\u00ebr lama t\u00eb d\u00ebmshme Gillette! K\u00ebshtu do t\u00eb arrijm\u00eb 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 Koha p\u00ebr treg<\/b>, p\u00ebr t\u00eb cilin kan\u00eb folur tashm\u00eb shum\u00eb njer\u00ebz.<\/p>\n

\"\u00c7far\u00eb
\n
\nKuptimi i koh\u00ebs p\u00ebr treg nuk \u00ebsht\u00eb se sa shpesh ne b\u00ebjm\u00eb depolimin. Mund t\u00eb b\u00ebhet depolim shpesh, por ciklet e l\u00ebshimit do t\u00eb jen\u00eb t\u00eb gjata. N\u00ebse ciklet e l\u00ebshimit prej tre muajsh vendosen nj\u00ebr\u00ebn mbi tjetr\u00ebn, duke i shtyr\u00eb p\u00ebr nj\u00eb jav\u00eb, duket se kompania po depolon \u00e7do jav\u00eb. Por ideja deri te realizimi p\u00ebrfundimtar zgjat 3 muaj.<\/p>\n

Koha p\u00ebr treg \u00ebsht\u00eb p\u00ebr minimizimin e koh\u00ebs nga ideja deri te realizimi p\u00ebrfundimtar.<\/p><\/blockquote>\n

\nN\u00eb k\u00ebt\u00eb rast, softueri nd\u00ebrvepron me tregun. K\u00ebshtu, One Box Shave ka nd\u00ebrveprime me klientin p\u00ebrmes faqes s\u00eb tyre. Ata nuk kan\u00eb shit\u00ebs - thjesht nj\u00eb faqe, ku vizitori klikoni dhe l\u00eb preferencat e tij. Prandaj, faqja duhet t\u00eb publikoj\u00eb vazhdimisht di\u00e7ka t\u00eb re, p\u00ebr t'u p\u00ebrdit\u00ebsuar n\u00eb p\u00ebrputhje me d\u00ebshirat. P\u00ebr shembull, n\u00eb Kore, nuk depilojn\u00eb si n\u00eb Rusi, dhe ata preferojn\u00eb arom\u00ebn e vaniljes me karot\u00eb nga ajo e pish\u00ebs.<\/p>\n

Me sa duhet t\u00eb nd\u00ebrrojm\u00eb shpejt p\u00ebrmbajtjen e faqeve, zhvillimi i softuerit ka ndryshuar ndjesh\u00ebm. Me an\u00eb t\u00eb softuerit, ne duhet t\u00eb kuptojm\u00eb se \u00e7far\u00eb d\u00ebshiron klienti. M\u00eb par\u00eb, ne e m\u00ebsuam k\u00ebt\u00eb p\u00ebrmes disa rrug\u00ebve alternative, p\u00ebr shembull, p\u00ebrmes menaxhimit t\u00eb biznesit. Pastaj e projektuan, p\u00ebrcaktuan k\u00ebrkesat n\u00eb sistemin IT, dhe gjith\u00e7ka ishte n\u00eb rregull. Tani \u00ebsht\u00eb ndryshe \u2013 softueri projektit zhvillohet nga t\u00eb gjith\u00eb q\u00eb jan\u00eb t\u00eb p\u00ebrfshir\u00eb n\u00eb proces, p\u00ebrfshir\u00eb inxhinier\u00ebt, sepse ata m\u00ebsojn\u00eb p\u00ebrmes specifikimeve 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, ne papritmas m\u00ebsuam se njer\u00ebzit e duan shum\u00eb t\u00eb ngarkojn\u00eb lista kontakti n\u00eb server, dhe ata na soll\u00ebn nj\u00eb aplikacion. Fillimisht ne nuk e kishim menduar k\u00ebt\u00eb. N\u00eb nj\u00eb kompani tradicionale, t\u00eb gjith\u00eb do t\u00eb kishin menduar se ishte nj\u00eb problem, pasi n\u00eb specifikim nuk ishte shkruar q\u00eb kjo duhej t\u00eb funksiononte mir\u00eb dhe ishte realizuar m\u00eb shum\u00eb n\u00eb m\u00ebnyr\u00eb t\u00eb improvizuar, do ta kishin ndaluar at\u00eb ve\u00e7ori dhe do thoshin: \"Kjo nuk \u00ebsht\u00eb e nevojshme p\u00ebr ask\u00ebnd, e r\u00ebnd\u00ebsishme \u00ebsht\u00eb q\u00eb funksionaliteti kryesor funksionon\". Nj\u00eb kompani teknologjike n\u00eb k\u00ebt\u00eb e sheh si mund\u00ebsi dhe fillon t\u00eb ndryshoj\u00eb softuerin n\u00eb p\u00ebrputhje me k\u00ebt\u00eb.<\/p>\n

\"\u00c7far\u00eb
\n
\nN\u00eb vitin 1968, djali i men\u00e7ur Melvin Conway formuloi k\u00ebt\u00eb ide.<\/p>\n

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

\nM\u00eb n\u00eb detaje, p\u00ebr t\u00eb prodhuar sisteme t\u00eb nj\u00eb lloji tjet\u00ebr, duhet gjithashtu t\u00eb kemi nj\u00eb struktur\u00eb komunikimi brenda kompanis\u00eb q\u00eb \u00ebsht\u00eb e ndryshme. N\u00ebse keni nj\u00eb struktur\u00eb komunikimi t\u00eb nivelit t\u00eb lart\u00eb hierarkik, kjo nuk do t'ju lejoj\u00eb t\u00eb krijoni sisteme q\u00eb mund t\u00eb sigurojn\u00eb nj\u00eb p\u00ebrqindje shum\u00eb t\u00eb lart\u00eb t\u00eb shpejt\u00ebsis\u00eb s\u00eb sjelljes n\u00eb treg.<\/p>\n

Lexoni rreth ligjit t\u00eb Conway<\/a><\/noindex> mund t\u00eb n\u00eb lidhje<\/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 themelore n\u00eb DevOps \u00ebsht\u00eb sakt\u00ebsisht struktura e komunikimit midis ekipeve.<\/b>.<\/p>\n

Nga perspektiva e procesit, para DevOps, t\u00eb gjitha fazat: analiza, zhvillimi, testimi, operimi, kalonin n\u00eb m\u00ebnyr\u00eb lineare.\"\u00c7far\u00eb
\nN\u00eb rastin e DevOps, t\u00eb gjith\u00eb k\u00ebto procese shkojn\u00eb nj\u00ebkoh\u00ebsisht.<\/p>\n

\"\u00c7far\u00eb
\n
\nShpejt\u00ebsia e sjelljes n\u00eb treg mund t\u00eb realizohet vet\u00ebm k\u00ebshtu. P\u00ebr njer\u00ebzit q\u00eb kan\u00eb punuar n\u00eb procesin e vjet\u00ebr, kjo duket disi kozmike dhe n\u00eb p\u00ebrgjith\u00ebsi jo shum\u00eb e mir\u00eb.<\/p>\n

Pse \u00ebsht\u00eb e nevojshme DevOps?<\/h3>\n

\nP\u00ebr zhvillimin e produkteve digjitale<\/b>. N\u00ebse kompania juaj nuk ka nj\u00eb produkt digjital, DevOps nuk \u00ebsht\u00eb e nevojshme - kjo \u00ebsht\u00eb shum\u00eb e r\u00ebnd\u00ebsishme.<\/p>\n

DevOps kalon kufijt\u00eb e shpejt\u00ebsis\u00eb s\u00eb nj\u00eb skeme tradicionale t\u00eb prodhimit t\u00eb softuerit<\/b>. N\u00eb t\u00eb gjitha proceset ndodhin n\u00eb nj\u00eb koh\u00eb.<\/p>\n

P\u00ebrfundon duke u b\u00ebr\u00eb m\u00eb e komplikuar.<\/b> Kur evangjelist\u00ebt e DevOps-it thon\u00eb se me t\u00eb do t'ju b\u00ebhet m\u00eb e leht\u00eb t\u00eb l\u00ebshoni softuer - kjo \u00ebsht\u00eb nonsense.<\/p>\n

Me DevOps gjith\u00e7ka do t\u00eb jet\u00eb m\u00eb e nd\u00ebrlikuar.<\/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 vendos\u00ebsh nj\u00eb kontejner Docker - nj\u00eb detyr\u00eb e pamundur. Kompleksiteti b\u00ebhet ekstreme, duhet t\u00eb jongloni me shum\u00eb topa n\u00eb t\u00eb nj\u00ebjt\u00ebn koh\u00eb.<\/p>\n

DevOps ndryshon plot\u00ebsisht procesin dhe organizat\u00ebn n\u00eb kompani<\/b>\u00a0\u2014 sakt\u00ebsisht, ndryshon jo DevOps, por produktin digjital. P\u00ebr t\u00eb arritur n\u00eb DevOps, duhet ta ndryshoni plot\u00ebsisht k\u00ebt\u00eb proces.<\/p>\n

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

\n\u00c7far\u00eb ndodh me ju? Pyetje q\u00eb mund t'i b\u00ebni vetes, kur punoni n\u00eb kompani dhe p\u00ebrfitoni si specialist.<\/p>\n

A keni nj\u00eb strategji p\u00ebr krijimin e produktit digjital?<\/b> N\u00ebse po - kjo \u00ebsht\u00eb mir\u00eb. Kjo do t\u00eb thot\u00eb se kompania juaj 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, duke u angazhuar n\u00eb aktivitete m\u00eb interesante - nga k\u00ebndv\u00ebshtrimi i DevOps, p\u00ebrs\u00ebri. Po e them vet\u00ebm nga ky k\u00ebndv\u00ebshtrim.<\/p>\n

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

B\u00ebni k\u00ebto pyetje p\u00ebr veten 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. N\u00ebse tema e DevOps \u00ebsht\u00eb v\u00ebrtet interesante p\u00ebr ju, ndoshta... duhet t\u00eb kaloni n\u00eb nj\u00eb kompani tjet\u00ebr? N\u00ebse kompania juaj d\u00ebshiron t\u00eb shkoj\u00eb n\u00eb DevOps, por ju p\u00ebrgjigj\u00ebt me \"Jo\" p\u00ebr t\u00eb gjitha pyetjet, at\u00ebher\u00eb ajo i ngjan atij rinocerosi t\u00eb mrekulluesh\u00ebm q\u00eb kurr\u00eb nuk do t\u00eb ndryshoj\u00eb.<\/p>\n

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

Organizata<\/h2>\n

\nSi\u00e7 kam th\u00ebn\u00eb tashm\u00eb, sipas ligjit t\u00eb Conway-t, organizata e kompanis\u00eb ndryshon. Do t\u00eb filloj me pengesat q\u00eb i ndalojn\u00eb DevOps-it t\u00eb dep\u00ebrtoj\u00eb brenda kompanis\u00eb, pik\u00ebrisht nga k\u00ebndv\u00ebshtrimi i organizat\u00ebs.<\/p>\n

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

\nFjala angleze \"Silo\" \u00ebsht\u00eb p\u00ebrkthyer k\u00ebtu n\u00eb rusisht si \"kolodec\". Kuptimi i k\u00ebtij problemi \u00ebsht\u00eb se nuk ka shk\u00ebmbim informacioni midis ekipeve.<\/b>. \u00c7do ekip thellon ekspertiz\u00ebn e tij, duke mos nd\u00ebrtuar nj\u00eb map\u00eb t\u00eb p\u00ebrgjithshme p\u00ebr orientim.<\/p>\n

Kjo t\u00eb ngjan disi me nj\u00eb njeri q\u00eb sapo ka mb arrive n\u00eb Mosk\u00eb dhe ende nuk di t\u00eb orientoj\u00eb n\u00eb hart\u00ebn e metros\u00eb. Moskvi i njohin zakonisht mir\u00eb lagjen 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 zhg\u00ebnjyer.<\/p>\n

DevOps ofron mund\u00ebsin\u00eb p\u00ebr t\u00eb kaluar k\u00ebt\u00eb moment t\u00eb zhg\u00ebnjimit dhe q\u00eb t\u00eb gjitha nj\u00ebsite t\u00eb nd\u00ebrtojn\u00eb s\u00eb bashku nj\u00eb hart\u00eb t\u00eb p\u00ebrbashk\u00ebt t\u00eb bashk\u00ebpunimit.<\/p><\/blockquote>\n

\nKjo pengohet nga dy faktor\u00eb.<\/p>\n

Pasojat e sistemit korporativ t\u00eb menaxhimit.<\/b> Ai \u00ebsht\u00eb nd\u00ebrtuar n\u00eb \u00abpushta\u00bb t\u00eb ve\u00e7anta hierarkike. 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 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 gjith\u00eb sistemin. Thjesht nuk \u00ebsht\u00eb komod. Imagjinoni se si do t\u00eb ndiheshit n\u00eb aeroportin e Bangokut \u2013 nuk \u00ebsht\u00eb e leht\u00eb t\u00eb orientohesh shpejt. Edhe n\u00eb DevOps \u00ebsht\u00eb e v\u00ebshtir\u00eb t\u00eb orientohesh, prandaj njer\u00ebzit thon\u00eb se duhet t\u00eb gjejm\u00eb nj\u00eb udh\u00ebheq\u00ebs p\u00ebr t\u00eb arritur atje.<\/p>\n

Porosia m\u00eb e r\u00ebnd\u00ebsishme \u00ebsht\u00eb se problemin e \"pusave\" p\u00ebr inxhinierin q\u00eb ka marr\u00eb frym\u00eb nga fryma DevOps, ka lexuar Fowler dhe shum\u00eb libra t\u00eb tjer\u00eb, shprehet n\u00eb at\u00eb q\u00eb \"pusat\" nuk lejojn\u00eb t\u00eb b\u00ebhen gj\u00ebra \"t\u00eb dukshme\"<\/b>. Ne shpesh mblidhemi pas DevOps Moscow, bisedojm\u00eb me nj\u00ebri-tjetrin dhe njer\u00ebzit ankohen:<\/p>\n

\u2014 Ne thjesht donim t\u00eb nisnim CI, por rezultoi se menaxhmenti nuk e kishte p\u00ebr synim.<\/i><\/p>\n

Kjo ndodh pik\u00ebrisht p\u00ebr shkak se\u00a0CI <\/b>dhe\u00a0procesi i Continuous Delivery<\/b> \u00ebsht\u00eb n\u00eb kufirin e shum\u00eb ekspertizave. Thjesht, duke mos e tejkaluar problemin e \"pusave\" n\u00eb nivelin organizativ, nuk do t\u00eb arrijm\u00eb t\u00eb avancojm\u00eb m\u00eb tej, pavar\u00ebsisht se \u00e7far\u00eb b\u00ebni dhe sa e trisht\u00eb q\u00eb \u00ebsht\u00eb.<\/p>\n

\"\u00c7far\u00eb
\n
\n\u00c7do pjes\u00ebmarr\u00ebs n\u00eb proces n\u00eb kompani: zhvilluesit e backend-it dhe frontend-it, testimi, DBA, operimi, rrjeti, po \u00e7ajn\u00eb n\u00eb an\u00ebn e tyre, dhe askush nuk ka nj\u00eb hart\u00eb t\u00eb p\u00ebrbashk\u00ebt, p\u00ebrve\u00e7 menaxherit, i cili i sheh dhe i menaxhon me metod\u00ebn \"ndaje dhe sundo\".<\/p>\n

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

\nSi n\u00eb fund, kur shfaqet detyra p\u00ebr t\u00eb lidhur gjith\u00e7ka s\u00eb bashku dhe p\u00ebr t\u00eb nd\u00ebrtuar nj\u00eb pipeline t\u00eb p\u00ebrbashk\u00ebt, dhe p\u00ebr yjet dhe flamujt nuk ka m\u00eb nevoj\u00eb t\u00eb luftohet, shfaqet pyetja - \u00e7far\u00eb duhet t\u00eb b\u00ebjm\u00eb n\u00eb fakt? Duhet t\u00eb arrijm\u00eb nj\u00eb marr\u00ebveshje, por si ta b\u00ebjm\u00eb k\u00ebt\u00eb, askush nuk na m\u00ebsoi n\u00eb shkoll\u00eb. Jemi m\u00ebsuar q\u00eb q\u00eb n\u00eb shkoll\u00eb: klasa e tet\u00eb - oho! - n\u00eb krahasim me klas\u00ebn e shtat\u00eb! K\u00ebtu \u00ebsht\u00eb nj\u00ebsoj.<\/p>\n

A \u00ebsht\u00eb k\u00ebshtu edhe n\u00eb kompanin\u00eb tuaj?<\/h3>\n

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

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

\u041d\u0430\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u0447\u0430\u0441\u0442\u043e \u043a\u043e\u043c\u0430\u043d\u0434\u044b \u043f\u0435\u0440\u0435\u0444\u043e\u0440\u043c\u0438\u0440\u0443\u044e\u0442\u0441\u044f\u00a0\u2014 \u043e\u0434\u043d\u0438 \u0441\u043f\u0435\u0446\u0438\u0430\u043b\u0438\u0441\u0442\u044b \u0438\u0437\u00a0\u043e\u0434\u043d\u043e\u0439 \u043a\u043e\u043c\u0430\u043d\u0434\u044b \u043f\u0435\u0440\u0435\u0445\u043e\u0434\u044f\u0442 \u0432\u00a0\u0434\u0440\u0443\u0433\u0443\u044e \u043a\u043e\u043c\u0430\u043d\u0434\u0443?<\/b> \u0418\u043c\u0435\u043d\u043d\u043e \u0432\u00a0DevOps-\u0441\u0440\u0435\u0434\u0435 \u044d\u0442\u043e \u0441\u0442\u0430\u043d\u043e\u0432\u0438\u0442\u0441\u044f \u043d\u043e\u0440\u043c\u0430\u043b\u044c\u043d\u044b\u043c, \u043f\u043e\u0442\u043e\u043c\u0443 \u0447\u0442\u043e \u0438\u043d\u043e\u0433\u0434\u0430 \u0447\u0435\u043b\u043e\u0432\u0435\u043a \u043f\u0440\u043e\u0441\u0442\u043e \u043d\u0435\u00a0\u043c\u043e\u0436\u0435\u0442 \u043f\u043e\u043d\u044f\u0442\u044c, \u0447\u0435\u043c \u0437\u0430\u043d\u0438\u043c\u0430\u0435\u0442\u0441\u044f \u0434\u0440\u0443\u0433\u0430\u044f \u0437\u043e\u043d\u0430 \u044d\u043a\u0441\u043f\u0435\u0440\u0442\u0438\u0437\u044b. \u041e\u043d\u00a0\u043f\u0435\u0440\u0435\u0445\u043e\u0434\u0438\u0442 \u0432\u00a0\u0434\u0440\u0443\u0433\u043e\u0439 \u043e\u0442\u0434\u0435\u043b, \u0434\u0432\u0435 \u043d\u0435\u0434\u0435\u043b\u044c\u043a\u0438 \u0442\u0430\u043c \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442, \u0447\u0442\u043e\u0431\u044b \u0441\u043e\u0437\u0434\u0430\u0442\u044c \u0434\u043b\u044f \u0441\u0435\u0431\u044f \u043a\u0430\u0440\u0442\u0443 \u043e\u0440\u0438\u0435\u043d\u0442\u0430\u0446\u0438\u0438 \u0438\u00a0\u0432\u0437\u0430\u0438\u043c\u043e\u0434\u0435\u0439\u0441\u0442\u0432\u0438\u044f \u0441\u00a0\u044d\u0442\u0438\u043c \u043e\u0442\u0434\u0435\u043b\u043e\u043c.<\/p>\n

A mund t\u00eb krijohet nj\u00eb komitet p\u00ebr ndryshime dhe t\u00eb b\u00ebhen disa ndryshime? <\/b>A \u00ebsht\u00eb e nevojshme q\u00eb nj\u00eb dor\u00eb e fort\u00eb nga drejtuesit m\u00eb t\u00eb lart\u00eb t\u00eb jet\u00eb e angazhuar p\u00ebr k\u00ebt\u00eb dhe nj\u00eb urdh\u00ebr? Koh\u00ebt e fundit kam shkruar n\u00eb Facebook se si nj\u00eb bank\u00eb e panjohur, p\u00ebrmes urdh\u00ebrave, po implementon metoda: kan\u00eb shkruar nj\u00eb urdh\u00ebr, e zbatojn\u00eb p\u00ebr nj\u00eb vit, dhe shohin se \u00e7far\u00eb ndodh. Sigurisht, kjo \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 parasysh arritjet e kompanis\u00eb? <\/b><\/p>\n

N\u00ebse i jepni p\u00ebrgjigje k\u00ebtyre pyetjeve p\u00ebr vete, do t\u00eb kuptoni n\u00ebse keni nj\u00eb problem t\u00eb till\u00eb n\u00eb kompani.<\/p>\n

Infrastruktura si kod<\/h2>\n

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

Shpesh infrastruktura si kod kuptohet k\u00ebshtu:<\/p>\n

\u2014 Le t\u00eb automatizojm\u00eb gjith\u00e7ka me bash, t\u00eb mbulohemi me skripta, q\u00eb administratoret t\u00eb ken\u00eb m\u00eb pak pun\u00eb manuale!<\/i><\/p>\n

Por, ajo nuk \u00ebsht\u00eb k\u00ebshtu.<\/p>\n

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

\nS\u00eb bashku me ekipet e tjera, krijoni nj\u00eb hart\u00eb t\u00eb formatuar si kod, q\u00eb \u00ebsht\u00eb e kuptueshme p\u00ebr t\u00eb gjith\u00eb dhe mbi t\u00eb cil\u00ebn mund t\u00eb orientoheni dhe navigoni. Nuk ka r\u00ebnd\u00ebsi se \u00e7far\u00eb p\u00ebrdoret p\u00ebr k\u00ebt\u00eb \u2014 Chef, Ansible, Salt, ose p\u00ebrdorimi i skedar\u00ebve YAML n\u00eb Kubernetes \u2014 nuk b\u00ebn diferenc\u00eb.<\/p>\n

N\u00eb konferenc\u00eb, nj\u00eb koleg nga 2GIS tregoi se si ata krijuan nj\u00eb mjet t\u00eb brendsh\u00ebm p\u00ebr Kubernetes, i cili p\u00ebrshkruan funksionimin e sistemeve t\u00eb ve\u00e7anta. P\u00ebr t\u00eb p\u00ebrshkruar 500 sisteme, ata pat\u00ebn nevoj\u00eb p\u00ebr nj\u00eb mjet t\u00eb ve\u00e7ant\u00eb q\u00eb gjeneron k\u00ebt\u00eb p\u00ebrshkrim. Kur ka k\u00ebt\u00eb p\u00ebrshkrim, secili mund t\u00eb krahasohet me t\u00eb tjer\u00ebt, t\u00eb monitoroj\u00eb ndryshimet, si mund ta ndryshoj\u00eb dhe p\u00ebrmir\u00ebsoj\u00eb, \u00e7far\u00eb mungon. <\/p>\n

M\u00eb tregoni, scriptet e ve\u00e7anta bashk\u00eb zakonisht nuk ofrojn\u00eb k\u00ebt\u00eb kuptim. N\u00eb nj\u00eb nga kompanit\u00eb ku kam punuar, kishte madje nj\u00eb em\u00ebr \"shkrim vet\u00ebm\" - kur skripti \u00ebsht\u00eb shkruar, por nuk mund t\u00eb lexohet m\u00eb. Mendoj se kjo \u00ebsht\u00eb e njohur edhe p\u00ebr ju.<\/p>\n

Infrastruktura si kod \u00ebsht\u00eb kod q\u00eb p\u00ebrshkruan gjendjen aktuale t\u00eb infrastruktur\u00ebs<\/b>. P\u00ebr k\u00ebt\u00eb kod punojn\u00eb s\u00eb bashku shum\u00eb ekipe produkti, infrastrukture dhe sh\u00ebrbimesh, dhe, m\u00eb e r\u00ebnd\u00ebsishmja, t\u00eb gjitha ato duhet t\u00eb kuptojn\u00eb si funksionon ky kod.<\/p>\n

Kodi shoq\u00ebrohet sipas praktikave m\u00eb t\u00eb mira t\u00eb zhvillimit t\u00eb kodit<\/b>: zhvillim i p\u00ebrbashk\u00ebt, rishikim i kodit, programimi XP, testimi, k\u00ebrkesat p\u00ebr bashk\u00ebngjitje, CI p\u00ebr infrastrukturat e kodit \u2014 t\u00eb gjitha k\u00ebto jan\u00eb t\u00eb mira dhe mund t\u00eb p\u00ebrdoren.<\/p>\n

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

\nNdryshimi i infrastruktur\u00ebs n\u00eb kod nuk z\u00eb shum\u00eb koh\u00eb<\/b>. Po, n\u00eb infrastruktur\u00ebn e kodit mund t\u00eb ket\u00eb borxhe teknike. Zakonisht, ekipet p\u00ebrballen me to rreth nj\u00eb vit e gjysm\u00eb pas fillimit t\u00eb zbatimit t\u00eb \u00abinfrastruktur\u00ebs si kod\u00bb n\u00eb form\u00ebn e nj\u00eb grumbulli skriptesh ose madje Ansible, t\u00eb cilat i shkruajn\u00eb si kod spageti, dhe k\u00ebshtu i hedhin edhe skripte bash n\u00eb zjarre! <\/p>\n

E r\u00ebnd\u00ebsishme<\/b>: n\u00ebse nuk e keni provuar k\u00ebt\u00eb gj\u00eb, mbani mend se Ansible nuk \u00ebsht\u00eb bash<\/b>! Lexoni me kujdes dokumentacionin, studiohuni p\u00ebr at\u00eb q\u00eb flitet p\u00ebr t\u00eb.<\/p>\n

Infrastruktura si kod \u00ebsht\u00eb ndarjen e kodit t\u00eb infrastruktur\u00ebs n\u00eb shtresa t\u00eb ve\u00e7anta.<\/p><\/blockquote>\n

\nN\u00eb kompanin\u00eb ton\u00eb, ne kemi identifikuar 3 nivele bazike q\u00eb jan\u00eb shum\u00eb t\u00eb qarta dhe t\u00eb thjeshta, por mund t\u00eb ket\u00eb edhe m\u00eb shum\u00eb. Ju mund t\u00eb shqyrtoni kodin tuaj t\u00eb infrastruktur\u00ebs dhe t\u00eb thoni n\u00ebse keni k\u00ebt\u00eb kusht apo jo. N\u00ebse nuk ka nivele t\u00eb identifikuara, \u00ebsht\u00eb e nevojshme t\u00eb dedikoni koh\u00eb dhe t\u00eb rregulloni pak.
\n\"\u00c7far\u00eb
\n
\nNiveli bazik<\/b>\u00a0\u2014 \u00ebsht\u00eb si konfigurimi i OS-s\u00eb, backup-et dhe gj\u00ebra t\u00eb tjera t\u00eb nivelit t\u00eb ul\u00ebt, p\u00ebr shembull, si vendoset Kubernetes n\u00eb nivelin bazik.<\/p>\n

Niveli i sh\u00ebrbimeve<\/b>\u00a0\u2014 jan\u00eb sh\u00ebrbimet q\u00eb ju ofroni zhvilluesve: logimi si sh\u00ebrbim, monitorimi si sh\u00ebrbim, baza e t\u00eb dh\u00ebnave si sh\u00ebrbim, balancuesi si sh\u00ebrbim, radhitja si sh\u00ebrbim, Continuous Delivery si sh\u00ebrbim \u2014 nj\u00eb mori sh\u00ebrbimesh q\u00eb ekipet e ndara mund t\u00eb ofrojn\u00eb p\u00ebr zhvillimin. T\u00eb gjitha k\u00ebto duhen p\u00ebrshkruar si module t\u00eb ve\u00e7anta n\u00eb sistemin tuaj t\u00eb menaxhimit t\u00eb konfiguracionit.<\/p>\n

Niveli ku krijohen aplikacionet<\/b> dhe p\u00ebrshkruhet si do t\u00eb zhvillohen mbi dy nivelet e m\u00ebparshme.<\/p>\n

Pyetje kontrolli<\/h3>\n

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

N\u00ebse keni hasur n\u00eb situata ku p\u00ebr t\u00eb b\u00ebr\u00eb ndryshime ka marr\u00eb nj\u00eb deri n\u00eb nj\u00eb dit\u00eb e gjysm\u00eb, kjo do t\u00eb thot\u00eb se keni krijuar borxh teknik dhe duhet t\u00eb punoni me t\u00eb. Ju sapo keni hasur n\u00eb pengesat e borxhit teknik n\u00eb kodin e infrastruktur\u00ebs. Kujtoj shum\u00eb histori, kur p\u00ebr t\u00eb ndryshuar nj\u00eb CCTL, duhej t\u00eb rishkruaje gjysm\u00ebn e kodit t\u00eb infrastruktur\u00ebs, sepse krijimtaria dhe d\u00ebshira p\u00ebr t\u00eb automatizuar gjith\u00e7ka \u00e7oi n\u00eb situata ku gjith\u00e7ka \u00ebsht\u00eb ngat\u00ebrruar, jan\u00eb hequr t\u00eb gjitha butonat, dhe duhet t\u00eb rifillosh.<\/p>\n

Dor\u00ebzim i vazhduesh\u00ebm<\/h2>\n

\nKemi nj\u00eb p\u00ebrmbledhje t\u00eb debitit me kreditin. Fillimisht paraqitet nj\u00eb p\u00ebrshkrim i infrastruktur\u00ebs, i cili mund t\u00eb jet\u00eb mjaft bazik. Nuk \u00ebsht\u00eb e nevojshme ta p\u00ebrshkruani gjith\u00e7ka n\u00eb detaje, por nj\u00eb p\u00ebrshkrim themelor \u00ebsht\u00eb i domosdosh\u00ebm q\u00eb t\u00eb punoni me k\u00ebt\u00eb. N\u00eb t\u00eb kund\u00ebrt, nuk \u00ebsht\u00eb e qart\u00eb se mbi \u00e7far\u00eb duhet t\u00eb b\u00ebni vazhdimin e p\u00ebrhersh\u00ebm. T\u00eb gjitha k\u00ebto praktika zbatohen n\u00eb m\u00ebnyr\u00eb t\u00eb nj\u00ebkohshme kur arrini n\u00eb DevOps, por duhet t\u00eb filloni me kuptimin e asaj q\u00eb keni dhe si ta menaxhoni at\u00eb. Kjo \u00ebsht\u00eb pik\u00ebrisht praktika e infrastruktur\u00ebs si kod.<\/p>\n

Pasi kuptoni at\u00eb q\u00eb keni dhe si ta menaxhoni, filloni t\u00eb mendoni si ta d\u00ebrgoni kodin e zhvilluesit sa m\u00eb shpejt n\u00eb prodhim. Kam parasysh s\u00eb bashku me zhvilluesin \u2014 mos haroni problemin e \u00abpus\u00ebve\u00bb, q\u00eb do t\u00eb thot\u00eb se nuk jan\u00eb individ\u00eb t\u00eb ve\u00e7ant\u00eb q\u00eb e mendojn\u00eb k\u00ebt\u00eb, por ekipi.<\/p>\n

Kur ne\u00a0Vanja Evtukhovich<\/b> pam\u00eb librin e par\u00eb Jez Hembla<\/b> dhe grupin e autor\u00ebve \u00abContinuous Delivery\u00bb<\/b>, e cila doli n\u00eb vitin 2009, menduam p\u00ebr nj\u00eb koh\u00eb t\u00eb gjat\u00eb se si ta p\u00ebrkthenim titullin e saj n\u00eb shqip. Donim ta p\u00ebrkthenim si \"D\u00ebrgesa e vazhdueshme\", por, fatkeq\u00ebsisht, e p\u00ebrkthyer si \"D\u00ebrgesa e pand\u00ebrprer\u00eb\". M\u00eb duket se titulli yn\u00eb ka di\u00e7ka shqiptare, me forc\u00eb.<\/p>\n

D\u00ebrgesa e vazhdueshme do t\u00eb thot\u00eb<\/h3>\n

\nKodet q\u00eb ndodhen n\u00eb depozit\u00ebn e produktit mund t\u00eb nxirren gjithmon\u00eb n\u00eb prodhim<\/b>. Ai mund t\u00eb mos nxirret, por gjithmon\u00eb \u00ebsht\u00eb gati p\u00ebr k\u00ebt\u00eb. Prandaj, gjithmon\u00eb shkruani kodin me nj\u00eb ndjenj\u00eb t\u00eb v\u00ebshtir\u00eb p\u00ebr t'u shpjeguar t\u00eb nj\u00eb shqet\u00ebsimi n\u00eb pjes\u00ebn e poshtme t\u00eb shpin\u00ebs. Kjo ndjenj\u00eb shqet\u00ebsimi shpesh shfaqet kur nxjerrni kodin e infrastruktur\u00ebs. Kjo ndjenj\u00eb shqet\u00ebsimi duhet t\u00eb jet\u00eb e pranishme \u2013 ajo aktivizon proceset mendore q\u00eb lejojn\u00eb t\u00eb shkruani kodin pak ndryshe. Kjo duhet t\u00eb dokumentohet n\u00eb rregullat brenda zhvillimit.<\/p>\n

P\u00ebr t\u00eb d\u00ebrguar vazhdimisht, nevojitet nj\u00eb format artefakti q\u00eb kalon n\u00ebp\u00ebr platform\u00ebn infrastrukturore. <\/b>N\u00ebse po d\u00ebrgoni \"mbeturina\" t\u00eb formateve t\u00eb ndryshme mbi platform\u00ebn infrastrukturore, ajo b\u00ebhet e paunifikuar, \u00ebsht\u00eb e v\u00ebshtir\u00eb p\u00ebr ta mbajtur, krijohet 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 s\u00eb bashku, t\u00eb p\u00ebrdorim mendjen dhe t\u00eb krijojm\u00eb k\u00ebt\u00eb format.<\/p>\n

Artefakti p\u00ebrmir\u00ebsohet dhe ndryshon vazhdimisht sipas mjedisit t\u00eb prodhimit gjat\u00eb kalimit n\u00ebp\u00ebr pipeline t\u00eb dor\u00ebzimit. <\/b>Kur artefakti l\u00ebviz p\u00ebrmes pipeline-it, ai p\u00ebrballet vazhdimisht me disa gj\u00ebra t\u00eb pak\u00ebndshme p\u00ebr t\u00eb, t\u00eb cilat i ngjasojn\u00eb atyre me t\u00eb cilat p\u00ebrballet artefakti q\u00eb po e publikoni n\u00eb prodhim. N\u00eb zhvillimin tradicional, nj\u00eb administrator sistemi merret me publikimin, nd\u00ebrsa n\u00eb procesin DevOps kjo ndodh vazhdimisht: k\u00ebtu e rrotullojn\u00eb me disa teste, k\u00ebtu e hedhin n\u00eb Kubernetes cluster q\u00eb ngjason m\u00eb shum\u00eb me prodhimin, k\u00ebtu papritur fillojn\u00eb testimin e ngarkes\u00ebs.<\/p>\n

Kjo i ngjan nj\u00eb loje Pac-Man \u2014 artefakti kalon n\u00ebp\u00ebr nj\u00eb histori. \u00cbsht\u00eb e r\u00ebnd\u00ebsishme t\u00eb kontrolloni n\u00ebse kodi kalon n\u00ebp\u00ebr k\u00ebt\u00eb histori dhe n\u00ebse ajo nd\u00ebrlidhet me prodhimin tuaj. Historia me prodhimin mund t\u00eb p\u00ebrfshihet brenda procesit t\u00eb Continuous Delivery: ndodhte k\u00ebshtu, kur di\u00e7ka d\u00ebshtoi, tani le t\u00eb programojm\u00eb thjesht k\u00ebt\u00eb skenar brenda sistemit. \u00c7do her\u00eb kodi do t\u00eb kaloj\u00eb k\u00ebt\u00eb skenar gjithashtu, dhe nuk do t\u00eb p\u00ebrballeni me k\u00ebt\u00eb problem tjet\u00ebr her\u00eb. Do t\u00eb informoheni p\u00ebr t\u00eb shum\u00eb m\u00eb her\u00ebt, para se t\u00eb dal\u00eb te klienti juaj.<\/p>\n

Strategji t\u00eb ndryshme t\u00eb deploy-eve. <\/b>P\u00ebr shembull, ju p\u00ebrdorni AB-testimin ose deploy-t\u00eb kanarin\u00eb, p\u00ebr t\u00eb provuar n\u00eb m\u00ebnyra t\u00eb ndryshme kodin te klient\u00eb t\u00eb ndrysh\u00ebm, p\u00ebr t\u00eb marr\u00eb informacion mbi se si punon kodi, dhe shum\u00eb m\u00eb her\u00ebt se sa do t\u00eb nxitohet p\u00ebr 100 milion p\u00ebrdorues.<\/p>\n

\u00abT\u00eb dor\u00ebzosh vazhdimisht\u00bb duket k\u00ebshtu.<\/p>\n

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

Processi i dor\u00ebzimit Dev, CI, Test, PreProd, Prod \u2014 nuk \u00ebsht\u00eb nj\u00eb ambient i ve\u00e7ant\u00eb, jan\u00eb faza ose stacione me shuma t\u00eb pathyeshme p\u00ebr t\u00eb cilat kalon artefakti juaj.<\/p><\/blockquote>\n

\nN\u00ebse keni kodin infrastruktural t\u00eb p\u00ebrshkruar si Base Service APP, ai ndihmon t\u00eb mos harroni gjith\u00eb skenar\u00ebt<\/b>, dhe t\u00eb regjistrohen gjithashtu n\u00eb form\u00ebn e kodit p\u00ebr k\u00ebt\u00eb artefakt, t\u00eb promovoni artefaktin<\/b> dhe ta ndryshoni gjat\u00eb rrug\u00ebs.<\/p>\n

Pyetje p\u00ebr vet\u00ebvler\u00ebsim<\/h3>\n

\nA \u00ebsht\u00eb koha nga p\u00ebrshkrimi i ve\u00e7oris\u00eb deri te lansimi n\u00eb prodhim n\u00eb 95% t\u00eb rasteve m\u00eb pak se nj\u00eb jav\u00eb? A rritet cil\u00ebsia e artefaktit n\u00eb \u00e7do hap t\u00eb pipeline? A ka nj\u00eb histori p\u00ebr t\u00eb cil\u00ebn ai kalon? A p\u00ebrdorni strategji t\u00eb ndryshme p\u00ebr nd\u00ebrrimin?<\/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 shk\u00eblqyer! Shkruani p\u00ebrgjigjet n\u00eb komente - do t\u00eb isha i lumtur).<\/p>\n

Feedback<\/h3>\n

\nKjo \u00ebsht\u00eb prakika 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 kjo \u00ebsht\u00eb me t\u00eb v\u00ebrtet\u00eb nj\u00eb praktik\u00eb shum\u00eb e v\u00ebshtir\u00eb p\u00ebr at\u00eb q\u00eb duhet t\u00eb monitoroni gjith\u00e7ka!<\/p>\n

\"\u00c7far\u00eb
\n
\nP\u00ebr shembull, shum\u00eb koh\u00eb m\u00eb par\u00eb, kur punoja n\u00eb Qik dhe kuptuam se duhet t\u00eb monitoronim gjith\u00e7ka. Ne e b\u00ebm\u00eb k\u00ebt\u00eb, dhe n\u00eb Zabbix kishim 150,000 items q\u00eb monitoroheshin vazhdimisht. Kjo ishte e frikshme, dhe drejtori teknik po p\u00ebrk\u00ebdhelte gishti n\u00eb tempull:<\/p>\n

\u2014 Djem, p\u00ebrse po e ngacmoni serverin me gj\u00ebra t\u00eb paqart\u00eb?<\/i><\/p>\n

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

Nj\u00eb nga sh\u00ebrbimet filloi t\u00eb bjer\u00eb vazhdimisht. N\u00eb fillim nuk kishte r\u00ebn\u00eb, q\u00eb \u00ebsht\u00eb interesante, pasi nuk ishte shkruar kod atje, sepse ishte nj\u00eb broker baz\u00eb, n\u00eb t\u00eb cilin praktikisht nuk kishte funksionalitete biznesi - ai thjesht transmetonte mesazhe midis sh\u00ebrbimeve t\u00eb ndryshme. Sh\u00ebrbimi nuk ishte ndryshuar p\u00ebr 4 muaj, dhe papritmas filloi t\u00eb binte me gabimin \"Segmentation fault\".<\/p>\n

Ishim t\u00eb shokuar, hap\u00ebm grafikun ton\u00eb n\u00eb Zabbix, dhe zbuluam se, realisht, sjellja e k\u00ebrkesave n\u00eb sh\u00ebrbimin API q\u00eb p\u00ebrdor k\u00ebt\u00eb broker kishte ndryshuar ndjesh\u00ebm nj\u00eb jav\u00eb e gjysm\u00eb m\u00eb par\u00eb. Pastaj ne pam\u00eb se frekuenca e d\u00ebrgimit t\u00eb nj\u00eb lloji t\u00eb caktuar mesazhesh kishte ndryshuar. M\u00eb pas zbuluam se ishin klient\u00ebt android. Pyet\u00ebm:<\/p>\n

\u2014 Djem, \u00e7far\u00eb ndodhi me ju nj\u00eb jav\u00eb e gjysm\u00eb m\u00eb par\u00eb?<\/i><\/p>\n

N\u00eb p\u00ebrgjigje, d\u00ebgjuam nj\u00eb histori interesante n\u00eb lidhje me ri-dizajnimin e UI. \u00cbsht\u00eb e v\u00ebshtir\u00eb t\u00eb thuhet menj\u00ebher\u00eb se ata e kan\u00eb ndryshuar bibliotek\u00ebn HTTP. P\u00ebr klient\u00ebt Android, kjo \u00ebsht\u00eb si t\u00eb nd\u00ebrroni sapunin n\u00eb banj\u00eb \u2014 ata thjesht nuk e mbajn\u00eb mend. Pas 40 minutash bised\u00eb, ne zbuluam se ata n\u00eb t\u00eb v\u00ebrtet\u00eb kan\u00eb ndryshuar bibliotek\u00ebn HTTP, dhe koha e saj e paracaktuar ishte ndryshuar. Kjo shkaktoi nj\u00eb ndryshim n\u00eb sjelljen e trafikut n\u00eb serverin API, \u00e7ka rezultoi n\u00eb nj\u00eb situat\u00eb q\u00eb shkaktoi nj\u00eb gar\u00eb brenda brokerit, dhe ai filloi t\u00eb bjer\u00eb.<\/p>\n

Pa monitorim t\u00eb thell\u00eb, kjo \u00ebsht\u00eb krejt\u00ebsisht e pamundur t\u00eb zbulohet.<\/b>. N\u00ebse organizata ka gjithashtu nj\u00eb problem me \"puset\", kur secili e kalon p\u00ebrgjegj\u00ebsin\u00eb te tjetri, kjo mund t\u00eb vazhdoj\u00eb p\u00ebr vite. Thjesht e rivendosni serverin, sepse \u00ebsht\u00eb e pamundur t\u00eb zgjidhni problemin. Kur monitoroni, ndjekni, regjistroni t\u00eb gjitha ngjarjet q\u00eb keni, dhe p\u00ebrdorni monitorimin si testim \u2014 shkruani kodin dhe menj\u00ebher\u00eb e sh\u00ebni se si ta monitoroni at\u00eb, gjithashtu n\u00eb form\u00ebn e kodit (ne tashm\u00eb kemi infrastruktura si kod), gjith\u00e7ka b\u00ebhet e qart\u00eb si n\u00eb p\u00ebll\u00ebmb\u00eb. Madje, problemet kaq t\u00eb komplikuara ndjekin leht\u00ebsisht.<\/p>\n

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

Mblidhni t\u00eb gjitha informacionet n\u00eb lidhje me at\u00eb q\u00eb ndodh me artefaktin n\u00eb \u00e7do faz\u00eb t\u00eb procesit t\u00eb furnizimit - jo n\u00eb produksion.<\/p><\/blockquote>\n

\nNgarkoni monitorimin n\u00eb CI, dhe atje do t\u00eb shihni disa gj\u00ebra bazike. M\u00eb pas do t'i shihni edhe n\u00eb Test, edhe n\u00eb PredProd, dhe n\u00eb testimin e ngarkes\u00ebs. Mblidhni informacion n\u00eb t\u00eb gjitha fazat, p\u00ebrfshir\u00eb jo vet\u00ebm metrikat, statistikat, por edhe logjet: si u publikua aplikacioni, anomali - 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, duhet t\u00eb keni nj\u00eb analitik\u00eb t\u00eb 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 gjithashtu ju, gjat\u00eb shkrimit t\u00eb kodit, se si ta monitorojn\u00eb at\u00eb?<\/p>\n

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

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

Platforma Infrastruktuore <\/h2>\n

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

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

\nNatyrisht, ka ekipe t\u00eb ve\u00e7anta q\u00eb jan\u00eb p\u00ebrgjegj\u00ebse 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 gjith\u00eb inxhinier\u00ebve. N\u00eb nivelin e brendsh\u00ebm, kjo b\u00ebhet nj\u00eb mjet i p\u00ebrbashk\u00ebt<\/b>. <\/p>\n

T\u00eb gjitha ekipet zhvillojn\u00eb platform\u00ebn infrastrukturore dhe i qasen asaj me kujdes si nj\u00eb IDE t\u00eb vetin.<\/b>. N\u00eb IDE-n\u00eb tuaj vendosni plugins t\u00eb ndryshme p\u00ebr t\u00eb gjitha t\u00eb duken bukur dhe t\u00eb shpejta, konfiguroni \u00e7el\u00ebsa t\u00eb nxeht\u00eb. Kur hapni Sublime, Atom ose Visual Studio Code, keni shum\u00eb gabime n\u00eb kod dhe kuptoni se \u00ebsht\u00eb e pamundur t\u00eb punoni, ndiheni menj\u00ebher\u00eb t\u00eb trishtuar dhe shkoni t\u00eb riparoni IDE-n\u00eb tuaj.<\/p>\n

Trajtojini ndryshe lidhjen tuaj me platform\u00ebn infrastrukturore. N\u00ebse e kuptoni se di\u00e7ka nuk shkon me t\u00eb, d\u00ebrgoni nj\u00eb k\u00ebrkes\u00eb n\u00ebse nuk mund ta rregulloni vet\u00eb. Por n\u00ebse \u00ebsht\u00eb di\u00e7ka e thjesht\u00eb, at\u00ebher\u00eb rregulloni vet\u00eb, d\u00ebrgoni nj\u00eb pull request - ekipi i shqyrton dhe miraton. Ky \u00ebsht\u00eb nj\u00eb qasje krejt tjet\u00ebr ndaj mjetit inxhinierik n\u00eb mendjen e zhvilluesit.<\/p>\n

Platforma infrastrukturore siguron transferimin e artefaktit nga zhvillimi te klienti me nj\u00eb p\u00ebrmir\u00ebsim t\u00eb vazhduesh\u00ebm t\u00eb cil\u00ebsis\u00eb.<\/b>. N\u00eb IP ka nj\u00eb grup historish t\u00eb programuar q\u00eb ndodhin me kodin n\u00eb prodhim. Gjat\u00eb viteve t\u00eb zhvillimit, k\u00ebto histori b\u00ebhen shum\u00eb, nj\u00eb pjes\u00eb e tyre jan\u00eb unike dhe i p\u00ebrkasin vet\u00ebm juve - nuk mund t\u00eb gjenden n\u00eb internet. <\/p>\n

N\u00eb k\u00ebt\u00eb moment, platforma infrastrukturore b\u00ebhet avantazhi juaj konkurrues,<\/b>, sepse p\u00ebrmban at\u00eb q\u00eb nuk e ka mjeti i konkurrentit. Sa m\u00eb e thell\u00eb t\u00eb jet\u00eb IP-ja juaj, aq m\u00eb shum\u00eb avantazh konkurrues keni n\u00eb aspektin e Time-to-market. K\u00ebtu paraqitet problemi i bllokimit nga shit\u00ebsi<\/b>: ju mund t\u00eb merrni nj\u00eb platform\u00eb t\u00eb huaj, por duke p\u00ebrdorur p\u00ebrvoj\u00ebn e dikujt tjet\u00ebr, nuk do t\u00eb kuptoni se sa e r\u00ebnd\u00ebsishme \u00ebsht\u00eb ajo p\u00ebr ju. Po, nuk \u00e7do kompani mund t\u00eb nd\u00ebrtoj\u00eb nj\u00eb platform\u00eb si Amazon. Kjo \u00ebsht\u00eb nj\u00ebnuanc\u00eb e komplikuar, ku p\u00ebrvoja e nj\u00eb kompanie \u00ebsht\u00eb e r\u00ebnd\u00ebsishme p\u00ebr pozit\u00ebn e saj n\u00eb treg, dhe nuk duhet lejuar vendor lock. Kjo \u00ebsht\u00eb gjithashtu e r\u00ebnd\u00ebsishme p\u00ebr t'u menduar.<\/p>\n

Skema<\/h3>\n

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

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

Sistemi i orkestrimit t\u00eb burimeve<\/b>, i cili ofron CPU, memorie, dhe disk p\u00ebr aplikacionet dhe sh\u00ebrbime t\u00eb tjera. M\u00eb sip\u00ebr k\u00ebsaj - sh\u00ebrbimet e nivelit t\u00eb ul\u00ebt<\/b>: monitorimi, logimi, CI\/CD Engine, depoja e artefakteve, infrastruktura si kod e sistemeve.<\/p>\n

Sh\u00ebrbimet e nivelit m\u00eb t\u00eb lart\u00eb<\/b>: baza e t\u00eb dh\u00ebnave si sh\u00ebrbim, radh\u00eb si sh\u00ebrbim, Load Balance si sh\u00ebrbim, resizing imazhesh si sh\u00ebrbim, Big Data fabrik\u00eb si sh\u00ebrbim. M\u00eb sip\u00ebr k\u00ebsaj - pipeline, i cili d\u00ebrgon kodin e modifikuar vazhdimisht tek klienti juaj<\/b>.<\/p>\n

Merrni informacione mbi m\u00ebnyr\u00ebn se si funksionon softueri juaj te klienti, ndihmoni, ripakoni k\u00ebt\u00eb kod, merrni informacione - dhe k\u00ebshtu vazhdoni p\u00ebr t\u00eb zhvilluar p\u00ebrher\u00eb platform\u00ebn infrastrukturore dhe softuerin tuaj.<\/p>\n

N\u00eb diagramin e delivery pipeline p\u00ebrb\u00ebhet nga shum\u00eb faza. Por kjo \u00ebsht\u00eb nj\u00eb skem\u00eb themelore, e dh\u00ebn\u00eb si shembull - nuk \u00ebsht\u00eb e nevojshme ta p\u00ebrs\u00ebritni sakt\u00ebsisht. Faza nd\u00ebrveprojn\u00eb me sh\u00ebrbimet, si sh\u00ebrbime - \u00e7do element i platform\u00ebs ka historin\u00eb e vet: si alokohen burimet, si aktivizohet aplikacioni, punon me burimet, monitorohet dhe ndryshohet.<\/p>\n

\u00cbsht\u00eb e r\u00ebnd\u00ebsishme t\u00eb kuptohet se \u00e7do pjes\u00eb e platform\u00ebs ka nj\u00eb histori, dhe t\u00eb pyesim veten - \u00e7far\u00eb historie ka ky element, ndoshta duhet ta hedhim at\u00eb dhe t\u00eb z\u00ebvend\u00ebsojm\u00eb me nj\u00eb sh\u00ebrbim t\u00eb jasht\u00ebm. P\u00ebr shembull, mund t\u00eb vendosim Okmeter n\u00eb vend t\u00eb k\u00ebtij elementi? Ndoshta, ata e kan\u00eb zhvilluar k\u00ebt\u00eb ekspertiz\u00eb shum\u00eb m\u00eb tep\u00ebr se ne. Por ndoshta jo - ndoshta ne kemi nj\u00eb ekspertiz\u00eb unike, na nevojitet t\u00eb vendosim Prometheus dhe ta zhvillojm\u00eb m\u00eb tej.<\/p>\n

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

\nKy \u00ebsht\u00eb nj\u00eb proces kompleks komunikimi. Kur keni praktikat themelore, filloni komunikimin mes inxhinier\u00ebve dhe specialist\u00ebve t\u00eb ndrysh\u00ebm, t\u00eb cil\u00ebt zhvillojn\u00eb k\u00ebrkesat dhe standardet dhe i ndryshojn\u00eb ato vazhdimisht bashk\u00eb me mjetet dhe qasjet e ndryshme. Kultura k\u00ebtu \u00ebsht\u00eb e r\u00ebnd\u00ebsishme p\u00ebr DevOps.<\/p>\n

\"\u00c7far\u00eb
\nMe kultur\u00ebn \u00ebsht\u00eb shum\u00eb e thjesht\u00eb \u2014 \u00ebsht\u00eb bashk\u00ebpunim dhe komunikim<\/b>, dometh\u00ebn\u00eb d\u00ebshira p\u00ebr t\u00eb punuar s\u00eb bashku n\u00eb nj\u00eb fush\u00eb t\u00eb p\u00ebrbashk\u00ebt, d\u00ebshira p\u00ebr t\u00eb zot\u00ebruar nj\u00eb mjet s\u00eb bashku. Nuk ka asgj\u00eb t\u00eb komplikuar \u2014 gjith\u00e7ka \u00ebsht\u00eb shum\u00eb e thjesht\u00eb, banale. P\u00ebr shembull, ne t\u00eb gjith\u00eb jetojm\u00eb n\u00eb nj\u00eb hyrje dhe mbajm\u00eb past\u00ebrtin\u00eb e saj \u2014 ky \u00ebsht\u00eb niveli i kultur\u00ebs.<\/p>\n

Dhe ju?<\/h3>\n

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

A \u00ebsht\u00eb ndar\u00eb platforma infrastrukturore? Kush p\u00ebrgjigjet 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 di\u00e7ka mund t\u00eb sillet n\u00eb sh\u00ebrbime t\u00eb jashtme \u2014 duhet ta sillni, n\u00ebse nj\u00eb sh\u00ebrbim i jasht\u00ebm fillon t\u00eb bllokoj\u00eb l\u00ebvizjen tuaj, at\u00ebher\u00eb duhet t\u00eb nd\u00ebrtoni nj\u00eb sistem brenda vetes.<\/p>\n

\u0418\u0442\u0430\u043a, DevOps…<\/h2>\n

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