{"id":55870,"date":"2020-01-30T00:00:00","date_gmt":"2020-01-29T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/ot-skriptov-k-sobstvennoj-platforme-kak-my-avtomatizirovali-razrabotku-v-tsian"},"modified":"2020-02-18T14:04:02","modified_gmt":"2020-02-18T11:04:02","slug":"ot-skriptov-k-sobstvennoj-platforme-kak-my-avtomatizirovali-razrabotku-v-tsian","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sq\/blog\/administrirovanie\/ot-skriptov-k-sobstvennoj-platforme-kak-my-avtomatizirovali-razrabotku-v-tsian","title":{"rendered":"Nga skriptet n\u00eb platform\u00ebn ton\u00eb: si e automatizuam zhvillimin n\u00eb CIAN","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Nga
\n
\nN\u00eb RIT 2019, kolegu yn\u00eb Aleksand\u00ebr Korotkov b\u00ebri raport<\/a><\/noindex> p\u00ebr automatizimin e zhvillimit n\u00eb CIAN: q\u00eb t\u00eb thjeshtojm\u00eb jet\u00ebn dhe pun\u00ebn, ne p\u00ebrdorim platform\u00ebn ton\u00eb t\u00eb brendshme Integro. Ajo ndjek ciklin jet\u00ebsor t\u00eb detyrave, eliminon operacionet rutin\u00eb nga zhvilluesit dhe zvog\u00eblon ndjesh\u00ebm numrin e defekteve n\u00eb prodhim. N\u00eb k\u00ebt\u00eb postim, ne do t\u00eb plot\u00ebsojm\u00eb referatin e Aleksandrit dhe do t\u00eb tregojm\u00eb si kaluam nga skriptet e thjeshta n\u00eb bashkimin e produkteve open source p\u00ebrmes platform\u00ebs son\u00eb dhe me \u00e7far\u00eb merret nj\u00eb ekip i ve\u00e7ant\u00eb p\u00ebr automatizimin.
\n\u00a0<\/a><\/noindex><\/p>\n

Niveli zero<\/h2>\n

\n\"Niveli zero nuk ekziston, un\u00eb nuk e di nj\u00eb t\u00eb till\u00eb\"<\/b>
\nM\u00ebsuesi Shifu nga filmi \"Kung Fu Panda\"<\/i><\/p>\n

Automatizimi n\u00eb CIAN filloi pas 14 vjet\u00ebsh nga themelimi i kompanis\u00eb. At\u00ebher\u00eb ekipi i zhvillimit kishte 35 njer\u00ebz. E v\u00ebshtir\u00eb p\u00ebr t'u besuar, apo jo? Sigurisht, n\u00eb nj\u00ebfar\u00eb forme automatizimi tashm\u00eb ekzistonte, por nj\u00eb drejtim i ve\u00e7ant\u00eb p\u00ebr integrimin dhe shp\u00ebrndarjen e vazhdueshme t\u00eb kodit filloi t\u00eb formohej pik\u00ebrisht n\u00eb vitin 2015.\u00a0<\/p>\n

N\u00eb at\u00eb koh\u00eb ne kishim nj\u00eb monolit t\u00eb madh nga Python, C# dhe PHP, i instaluar n\u00eb serverat Linux\/Windows. P\u00ebr t\u00eb b\u00ebr\u00eb deploy t\u00eb k\u00ebtij monst\u00ebr ne kishim nj\u00eb set skriptesh, q\u00eb i aktivizonim manualisht. Ishte gjithashtu nd\u00ebrtimi i monolitit, q\u00eb sillte dhimbje dhe vuajtje p\u00ebr shkak t\u00eb konflikteve gjat\u00eb bashkimit t\u00eb deg\u00ebve, rregullimit t\u00eb defekteve dhe rin nd\u00ebrtimit \"me nj\u00eb set tjet\u00ebr detyrash n\u00eb nd\u00ebrtim\". Procesi dukej thjesht k\u00ebshtu:<\/p>\n

\"Nga
\n
\nKjo nuk na k\u00ebnaqte, dhe ne d\u00ebshironim t\u00eb nd\u00ebrtuonim nj\u00eb proces nd\u00ebrtimi dhe shp\u00ebrndarjeje t\u00eb rip\u00ebrs\u00ebritsh\u00ebm, t\u00eb automatizuar dhe t\u00eb menaxhuar. P\u00ebr k\u00ebt\u00eb na duhej nj\u00eb sistem CI\/CD, dhe ne zgjodh\u00ebm midis versionit falas t\u00eb Teamcity dhe Jenkins t\u00eb lir\u00eb, pasi kishim punuar me to dhe t\u00eb dy na plot\u00ebsonin me t\u00eb nj\u00ebjtat funksionalitete. Zgjodh\u00ebm Teamcity si produkt m\u00eb t\u00eb ri. At\u00ebher\u00eb ne ende nuk kishim p\u00ebrdorur arkitektur\u00ebn mikrosh\u00ebrbimesh dhe nuk prisnim shum\u00eb detyra dhe projekte.<\/p>\n

Arrijm\u00eb te ideja p\u00ebr nj\u00eb sistem t\u00eb brendsh\u00ebm<\/h2>\n

\nZgjedhja e Teamcity hoqi vet\u00ebm nj\u00eb pjes\u00eb t\u00eb pun\u00ebs manuale: mbeti ende krijimi i Pull Request-eve, avancimi i detyrave sipas statusit n\u00eb Jira, zgjedhja e detyrave p\u00ebr rrelease. Me k\u00ebt\u00eb, sistemi Teamcity nuk munde m\u00eb t\u00eb p\u00ebrballoj\u00eb. Duhej t\u00eb zgjidheshin rrug\u00ebt e m\u00ebtejshme t\u00eb automatizimit. Ne shqyrtuam mund\u00ebsit\u00eb e pun\u00ebs me skriptet n\u00eb Teamcity ose kalimin n\u00eb sisteme t\u00eb jashtme t\u00eb automatizimit. Por n\u00eb fund, vendos\u00ebm se na duhej fleksibiliteti maksimal, t\u00eb cilin e jep vet\u00ebm nj\u00eb zgjidhje e brendshme. K\u00ebshtu u shfaq versioni i par\u00eb i sistemit t\u00eb brendsh\u00ebm t\u00eb automatizimit t\u00eb quajtur Integro.<\/p>\n

Teamcity merret me automatizimin n\u00eb nivelin e fillimit t\u00eb proceseve t\u00eb nd\u00ebrtimit dhe dep_limit, nd\u00ebrsa Integro \u00ebsht\u00eb fokusuar n\u00eb automatizimin e proceseve t\u00eb zhvillimit n\u00eb nivel m\u00eb t\u00eb lart\u00eb. Duhej t\u00eb bashkonte pun\u00ebn me detyrat n\u00eb Jira me p\u00ebrpunimin e kodit burimor t\u00eb lidhur n\u00eb Bitbucket. N\u00eb k\u00ebt\u00eb faz\u00eb, brenda Integro filluan t\u00eb shfaqen workflow t\u00eb veta p\u00ebr t\u00eb punuar me detyra t\u00eb tipave t\u00eb ndrysh\u00ebm.\u00a0<\/p>\n

P\u00ebr shkak t\u00eb rritjes s\u00eb automatizimit n\u00eb proceset e biznesit, numri i projekteve dhe run-eve n\u00eb Teamcity u rrit. K\u00ebshtu erdhi nj\u00eb problem i ri: nj\u00eb instanc\u00eb falas e Teamcity nuk mjaftonte (3 agjent\u00eb dhe 100 projekte), ne shtuam nj\u00eb instanc\u00eb tjet\u00ebr (edhe 3 agjent\u00eb dhe 100 projekte), pastaj edhe nj\u00eb tjet\u00ebr. N\u00eb fund mor\u00ebm nj\u00eb sistem prej disa klasteresh, t\u00eb cilin ishte e v\u00ebshtir\u00eb ta menaxhonim:<\/p>\n

\"Nga
\n
\nKur doli n\u00eb pyetje nj\u00eb instanc\u00eb e kat\u00ebrt, ne kuptuam q\u00eb nuk mund t\u00eb jetonim m\u00eb k\u00ebshtu, sepse shpenzimet totale p\u00ebr mb\u00ebshtetje e kat\u00ebr instancave nuk p\u00ebrballoheshin m\u00eb. U hodh n\u00eb diskutim blerja e nj\u00eb Teamcity me pages\u00eb ose zgjedhja e Jenkins-it falas. Ne b\u00ebm\u00eb llogaritjet p\u00ebr instancat dhe planet p\u00ebr automatizimin dhe vendos\u00ebm q\u00eb do t\u00eb jetonim me Jenkins. Pasi kaluam disa jav\u00eb, u kaluam n\u00eb Jenkins dhe u liruar nga nj\u00eb pjes\u00eb e dhimbjes s\u00eb kok\u00ebs lidhur me mb\u00ebshtetjen e disa instancave t\u00eb Teamcity. K\u00ebshtu, arrit\u00ebm t\u00eb p\u00ebrqendrohemi n\u00eb zhvillimin e Integro dhe p\u00ebrshtatjen e Jenkins sipas nevojave tona.<\/p>\n

Me rritjen e automatizimit baz\u00eb (n\u00eb form\u00ebn e krijimit automatik t\u00eb Pull Request-eve, grumbullimit dhe publikimit t\u00eb Code coverage dhe kontrollesh t\u00eb tjera) u shfaq nj\u00eb d\u00ebshir\u00eb e fort\u00eb p\u00ebr t\u00eb minimizuar n\u00eb maksimum l\u00ebshimet manuale dhe p\u00ebr t'i dh\u00ebn\u00eb k\u00ebt\u00eb pun\u00eb robot\u00ebve. P\u00ebrve\u00e7 k\u00ebsaj, brenda kompanis\u00eb filloi kalimi n\u00eb mikrosh\u00ebrbime, t\u00eb cilat k\u00ebrkonin l\u00ebshime t\u00eb shpeshta, dhe p\u00ebrve\u00e7 k\u00ebsaj, t\u00eb ndara nga nj\u00ebra-tjetra. K\u00ebshtu ne gradualisht arrit\u00ebm te l\u00ebshimet automatike t\u00eb mikrosh\u00ebrbimeve tona (monoliti e l\u00ebshojm\u00eb akoma manualisht p\u00ebr shkak t\u00eb kompleksitetit t\u00eb procesit). Por, si\u00e7 ndodh zakonisht, lind\u00ebn v\u00ebshtir\u00ebsi t\u00eb reja.\u00a0<\/p>\n

Automatizojm\u00eb testimin<\/h2>\n

\n\"Nga
\n
\nP\u00ebr shkak t\u00eb automatizimit t\u00eb l\u00ebshimeve, proceset e zhvillimit u p\u00ebrshpejtuan, pjes\u00ebrisht p\u00ebrmes anashkalimit t\u00eb disa fazave t\u00eb testimit. Dhe kjo \u00e7oi n\u00eb humbje t\u00eb p\u00ebrkohshme t\u00eb cil\u00ebsis\u00eb. Duket banale, por s\u00eb bashku me p\u00ebrshpejtimin e l\u00ebshimeve, duhej t\u00eb ndryshonim edhe metodologjin\u00eb e zhvillimit t\u00eb produktit. Duhej t\u00eb mendonim p\u00ebr automatizimin e testimit, p\u00ebr forcimin e p\u00ebrgjegj\u00ebsis\u00eb personale (k\u00ebtu flasim p\u00ebr 'pranimin e ideve n\u00eb mendje', dhe jo p\u00ebr gjoba financiare) t\u00eb zhvilluesit p\u00ebr kodin e l\u00ebshuar dhe p\u00ebr gabit\u00eb q\u00eb ndodhen n\u00eb t\u00eb, si dhe p\u00ebr nj\u00eb zgjidhje p\u00ebr l\u00ebshimin\/nuk l\u00ebshimin e detyrave p\u00ebrmes automatizimeve t\u00eb deploy.\u00a0<\/p>\n

Duke eliminuar problemet me cil\u00ebsin\u00eb, arrit\u00ebm dy vendime t\u00eb r\u00ebnd\u00ebsishme: filluam t\u00eb b\u00ebjm\u00eb testim kanar dhe kemi implementuar monitorim automatik t\u00eb gabimeve me reagim automatike n\u00eb rast se kalon nj\u00eb nivel t\u00eb caktuar. Vendimi i par\u00eb leht\u00ebsoi gjetjen e gabimeve evidente para se kodi t\u00eb arrij\u00eb n\u00eb production, nd\u00ebrsa vendimi i dyt\u00eb zvog\u00ebloi koh\u00ebn e reagimit ndaj problemeve n\u00eb production. Gabimet, natyrisht, ndodhin, por ne shpenzojm\u00eb shumic\u00ebn e koh\u00ebs dhe forc\u00ebs jo p\u00ebr t'i korrigjuar ato, por p\u00ebr t'i minimizuar.\u00a0<\/p>\n

Ekipi i automatizimit<\/h2>\n

\nTani kemi nj\u00eb staf prej 130 zhvilluesish, dhe ne vazhdojm\u00eb t\u00eb rritemi<\/a><\/noindex>. Ekipi p\u00ebr integrimin dhe dor\u00ebzimin e vazhduesh\u00ebm t\u00eb kodit (n\u00eb vazhdim \u2014 ekipi Deploy and Integration ose DI) p\u00ebrb\u00ebhet nga 7 veta dhe punon n\u00eb 2 drejtime: zhvillimin e platform\u00ebs s\u00eb automatizimit Integro dhe DevOps.\u00a0<\/p>\n

DevOps \u00ebsht\u00eb p\u00ebrgjegj\u00ebs p\u00ebr ambientet Dev\/Beta t\u00eb faqes CIAN, ambientet Integro, ndihmon zhvilluesit n\u00eb zgjidhjen e problemeve dhe zhvillon qasje t\u00eb reja p\u00ebr shkall\u00ebzimin e ambienteve. Direksioni i zhvillimit t\u00eb Integro merret si me Integro-n vet\u00eb, ashtu edhe me sh\u00ebrbime t\u00eb ngjashme, si p\u00ebr shembull me plugin-et p\u00ebr Jenkins, Jira, Confluence, dhe gjithashtu zhvillon mjete ndihm\u00ebse dhe aplikacione p\u00ebr ekipet e zhvilluesve.\u00a0<\/p>\n

Ekipi DI punon s\u00eb bashku me ekipin e Platform\u00ebs, i cili merret me zhvillimin e arkitektur\u00ebs, librarive dhe qasjeve t\u00eb zhvillimit brenda kompanis\u00eb. Bashk\u00eb me k\u00ebt\u00eb, \u00e7do zhvillues brenda CIAN-it mund t\u00eb kontribuoj\u00eb n\u00eb automatizim, p\u00ebr shembull, t\u00eb b\u00ebj\u00eb mikroautomatik min p\u00ebr nevojat e ekipit ose t\u00eb ndaj\u00eb nj\u00eb ide interesante, si t\u00eb b\u00ebj\u00eb automatizimin akoma m\u00eb t\u00eb mir\u00eb.<\/p>\n

Tort\u00eb e shum\u00ebfisht\u00eb e automatizimit n\u00eb CIAN<\/h2>\n

\n\"Nga
\n
\nT\u00eb gjitha sistemet e angazhuara n\u00eb automatizim mund t\u00eb ndahen n\u00eb disa nivele:<\/p>\n

    \n
  1. Sistemet e jashtme (Jira, Bitbucket etj.). Ekipet e zhvillimit punojn\u00eb me to.\n<\/li>\n
  2. Platforma Integro. Zakonisht, zhvilluesit nuk punojn\u00eb drejtp\u00ebrs\u00ebdrejti me t\u00eb, por pik\u00ebrisht ajo mb\u00ebshtet pun\u00ebn e gjith\u00eb automatizimit.\n<\/li>\n
  3. Sh\u00ebrbimet e dor\u00ebzimit, orkestrimit dhe zbulimit (p\u00ebr shembull, Jenkins, Consul, Nomad). Me to ne vendosim kodin n\u00eb serverat dhe sigurojm\u00eb funksionimin e sh\u00ebrbimeve me nj\u00ebra-tjetr\u00ebn.\n<\/li>\n
  4. Niveli fizik (servera, OS, softuer i ngjash\u00ebm). N\u00eb k\u00ebt\u00eb nivel funksionon kodi yn\u00eb. Kjo mund t\u00eb jet\u00eb nj\u00eb server fizik, ashtu si dhe nj\u00eb virtual (LXC, KVM, Docker).\n<\/li>\n<\/ol>\n

    \nDuke u bazuar n\u00eb k\u00ebt\u00eb koncept ne ndajm\u00eb zonat e p\u00ebrgjegj\u00ebsive brenda ekipit DI. Dy nivelet e para bien n\u00eb zon\u00ebn e p\u00ebrgjegj\u00ebsis\u00eb s\u00eb drejtimeve t\u00eb zhvillimit t\u00eb Integro, nd\u00ebrsa dy nivelet e fundit jan\u00eb n\u00eb zon\u00ebn e p\u00ebrgjegj\u00ebsis\u00eb t\u00eb DevOps. Kjo ndarje lejon p\u00ebrqendrimin n\u00eb detyra dhe nuk pengon bashk\u00ebpunimin, pasi jemi af\u00ebr nj\u00ebri-tjetrit dhe vazhdimisht shk\u00ebmbejm\u00eb dije dhe p\u00ebrvoj\u00eb.<\/p>\n

    Integro<\/h2>\n

    \nT\u00eb p\u00ebrqendrohemi n\u00eb Integro dhe t\u00eb fillojm\u00eb me tech stack-un:<\/p>\n