{"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 referatin<\/a><\/noindex> p\u00ebr automatizimin e zhvillimit n\u00eb CIAN: p\u00ebr t\u00eb thjeshtuar jet\u00ebn dhe pun\u00ebn, ne p\u00ebrdorim platform\u00ebn ton\u00eb t\u00eb brendshme Integro. Ajo ndjek ciklin e jet\u00ebs s\u00eb detyrave, heq nga zhvilluesit operacionet rutin\u00eb dhe zvog\u00eblon ndjesh\u00ebm numrin e gabimeve n\u00eb prodhim. N\u00eb k\u00ebt\u00eb post, do t\u00eb plot\u00ebsojm\u00eb leksionin e Aleksandrit dhe do t\u00eb tregojm\u00eb se si e kaluam rrug\u00ebn nga skenar\u00ebt e thjesht\u00eb n\u00eb integrimin e produkteve open source p\u00ebrmes platform\u00ebs son\u00eb dhe se me \u00e7far\u00eb merret nj\u00eb ekip i ve\u00e7ant\u00eb automatizimi.
\n\u00a0<\/a><\/noindex><\/p>\n

Niveli zero<\/h2>\n

\n\u00abNiveli zero nuk ekziston, nuk e di nj\u00eb t\u00eb till\u00eb\u00bb<\/b>
\nMjeshtri Shifu nga filmi \u00abKung Fu Panda\u00bb<\/i><\/p>\n

Automatizimi n\u00eb CIAN filloi 14 vjet pas themelimit t\u00eb kompanis\u00eb. At\u00ebher\u00eb ekipi i zhvillimit kishte 35 njer\u00ebz. V\u00ebshtir\u00eb t\u00eb besohej, apo jo? Sigurisht, n\u00eb nj\u00eb form\u00eb, automatizimi ekzistonte, por nj\u00eb drejtim i ve\u00e7ant\u00eb p\u00ebr integrimin e vazhduesh\u00ebm dhe shp\u00ebrndarjen e 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, t\u00eb instaluar n\u00eb server\u00eb Linux\/Windows. P\u00ebr depozimin e k\u00ebtij monstruoze, ne kishim nj\u00eb grup skenar\u00ebsh q\u00eb i ekzekutonim manualisht. Ishte gjithashtu nj\u00eb nd\u00ebrtim i monolitit, q\u00eb sillte dhimbje dhe vuajtje p\u00ebr shkak t\u00eb konflikteve t\u00eb bashkimeve t\u00eb deg\u00ebve, rregullimeve t\u00eb defekteve dhe ri-nd\u00ebrtimit \"me nj\u00eb grup tjet\u00ebr detyrash n\u00eb nd\u00ebrtim\". Thjesht, procesi dukej k\u00ebshtu:<\/p>\n

\"Nga
\n
\nKjo nuk na k\u00ebnaqte dhe ne donim t\u00eb nd\u00ebrtonim nj\u00eb proces t\u00eb nd\u00ebrtimit dhe shp\u00ebrndarjes t\u00eb p\u00ebrs\u00ebritur, 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 i lir\u00eb, pasi kishim punuar me t\u00eb dhe t\u00eb dy na k\u00ebnaqin me grupin e funksioneve. Zgjodh\u00ebm Teamcity si nj\u00eb produkt m\u00eb t\u00eb ri. N\u00eb at\u00eb koh\u00eb, ne nuk po p\u00ebrdornim arkitektur\u00eb mikros\u00ebrvish dhe nuk prisnim nj\u00eb num\u00ebr t\u00eb madh detyrash dhe projektesh.<\/p>\n

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

\nP\u00ebrvoja e zbatimit t\u00eb Teamcity reduktoi vet\u00ebm nj\u00eb pjes\u00eb t\u00eb pun\u00ebs manuale: mbeti ende krijimi i Pull Request-eve, avancimi i detyrave n\u00eb statuset n\u00eb Jira, dhe p\u00ebrzgjedhja e detyrave p\u00ebr l\u00ebshim. S\u00eb bashku, sistemi Teamcity nuk mund ta menaxhonte k\u00ebt\u00eb. Duhej t\u00eb zgjidhnim rrug\u00ebn p\u00ebr automatik\u00ebn e m\u00ebtejshme. Ne shqyrtuam mund\u00ebsit\u00eb e pun\u00ebs me skriptet n\u00eb Teamcity ose kalimin n\u00eb sisteme t\u00eb jashtme automatizimi. Por n\u00eb fund vendos\u00ebm se na nevojitej maksimalja fleksibilitetit q\u00eb ofron vet\u00ebm nj\u00eb zgjidhje e brendshme. K\u00ebshtu lindi 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 nisjes s\u00eb proceseve t\u00eb nd\u00ebrtimit dhe shp\u00ebrndarrjes, 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 bashkoheshin pun\u00ebt 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-e t\u00eb veta p\u00ebr t\u00eb punuar me detyra t\u00eb llojeve t\u00eb ndryshme.\u00a0<\/p>\n

P\u00ebr shkak t\u00eb rritjes s\u00eb automatizmit n\u00eb proceset e biznesit, u rrit numri i projekteve dhe run-eve n\u00eb Teamcity. K\u00ebshtu erdhi nj\u00eb problem i ri: nj\u00eb instanc\u00eb falas e Teamcity nuk ishte e mjaftueshme (3 agjent\u00eb dhe 100 projekte), shtuam nj\u00eb instanc\u00eb tjet\u00ebr (3 agjent\u00eb dhe 100 projekte) dhe pastaj edhe nj\u00eb tjet\u00ebr. N\u00eb p\u00ebrfundim, mor\u00ebm nj\u00eb sistem me disa klaster\u00eb q\u00eb ishte i v\u00ebshtir\u00eb p\u00ebr t'u menaxhuar:<\/p>\n

\"Nga
\n
\nKur u shfaq pyetja p\u00ebr nj\u00eb instanc\u00eb t\u00eb kat\u00ebrt, ne kuptuam se nuk mund t\u00eb vazhdojm\u00eb m\u00eb k\u00ebshtu, pasi kostot e mb\u00ebshtetjes p\u00ebr 4 instanca tashm\u00eb ishin jasht\u00eb \u00e7do kufiri. Lind\u00ebn pyetja p\u00ebr blerjen e Teamcity t\u00eb paguar ose zgjedhja e Jenkins falas. Ne b\u00ebm\u00eb llogaritjet mbi instancat dhe planet p\u00ebr automatizimin dhe vendos\u00ebm se do t\u00eb jetonim me Jenkins. Pas disa jav\u00ebsh, u kaluam n\u00eb Jenkins dhe iu shmang\u00ebm nj\u00eb pjese t\u00eb dhimbjeve t\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 p\u00ebr ne.<\/p>\n

Me rritja e automatizimit baz\u00eb (si\u00e7 \u00ebsht\u00eb krijimi automatik i Pull Request-eve, mbledhja dhe publikimi i Code coverage dhe kontrollimeve t\u00eb tjera) ka sjell\u00eb d\u00ebshir\u00ebn e fort\u00eb p\u00ebr t'u hequr dor\u00eb maksimalisht nga l\u00ebshimet manuale dhe p\u00ebr t'i l\u00ebn\u00eb k\u00ebto pun\u00eb roboteve. P\u00ebrve\u00e7 k\u00ebsaj, brenda kompanis\u00eb ka filluar nj\u00eb trasladim n\u00eb mikrosh\u00ebrbime, t\u00eb cilat k\u00ebrkonin l\u00ebshime t\u00eb shpeshta, madje dhe ndaras nga nj\u00ebra-tjetra. K\u00ebshtu, ne gradualisht arrit\u00ebm n\u00eb l\u00ebshimet automatike t\u00eb mikrosh\u00ebrbimeve tona (monoliti ende e l\u00ebshojm\u00eb manualisht p\u00ebr shkak t\u00eb kompleksitetit t\u00eb procesit). Por, si\u00e7 ndodh zakonisht, u shfaq nj\u00eb v\u00ebshtir\u00ebsi e re.\u00a0<\/p>\n

Po 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\u00ebr shkak t\u00eb anashkalimit t\u00eb disa fazave t\u00eb testimit. Kjo \u00e7oi n\u00eb nj\u00eb humbje t\u00eb p\u00ebrkohshme t\u00eb cil\u00ebsis\u00eb. Duket banal, 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 ndjenj\u00ebn e p\u00ebrgjegj\u00ebsis\u00eb personale (k\u00ebtu flitet p\u00ebr \"pranimin e ideve n\u00eb mendje\", jo p\u00ebr d\u00ebnime financiare) t\u00eb zhvilluesve p\u00ebr kodin q\u00eb l\u00ebshojn\u00eb dhe gabimet n\u00eb t\u00eb, si dhe p\u00ebr nj\u00eb zgjidhje p\u00ebr l\u00ebshimin\/n\u00eb l\u00ebshimin e detyrave n\u00ebp\u00ebrmjet deploy-it automatik.\u00a0<\/p>\n

Duke eliminuar problemet me cil\u00ebsin\u00eb, arrit\u00ebm n\u00eb dy vendime t\u00eb r\u00ebnd\u00ebsishme: filluam t\u00eb kryejm\u00eb testime kanari dhe implementuam monitorim automatik t\u00eb sfondit p\u00ebr gabimet me reagim automatik n\u00ebse ato tejkalonin nj\u00eb nivel t\u00eb caktuar. Vendimi i par\u00eb na lejoji t\u00eb gjejm\u00eb gabimet evidente para se kodi t\u00eb arrinte n\u00eb production, vendimi i dyt\u00eb reduktoi koh\u00ebn e reagimit ndaj problemeve n\u00eb production. Gabimet, sigurisht, ndodhin, por ne shpenzojm\u00eb m\u00eb shum\u00eb koh\u00eb dhe energji p\u00ebr minimizimin e tyre sesa p\u00ebr korrigjimin e tyre.\u00a0<\/p>\n

Ekipi i automatizimit<\/h2>\n

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

DevOps \u00ebsht\u00eb p\u00ebrgjegj\u00ebs p\u00ebr mjediset Dev\/Beta t\u00eb faqes CIAN, mjediset Integro, ndihmon zhvilluesit n\u00eb zgjidhjen e problemeve dhe zhvillon qasje t\u00eb reja p\u00ebr zgjerimin e mjediseve. Drejtimi i zhvillimit Integro merret si me vet\u00eb Integro, ashtu edhe me sh\u00ebrbime t\u00eb lidhura, si\u00e7 jan\u00eb shtesat p\u00ebr Jenkins, Jira, Confluence, dhe gjithashtu zhvillon mjete ndihm\u00ebse dhe aplikacione p\u00ebr ekipet e zhvilluesve.\u00a0<\/p>\n

Ekipi DI punon ngusht\u00eb me ekipin e Platform\u00ebs, i cili merret me zhvillimin e arkitektur\u00ebs, biblioteka dhe qasjes p\u00ebr zhvillim brenda kompanis\u00eb. P\u00ebrve\u00e7 k\u00ebsaj, \u00e7do zhvillues brenda CIAN mund t\u00eb kontribuoj\u00eb n\u00eb automatizim, p\u00ebr shembull, t\u00eb b\u00ebj\u00eb mikro-automatizim sipas nevojave t\u00eb ekipit ose t\u00eb ndaj\u00eb nj\u00eb ide t\u00eb shk\u00eblqyer p\u00ebr t\u00eb p\u00ebrmir\u00ebsuar automatizimin.<\/p>\n

Shtresa 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 shtresa:<\/p>\n

    \n
  1. Sistemet e jashtme (Jira, Bitbucket dhe t\u00eb tjera). Ekipet e zhvillimit punojn\u00eb me to.\n<\/li>\n
  2. Platforma Integro. Zhvilluesit zakonisht nuk punojn\u00eb direkt me t\u00eb, por ajo mb\u00ebshtet funksionimin e gjith\u00eb automatizimit.\n<\/li>\n
  3. Sh\u00ebrbimet e dor\u00ebzimit, orkestrimit dhe zbulimit (p.sh., Jenkins, Consul, Nomad). Me ndihm\u00ebn e tyre ne zhvillojm\u00eb kodin n\u00eb servera dhe sigurojm\u00eb funksionimin e sh\u00ebrbimeve me nj\u00ebri-tjetrin.\n<\/li>\n
  4. Niveli fizik (serverat, OS, softueri p\u00ebrkat\u00ebs). N\u00eb k\u00ebt\u00eb nivel funksionon kodi yn\u00eb. Kjo mund t\u00eb jet\u00eb si nj\u00eb server fizik, ashtu edhe 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\u00ebsis\u00eb brenda ekipit DI. Dy nivelet e para bien n\u00eb p\u00ebrgjegj\u00ebsin\u00eb e drejtimit t\u00eb zhvillimit Integro, nd\u00ebrsa dy nivelet e fundit bie n\u00eb p\u00ebrgjegj\u00ebsin\u00eb e DevOps. Ky ndarje lejon fokusimin n\u00eb detyra dhe nuk pengon bashk\u00ebpunimin, pasi ne jemi af\u00ebr nj\u00ebri-tjetrit dhe vazhdimisht shk\u00ebmbejm\u00eb njohuri dhe p\u00ebrvoj\u00eb.<\/p>\n

    Integro<\/h2>\n

    \nLe t\u00eb fokusojm\u00eb n\u00eb Integro dhe t\u00eb fillojm\u00eb me stakun teknologjik:<\/p>\n