{"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\/sk\/blog\/administrirovanie\/ot-skriptov-k-sobstvennoj-platforme-kak-my-avtomatizirovali-razrabotku-v-tsian","title":{"rendered":"Od skriptov k vlastnej platforme: ako sme automatizovali v\u00fdvoj v CIAN","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Od
\n
\nNa RIT 2019 n\u00e1\u0161 kolega Alexander Korotkov predstavil predn\u00e1\u0161ka<\/a><\/noindex> o automatiz\u00e1cii v\u00fdvoja v CIAN: na zjednodu\u0161enie \u017eivota a pr\u00e1ce pou\u017e\u00edvame vlastn\u00fa platformu Integro. T\u00e1to platforma sleduje \u017eivotn\u00fd cyklus \u00faloh, zbavuje v\u00fdvoj\u00e1rov rutinn\u00fdch oper\u00e1ci\u00ed a v\u00fdrazne zni\u017euje po\u010det ch\u00fdb v produkcii. V tomto pr\u00edspevku dopln\u00edme Alexanderovu predn\u00e1\u0161ku a povieme, ako sme pre\u0161li od jednoduch\u00fdch skriptov k integr\u00e1cii open source produktov cez vlastn\u00fa platformu a \u010domu sa venuje n\u00e1\u0161 samostatn\u00fd t\u00edm automatiz\u00e1cie.
\n\u00a0<\/a><\/noindex><\/p>\n

Nulov\u00e1 \u00farove\u0148<\/h2>\n

\n\u201eNulov\u00e1 \u00farove\u0148 neexistuje, nie\u010do tak\u00e9 nepozn\u00e1m\u201c<\/b>
\nMajster Shifu z m\/f \u201eKung-fu Panda\u201c<\/i><\/p>\n

Automatiz\u00e1cia v CIAN za\u010dala 14 rokov po zalo\u017een\u00ed spolo\u010dnosti. Vtedy bola v v\u00fdvojovom t\u00edme 35 \u010dlenov. \u0164a\u017eko tomu uveri\u0165, v\u0161ak? Samozrejme, nejak\u00e1 forma automatiz\u00e1cie u\u017e existovala, ale samostatn\u00e1 oblas\u0165 nepretr\u017eitej integr\u00e1cie a dod\u00e1vky k\u00f3du sa za\u010dala formova\u0165 pr\u00e1ve v roku 2015.\u00a0<\/p>\n

Vtedy sme mali obrovsk\u00fd monolit z Pythonu, C# a PHP, nasaden\u00fd na Linux\/Windows serveroch. Na nasadenie tohto mon\u0161tra sme mali sadu skriptov, ktor\u00e9 sme sp\u00fa\u0161\u0165ali manu\u00e1lne. Bolo tu tie\u017e zostavovanie monolitu, sp\u00f4sobuj\u00face boles\u0165 a utrpenie kv\u00f4li konfliktom pri zl\u00fa\u010den\u00ed vetiev, oprav\u00e1m defektov a op\u00e4tovn\u00e9mu zostavovaniu \u201es inou sadou \u00faloh v zostave\u201c. Zjednodu\u0161ene proces vyzeral takto:<\/p>\n

\"Od
\n
\nTo n\u00e1m nevyhovovalo a chceli sme vybudova\u0165 opakovate\u013en\u00fd, automatizovan\u00fd a kontrolovan\u00fd proces zostavovania a nasadenia. Na to sme potrebovali syst\u00e9m CI\/CD a vyberali sme medzi bezplatnou verziou Teamcity a bezplatn\u00fdm Jenkins, preto\u017ee sme s nimi pracovali a obidve sp\u013a\u0148ali na\u0161e po\u017eiadavky. Vybrali sme Teamcity ako modernej\u0161\u00ed produkt. Vtedy sme e\u0161te nepou\u017e\u00edvali mikroslu\u017ebov\u00fa architekt\u00faru a nepl\u00e1novali sme mno\u017estvo \u00faloh a projektov.<\/p>\n

Dost\u00e1vame sa k my\u0161lienke o vlastnom syst\u00e9me<\/h2>\n

\nImplement\u00e1cia Teamcity odstr\u00e1nila len \u010das\u0165 manu\u00e1lnej pr\u00e1ce: zostalo e\u0161te vytv\u00e1ranie Pull Requestov, presun \u00faloh pod\u013ea stavov v Jira, v\u00fdber \u00faloh na uvo\u013enenie. S t\u00fdmto syst\u00e9mom Teamcity u\u017e nespolupracoval. Bolo potrebn\u00e9 zvoli\u0165 cestu \u010fal\u0161ej automatiz\u00e1cie. Zv\u00e1\u017eili sme mo\u017enosti pr\u00e1ce so skriptmi v Teamcity alebo prechod na extern\u00e9 automatiza\u010dn\u00e9 syst\u00e9my. Nakoniec sme sa rozhodli, \u017ee potrebujeme maxim\u00e1lnu flexibilitu, ktor\u00fa poskytuje len vlastn\u00e9 rie\u0161enie. Tak vznikla prv\u00e1 verzia vn\u00fatorn\u00e9ho automatiza\u010dn\u00e9ho syst\u00e9mu s n\u00e1zvom Integro.<\/p>\n

Teamcity sa zaober\u00e1 automatiz\u00e1ciou na \u00farovni sp\u00fa\u0161\u0165ania procesov kompil\u00e1cie a nasadenia, zatia\u013e \u010do Integro sa zameralo na vy\u0161\u0161iu \u00farove\u0148 automatiz\u00e1cie vyvojov\u00fdch procesov. Bolo potrebn\u00e9 zl\u00fa\u010di\u0165 pr\u00e1cu s \u00falohami v Jira s spracovan\u00edm s\u00favisiaceho zdrojov\u00e9ho k\u00f3du v Bitbucket. V tejto f\u00e1ze za\u010dali v Integro vznikn\u00fa\u0165 vlastn\u00e9 workflow pre pr\u00e1cu s r\u00f4znymi typmi \u00faloh.\u00a0<\/p>\n

V d\u00f4sledku zvy\u0161ovania automatiz\u00e1cie v obchodn\u00fdch procesoch vzr\u00e1stol po\u010det projektov a runov v Teamcity. Tak pri\u0161la nov\u00e1 probl\u00e9m: jedno bezplatn\u00e9 in\u0161tan\u010dn\u00e9 Teamcity u\u017e nesta\u010dilo (3 agenti a 100 projektov), pridali sme \u010fal\u0161ie in\u0161tancie (\u010fal\u0161ie 3 agenti a 100 projektov), nesk\u00f4r \u010fal\u0161ie. Nakoniec sme dostali syst\u00e9m z nieko\u013ek\u00fdch klastrov, ktor\u00fdm bolo \u0165a\u017ek\u00e9 spravova\u0165:<\/p>\n

\"Od
\n
\nKe\u010f nastala ot\u00e1zka o 4. in\u0161tancii, pochopili sme, \u017ee takto u\u017e nem\u00f4\u017eeme \u017ei\u0165, preto\u017ee s\u00fahrnn\u00e9 n\u00e1klady na \u00fadr\u017ebu 4 in\u0161tanci\u00ed u\u017e neboli prijate\u013en\u00e9. Vznikla ot\u00e1zka n\u00e1kupu platen\u00e9ho Teamcity alebo vo\u013eby v prospech bezplatnej Jenkins. Urobili sme v\u00fdpo\u010dty pre in\u0161tancie a pl\u00e1ny na automatiz\u00e1ciu a rozhodli sme sa, \u017ee prejdeme na Jenkins. Po p\u00e1r t\u00fd\u017ed\u0148och sme pre\u0161li na Jenkins a zbavili sa \u010dasti bolesti hlavy spojen\u00e9 so spr\u00e1vou nieko\u013ek\u00fdch in\u0161tanci\u00ed Teamcity. Tak sme sa mohli s\u00fastredi\u0165 na v\u00fdvoj Integro a \u00fapravy Jenkins pre na\u0161e potreby.<\/p>\n

S rastom z\u00e1kladnej automatiz\u00e1cie (vo forme automatick\u00e9ho vytv\u00e1rania Pull Request-ov, zberu a publikovania Code coverage a in\u00fdch kontrol) sa objavil trval\u00fd z\u00e1ujem maxim\u00e1lne sa vzda\u0165 ru\u010dn\u00fdch release-ov a zveri\u0165 t\u00fato pr\u00e1cu robotom. Okrem toho sa vo vn\u00fatri spolo\u010dnosti za\u010dalo s presunom na mikroservisy, ktor\u00e9 si vy\u017eadovali \u010dast\u00e9 release-y, pri\u010dom ka\u017ed\u00fd samostatne. Tak sme postupne pri\u0161li k automatick\u00fdm release-om na\u0161ich mikroservisov (monolit zatia\u013e vyd\u00e1vame ru\u010dne kv\u00f4li zlo\u017eitosti procesu). Ale, ako to u\u017e b\u00fdva, objavila sa nov\u00e1 zlo\u017eitost.\u00a0<\/p>\n

Automatizujeme testovanie<\/h2>\n

\n\"Od
\n
\nV\u010faka automatiz\u00e1cii release-ov sa procesy v\u00fdvoja ur\u00fdchlili, pri\u010dom \u010diasto\u010dne na \u00fakor presko\u010denia niektor\u00fdch f\u00e1z testovania. To viedlo k do\u010dasnej strate kvality. Znie to ban\u00e1lne, ale spolu s ur\u00fdchlen\u00edm release-ov bolo potrebn\u00e9 zmeni\u0165 aj metodol\u00f3giu v\u00fdvoja produktu. Museli sme uva\u017eova\u0165 o automatiz\u00e1cii testovania, prerozde\u013eovan\u00ed osobnej zodpovednosti (tu ide o 'prijatie my\u0161lienky v hlave', a nie o finan\u010dn\u00e9 pokuty) v\u00fdvoj\u00e1ra za vydan\u00fd k\u00f3d a chyby v \u0148om, ako aj o rozhodnut\u00ed o vydan\u00ed\/ne vydan\u00ed \u00falohy prostredn\u00edctvom automatick\u00e9ho nasadenia.\u00a0<\/p>\n

Rie\u0161en\u00edm probl\u00e9mov s kvalitou sme dospeli k dvom d\u00f4le\u017eit\u00fdm rozhodnutiam: za\u010dali sme vykon\u00e1va\u0165 kan\u00e1rske testovanie a zaviedli sme automatick\u00e9 monitorovanie pozadia ch\u00fdb s automatick\u00fdm reagovan\u00edm na jeho presiahnutie. Prv\u00e9 rozhodnutie umo\u017enilo identifikova\u0165 zjavn\u00e9 chyby predt\u00fdm, ne\u017e sa k\u00f3d dostal do produkcie, druh\u00e9 zn\u00ed\u017eilo \u010das reakcie na probl\u00e9my v produkcii. Chyby sa samozrejme st\u00e1vaj\u00fa, ale v\u00e4\u010d\u0161inu \u010dasu a energie tr\u00e1vime nie na opravovanie, ale na minimaliz\u00e1ciu.\u00a0<\/p>\n

T\u00edm automatiz\u00e1cie<\/h2>\n

\nMoment\u00e1lne m\u00e1me t\u00edm 130 v\u00fdvoj\u00e1rov a pokra\u010dujeme r\u00e1s\u0165<\/a><\/noindex>. T\u00edm pre kontinu\u00e1lnu integr\u00e1ciu a dod\u00e1vku k\u00f3du (\u010falej \u2014 t\u00edm Deploy and Integration alebo DI) pozost\u00e1va zo 7 \u013eud\u00ed a pracuje v 2 smeroch: v\u00fdvoj platformy automatiz\u00e1cie Integro a DevOps.\u00a0<\/p>\n

DevOps zodpoved\u00e1 za Dev\/Beta prostredia webu CIAN, prostredie Integro, pom\u00e1ha v\u00fdvoj\u00e1rom pri rie\u0161en\u00ed probl\u00e9mov a vypracov\u00e1va nov\u00e9 pr\u00edstupy k \u0161k\u00e1lovaniu prostred\u00ed. Oblas\u0165 v\u00fdvoja Integro sa zaober\u00e1 nielen samotn\u00fdm Integro, ale aj pr\u00edbuzn\u00fdmi slu\u017ebami, ako s\u00fa pluginy pre Jenkins, Jira, Confluence, a tie\u017e vyv\u00edja pomocn\u00e9 n\u00e1stroje a aplik\u00e1cie pre t\u00fdmy v\u00fdvoj\u00e1rov.\u00a0<\/p>\n

T\u00edm DI spolupracuje s t\u00edmom Platformy, ktor\u00fd sa zaober\u00e1 v\u00fdvojom architekt\u00fary, kni\u017en\u00edc a pr\u00edstupov k v\u00fdvoju v r\u00e1mci spolo\u010dnosti. Okrem toho m\u00f4\u017ee ka\u017ed\u00fd v\u00fdvoj\u00e1r v CIAN prispie\u0165 k automatiz\u00e1cii, napr\u00edklad vytvoren\u00edm mikroautomatiz\u00e1cie pod\u013ea potrieb t\u00edmu alebo zdie\u013ean\u00edm skvelej my\u0161lienky, ako zlep\u0161i\u0165 automatiz\u00e1ciu.<\/p>\n

Viacvrstvov\u00e1 \u0161trukt\u00fara automatiz\u00e1cie v CIAN<\/h2>\n

\n\"Od
\n
\nV\u0161etky syst\u00e9my zapojen\u00e9 do automatiz\u00e1cie m\u00f4\u017eeme rozdeli\u0165 na nieko\u013eko vrstiev:<\/p>\n

    \n
  1. Extern\u00e9 syst\u00e9my (Jira, Bitbucket a pod.). S nimi pracuj\u00fa v\u00fdvoj\u00e1rske t\u00edmy.\n<\/li>\n
  2. Platforma Integro. V\u00fdvoj\u00e1ri s \u0148ou v\u00e4\u010d\u0161inou nepracuj\u00fa priamo, ale je to pr\u00e1ve ona, ktor\u00e1 podporuje funkciu celej automatiz\u00e1cie.\n<\/li>\n
  3. Slu\u017eby doru\u010dovania, orchestr\u00e1cie a zistovania (napr\u00edklad Jenkins, Consul, Nomad). S ich pomocou nasadzujeme k\u00f3d na serveroch a zabezpe\u010dujeme vz\u00e1jomn\u00fa interakciu slu\u017eieb.\n<\/li>\n
  4. Fyzick\u00e1 \u00farove\u0148 (servery, OS, pr\u00edbuzn\u00fd softv\u00e9r). Na tejto \u00farovni be\u017e\u00ed n\u00e1\u0161 k\u00f3d. M\u00f4\u017ee to by\u0165 fyzick\u00fd server alebo virtu\u00e1lny (LXC, KVM, Docker).\n<\/li>\n<\/ol>\n

    \nNa z\u00e1klade tejto koncepcie del\u00edme z\u00f3ny zodpovednosti v r\u00e1mci t\u00edmu DI. Dve prv\u00e9 \u00farovne spadaj\u00fa pod zodpovednos\u0165 oblasti v\u00fdvoja Integro, zatia\u013e \u010do dve posledn\u00e9 \u00farovne spadaj\u00fa pod zodpovednos\u0165 DevOps. Tak\u00e9to rozdelenie umo\u017e\u0148uje s\u00fastredi\u0165 sa na \u00falohy a nebr\u00e1ni interakcii, preto\u017ee sme bl\u00edzko seba a neust\u00e1le si vymie\u0148ame znalosti a sk\u00fasenosti.<\/p>\n

    Integro<\/h2>\n

    \nZamerajme sa na Integro a za\u010dneme technologick\u00fdm z\u00e1sobn\u00edkom:<\/p>\n