{"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\/ro\/blog\/administrirovanie\/ot-skriptov-k-sobstvennoj-platforme-kak-my-avtomatizirovali-razrabotku-v-tsian","title":{"rendered":"De la scripturi la propria platform\u0103: cum am automatizat dezvoltarea \u00een CIAN","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"De
\n
\nLa RIT 2019, colegul nostru Alexandr Korotkov a discutat raport<\/a><\/noindex> despre automatizarea dezvolt\u0103rii la CIAN: pentru a simplifica via\u021ba \u0219i munca, folosim propria noastr\u0103 platform\u0103 Integro. Aceasta urm\u0103re\u0219te ciclul de via\u021b\u0103 al sarcinilor, \u00eendep\u0103rteaz\u0103 sarcinile repetitive de la dezvoltatori \u0219i reduce semnificativ num\u0103rul de bug-uri \u00een produc\u021bie. \u00cen aceast\u0103 postare, vom completa prezentarea lui Alexandr \u0219i vom \u00eemp\u0103rt\u0103\u0219i cum am evoluat de la scripturi simple la integrarea produselor open source prin propria noastr\u0103 platform\u0103 \u0219i cu ce se ocup\u0103 o echip\u0103 separat\u0103 de automatizare.
\n\u00a0<\/a><\/noindex><\/p>\n

Nivelul zero<\/h2>\n

\n\u201eNu exist\u0103 nivel zero, nu \u0219tiu a\u0219a ceva\u201d<\/b>
\nMister Shifu din m\/f \u201eKung Fu Panda\u201d<\/i><\/p>\n

Automatizarea la CIAN a \u00eenceput la 14 ani dup\u0103 \u00eenfiin\u021barea companiei. Atunci, echipa de dezvoltare num\u0103ra 35 de persoane. E greu de crezut, nu? Desigur, \u00eentr-o form\u0103 oarecare, automatizarea exista, dar un domeniu separat pentru integrarea continu\u0103 \u0219i livrarea codului a \u00eenceput s\u0103 se contureze exact \u00een anul 2015.\u00a0<\/p>\n

La acel moment, aveam un monolit uria\u0219 din Python, C# \u0219i PHP, desf\u0103\u0219urat pe servere Linux\/Windows. Pentru a desf\u0103\u0219ura acest monstru, aveam un set de scripturi pe care le rulam manual. Mai exista \u0219i construc\u021bia monolitului, care provoca dureri \u0219i suferin\u021be din cauza conflictelor la unirea ramurilor, corect\u0103rii defectelor \u0219i reconstruc\u0103rii \u201ecu un alt set de sarcini \u00een build\u201d. Simplificat, procesul ar\u0103ta astfel:<\/p>\n

\"De
\n
\nNu eram mul\u021bumi\u021bi de asta \u0219i voiam s\u0103 construim un proces de construc\u021bie \u0219i desf\u0103\u0219urare repetabil, automatizat \u0219i gestionat. Pentru aceasta, aveam nevoie de un sistem CI\/CD, \u0219i am ales \u00eentre versiunea gratuit\u0103 Teamcity \u0219i Jenkins gratuit, deoarece lucrasem cu ambele \u0219i ne satisf\u0103ceau prin setul de func\u021bii. Am ales Teamcity ca produs mai nou. Atunci nu foloseam arhitectur\u0103 de microservicii \u0219i nu ne a\u0219teptam la un num\u0103r mare de sarcini \u0219i proiecte.<\/p>\n

Ajungem la ideea despre propriul sistem<\/h2>\n

\nImplementarea Teamcity a redus doar o parte din munca manual\u0103: a r\u0103mas \u00eenc\u0103 necesar s\u0103 se creeze Pull Request-uri, s\u0103 se promoveze sarcinile prin statusuri \u00een Jira, s\u0103 se aleag\u0103 sarcinile pentru lansare. Cu acest lucru, sistemul Teamcity nu mai reu\u0219ea. Trebuia s\u0103 alegem calea unei automatiz\u0103ri suplimentare. Am luat \u00een considerare op\u021biuni de lucru cu scripturi \u00een Teamcity sau tranzi\u021bia la sisteme externe de automatizare. Dar, \u00een cele din urm\u0103, am decis c\u0103 avem nevoie de cea mai mare flexibilitate, pe care o ofer\u0103 doar o solu\u021bie proprie. A\u0219a a ap\u0103rut prima versiune a sistemului nostru intern de automatizare numit Integro.<\/p>\n

Teamcity se ocup\u0103 cu automatizarea la nivelul lans\u0103rii proceselor de construire \u0219i implementare, \u00een timp ce Integro s-a concentrat pe automatizarea la un nivel superior a proceselor de dezvoltare. A fost necesar s\u0103 combin\u0103m lucrul cu sarcinile din Jira cu procesarea codului surs\u0103 asociat \u00een Bitbucket. \u00cen acest stadiu, \u00een interiorul Integro au \u00eenceput s\u0103 apar\u0103 fluxuri de lucru proprii pentru gestionarea sarcinilor de diferite tipuri.\u00a0<\/p>\n

Datorit\u0103 cre\u0219terii automatiz\u0103rii \u00een procesele de business, num\u0103rul de proiecte \u0219i run-uri \u00een Teamcity a crescut. A\u0219a a ap\u0103rut o nou\u0103 problem\u0103: un singur instan\u021b gratuit de Teamcity nu mai era suficient (3 agen\u021bi \u0219i 100 de proiecte), am ad\u0103ugat \u00eenc\u0103 un instan\u021b (\u00eenc\u0103 3 agen\u021bi \u0219i 100 de proiecte), apoi \u00eenc\u0103 unul. \u00cen final, am ob\u021binut un sistem format din mai multe clustere, pe care era dificil s\u0103 \u00eel gestion\u0103m:<\/p>\n

\"De
\n
\nC\u00e2nd a ap\u0103rut \u00eentrebarea despre al patrulea instan\u021b, am realizat c\u0103 nu mai putem continua astfel, deoarece costurile totale pentru sus\u021binerea a patru instan\u021be dep\u0103\u0219eau orice limit\u0103. A ap\u0103rut \u00eentrebarea achizi\u021bion\u0103rii unui Teamcity pl\u0103tit sau alegerea unei solu\u021bii gratuite Jenkins. Am realizat calculele pentru instan\u021be \u0219i planurile de automatizare \u0219i am decis c\u0103 vom continua pe Jenkins. Dup\u0103 c\u00e2teva s\u0103pt\u0103m\u00e2ni, am trecut pe Jenkins \u0219i ne-am eliberat de o parte din durerea de cap legat\u0103 de gestionarea mai multor instan\u021be Teamcity. A\u0219adar, am putut s\u0103 ne concentr\u0103m pe dezvoltarea Integro \u0219i adaptarea Jenkins pentru nevoile noastre.<\/p>\n

Odat\u0103 cu cre\u0219terea automatiz\u0103rii de baz\u0103 (sub forma cre\u0103rii automate de Pull Request-uri, colect\u0103rii \u0219i public\u0103rii acoperirii codului \u0219i altor verific\u0103ri) a ap\u0103rut o dorin\u021b\u0103 persistent\u0103 de a renun\u021ba la lans\u0103rile manuale \u0219i de a l\u0103sa aceast\u0103 munc\u0103 robo\u021bilor. Pe l\u00e2ng\u0103 asta, \u00een interiorul companiei a \u00eenceput o migrare c\u0103tre microservicii, care necesitau lans\u0103ri frecvente, separate unele de altele. Astfel, am ajuns treptat la lans\u0103ri automate ale microserviciilor noastre (monolitul este \u00eenc\u0103 lansat manual din cauza complexit\u0103\u021bii procesului). Dar, a\u0219a cum se \u00eent\u00e2mpl\u0103 de obicei, a ap\u0103rut o nou\u0103 dificultate.\u00a0<\/p>\n

Automatiz\u0103m testarea<\/h2>\n

\n\"De
\n
\nDatorit\u0103 automatiz\u0103rii lans\u0103rilor, procesele de dezvoltare s-au accelerat, par\u021bial \u0219i prin omisiunea unor etape de testare. Iar aceasta a dus la o pierdere temporar\u0103 a calit\u0103\u021bii. Sun\u0103 banal, dar \u00eempreun\u0103 cu accelerarea lans\u0103rilor, a fost necesar s\u0103 schimb\u0103m \u0219i metodologia de dezvoltare a produsului. A fost nevoie s\u0103 ne g\u00e2ndim la automatizarea test\u0103rii, la promovarea responsabilit\u0103\u021bii personale (aici se vorbe\u0219te despre \"asumarea ideii \u00een minte\", nu despre amenzi financiare) a dezvoltatorului pentru codul livrat \u0219i erorile din acesta, precum \u0219i la o decizie privind livrarea\/nerularea sarcinii prin intermediul unui deploy automatizat.\u00a0<\/p>\n

Elimin\u00e2nd problemele legate de calitate, am ajuns la dou\u0103 solu\u021bii importante: am \u00eenceput s\u0103 desf\u0103\u0219ur\u0103m teste canarie \u0219i am implementat monitorizarea automat\u0103 a erorilor cu reac\u021bie automat\u0103 la dep\u0103\u0219irea acestora. Prima solu\u021bie a permis identificarea erorilor evidente \u00eenainte de a ajunge codul \u00een produc\u021bie, iar a doua a redus timpul de reac\u021bie la problemele din produc\u021bie. Erorile, desigur, exist\u0103, dar cheltuim mai mult timp \u0219i efort nu pe corectare, ci pe minimizare.\u00a0<\/p>\n

Echipa de automatizare<\/h2>\n

\n\u00cen prezent, avem un personal de 130 de dezvoltatori \u0219i continu\u0103m s\u0103 cre\u0219tem<\/a><\/noindex>. Echipa de integrare \u0219i livrare continu\u0103 a codului (\u00een continuare \u2013 echipa Deploy and Integration sau DI) este format\u0103 din 7 persoane \u0219i lucreaz\u0103 \u00een 2 direc\u021bii: dezvoltarea platformei de automatizare Integro \u0219i DevOps.\u00a0<\/p>\n

DevOps este responsabil pentru mediile Dev\/Beta ale site-ului CIAN, pentru mediu Integro, ajut\u00e2nd dezvoltatorii s\u0103 rezolve probleme \u0219i dezvolt\u00e2nd noi abord\u0103ri pentru scalarea mediilor. Direc\u021bia de dezvoltare Integro se ocup\u0103 at\u00e2t de Integro \u00een sine, c\u00e2t \u0219i de servicii conexe, cum ar fi pluginuri pentru Jenkins, Jira, Confluence, precum \u0219i dezvoltarea de utilitare \u0219i aplica\u021bii auxiliare pentru echipele de dezvoltare.\u00a0<\/p>\n

Echipa DI colaboreaz\u0103 cu echipa Platformei, care se ocup\u0103 de dezvoltarea arhitecturii, bibliotecilor \u0219i abord\u0103rilor de dezvoltare \u00een cadrul companiei. \u00cen plus, orice dezvoltator din cadrul CIAN poate contribui la automatizare, de exemplu, realiz\u00e2nd micro-automatiz\u0103ri pentru nevoile echipei sau \u00eemp\u0103rt\u0103\u0219ind idei interesante pentru a \u00eembun\u0103t\u0103\u021bi automatizarea.<\/p>\n

Pachetul stratificat de automatizare la CIAN<\/h2>\n

\n\"De
\n
\nToate sistemele implicate \u00een automatizare pot fi \u00eemp\u0103r\u021bite \u00een mai multe straturi:<\/p>\n

    \n
  1. Sisteme externe (Jira, Bitbucket etc.). Acestea sunt utilizate de echipele de dezvoltare.\n<\/li>\n
  2. Platforma Integro. Cel mai adesea dezvoltatorii nu interac\u021bioneaz\u0103 direct cu aceasta, dar ea sus\u021bine func\u021bionarea \u00eentregii automatiz\u0103ri.\n<\/li>\n
  3. Servicii de livrare, orchestrare \u0219i detectare (cum ar fi Jenkins, Consul, Nomad). Cu ajutorul lor desf\u0103\u0219ur\u0103m codul pe servere \u0219i asigur\u0103m comunicarea serviciilor \u00eentre ele.\n<\/li>\n
  4. Nivelul fizic (servere, SO, software conex). Pe acest nivel ruleaz\u0103 codul nostru. Poate fi at\u00e2t un server fizic, c\u00e2t \u0219i unul virtual (LXC, KVM, Docker).\n<\/li>\n<\/ol>\n

    \nPe baza acestei concep\u021bii, \u00eemp\u0103r\u021bim zonele de responsabilitate \u00een cadrul echipei DI. Primele dou\u0103 niveluri se afl\u0103 \u00een responsabilitatea direc\u021biei de dezvoltare Integro, iar ultimele dou\u0103 \u00een responsabilitatea DevOps. Aceast\u0103 \u00eemp\u0103r\u021bire permite concentrarea asupra sarcinilor \u0219i nu \u00eempiedic\u0103 interac\u021biunea, deoarece suntem aproape unul de cel\u0103lalt \u0219i schimb\u0103m constant cuno\u0219tin\u021be \u0219i experien\u021be.<\/p>\n

    Integro<\/h2>\n

    \nS\u0103 ne concentr\u0103m asupra Integro \u0219i s\u0103 \u00eencepem cu tehnologia utilizat\u0103:<\/p>\n