{"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\/da\/blog\/administrirovanie\/ot-skriptov-k-sobstvennoj-platforme-kak-my-avtomatizirovali-razrabotku-v-tsian","title":{"rendered":"Fra scripts til egen platform: hvordan vi automatiserede udviklingen i CIAN","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Fra
\n
\nP\u00e5 RIT 2019 pr\u00e6senterede vores kollega Alexander Korotkov en rapport<\/a><\/noindex> om automatisering af udvikling i CIAN: for at forenkle livet og arbejdet, bruger vi vores egen platform Integro. Den sporer livscyklussen for opgaver, fjerner rutineopgaver fra udviklerne og reducerer betydeligt antallet af fejl i produktionen. I dette indl\u00e6g vil vi supplere Alexanders rapport og fort\u00e6lle, hvordan vi gik fra simple scripts til integration af open source-produkter gennem vores egen platform, og hvad vores dedikerede automatiseringsteam arbejder med.
\n\u00a0<\/a><\/noindex><\/p>\n

Nulniveau<\/h2>\n

\n\u00bbDer findes ikke noget nulniveau, jeg kender ikke til det\u00ab<\/b>
\nMester Shifu fra animationsfilmen \u00abKung Fu Panda\u00bb<\/i><\/p>\n

Automatisering i CIAN begyndte 14 \u00e5r efter virksomhedens grundl\u00e6ggelse. P\u00e5 det tidspunkt var der 35 personer i udviklingsteamet. Det er sv\u00e6rt at tro, ikke? Selvf\u00f8lgelig eksisterede automatisering p\u00e5 en eller anden m\u00e5de, men et s\u00e6rskilt fokus p\u00e5 kontinuerlig integration og levering af kode begyndte f\u00f8rst at tage form i 2015.\u00a0<\/p>\n

P\u00e5 det tidspunkt havde vi en k\u00e6mpe monolit best\u00e5ende af Python, C# og PHP, der var implementeret p\u00e5 Linux-\/Windows-servere. For at deployere dette monster havde vi et s\u00e6t scripts, som vi k\u00f8rte manuelt. Der var ogs\u00e5 opbygningen af monolitten, som medf\u00f8rte smerte og lidelse p\u00e5 grund af konflikter ved sammensmeltning af grene, fejlrettelser og genopbygning med \u00bben anden samling opgaver i builden\u00ab. Forenklet s\u00e5 processen s\u00e5dan ud:<\/p>\n

\"Fra
\n
\nDette tilfredsstillede os ikke, og vi \u00f8nskede at skabe en gentagelig, automatiseret og kontrolleret proces for opbygning og deployment. Til dette havde vi brug for et CI\/CD-system, og vi overvejede mellem den gratis version af Teamcity og den gratis Jenkins, da vi allerede havde arbejdet med dem, og begge opfyldte vores funktionsm\u00e6ssige behov. Vi valgte Teamcity som et mere moderne produkt. P\u00e5 det tidspunkt brugte vi endnu ikke mikroservicearkitektur og forventede ikke et stort antal opgaver og projekter.<\/p>\n

Vi n\u00e5r frem til ideen om vores eget system<\/h2>\n

\nImplementeringen af Teamcity fjernede kun en del af det manuelle arbejde: der var stadig behov for at oprette Pull Requests, fremme opgaver gennem statusser i Jira og v\u00e6lge opgaver til releaser. Dette var noget, Teamcity-systemet ikke kunne h\u00e5ndtere. Vi skulle v\u00e6lge vejen for yderligere automatisering. Vi overvejede at arbejde med scripts i Teamcity eller skifte til eksterne automatiseringssystemer. Men i sidste ende besluttede vi, at vi havde brug for den maksimale fleksibilitet, som kun en egen l\u00f8sning kan give. S\u00e5ledes opstod den f\u00f8rste version af vores interne automatiseringssystem kaldet Integro.<\/p>\n

Teamcity besk\u00e6ftiger sig med automatisering p\u00e5 niveauet til start af bygge- og deploy-processer, mens Integro fokuserede p\u00e5 overordnet automatisering af udviklingsprocesser. Det var n\u00f8dvendigt at kombinere arbejdet med opgaver i Jira med behandlingen af den relaterede kildekode i Bitbucket. P\u00e5 dette tidspunkt begyndte Integro at udvikle sine egne workflows til h\u00e5ndtering af opgaver af forskellige typer.\u00a0<\/p>\n

P\u00e5 grund af den stigende automatisering i forretningsprocesserne er antallet af projekter og runs i Teamcity steget. Her opstod et nyt problem: \u00e9n gratis instans af Teamcity var ikke l\u00e6ngere tilstr\u00e6kkelig (3 agenter og 100 projekter), vi tilf\u00f8jede endnu en instans (yderligere 3 agenter og 100 projekter), og derefter endnu en. I sidste ende endte vi med et system best\u00e5ende af flere klynger, som var sv\u00e6re at administrere:<\/p>\n

\"Fra
\n
\nDa sp\u00f8rgsm\u00e5let om en fjerde instans opstod, inds\u00e5 vi, at det ikke kunne forts\u00e6tte s\u00e5dan, da de samlede omkostninger ved at underst\u00f8tte 4 instanser ikke l\u00e6ngere kunne forsvares. Der opstod sp\u00f8rgsm\u00e5let om at k\u00f8be en betalt version af Teamcity eller v\u00e6lge den gratis Jenkins. Vi lavede beregninger vedr\u00f8rende instanser og automatiseringsplaner og besluttede, at vi ville overg\u00e5 til Jenkins. Efter et par uger skiftede vi til Jenkins og slap for en del af hovedpinen i forbindelse med underst\u00f8ttelsen af flere instanser af Teamcity. P\u00e5 den m\u00e5de kunne vi fokusere p\u00e5 udviklingen af Integro og tilpasningen af Jenkins til vores behov.<\/p>\n

Med stigningen i grundl\u00e6ggende automatisering (i form af automatisk oprettelse af Pull Requests, indsamling og publicering af Code coverage og andre kontroller) opstod der et st\u00e6rkt \u00f8nske om at maksimere afgivelsen fra manuelle udgivelser og overlade dette arbejde til robotter. Derudover begyndte virksomheden at flytte til mikrotjenester, som kr\u00e6vede hyppige udgivelser, der blev udf\u00f8rt separat fra hinanden. P\u00e5 denne m\u00e5de kom vi gradvist til automatiserede udgivelser af vores mikrotjenester (monolitten udgiver vi stadig manuelt p\u00e5 grund af kompleksiteten i processen). Men som det ofte sker, opstod der en ny udfordring.\u00a0<\/p>\n

Vi automatiserer testning<\/h2>\n

\n\"Fra
\n
\nP\u00e5 grund af automatiseringen af udgivelser er udviklingsprocesserne blevet hurtigere, delvist p\u00e5 bekostning af at springe nogle testfaser over. Dette har f\u00f8rt til midlertidigt tab af kvalitet. Det lyder banalt, men sammen med accelerationen af udgivelserne var det n\u00f8dvendigt ogs\u00e5 at \u00e6ndre produktudviklingsmetodologien. Vi skulle overveje automatisering af testning, indf\u00f8re personlig ansvarlighed (her taler vi om \"at tage ideen til sig\", ikke \u00f8konomiske b\u00f8der) for udviklerne for den kode, de udgiver, og fejlene i den, samt tage beslutning om udgivelse\/ikke udgivelse af opgaver gennem automatisk deployment.\u00a0<\/p>\n

Ved at l\u00f8se kvalitetsproblemerne kom vi til to vigtige beslutninger: vi begyndte at udf\u00f8re kanarietestning og implementerede automatisk overv\u00e5gning af baggrundsfejl med automatisk respons ved overskridelser. Den f\u00f8rste beslutning gjorde det muligt at finde \u00e5benlyse fejl, f\u00f8r koden reelt kom i produktion, mens den anden reducerede responstiden p\u00e5 problemer i produktion. Der opst\u00e5r selvf\u00f8lgelig fejl, men vi bruger det meste af tiden og ressourcerne ikke p\u00e5 at rette dem, men p\u00e5 at minimere dem.\u00a0<\/p>\n

Automatiseringsteamet<\/h2>\n

\nVi har nu et team p\u00e5 130 udviklere, og vi forts\u00e6tter med at vokse<\/a><\/noindex>. Teamet for kontinuerlig integration og levering af kode (herefter kaldet Deploy and Integration eller DI-teamet) best\u00e5r af 7 personer og arbejder inden for 2 omr\u00e5der: udvikling af automatiseringsplatformen Integro og DevOps.\u00a0<\/p>\n

DevOps er ansvarlig for Dev\/Beta-milj\u00f8er af CIAN-webstedet, Integro-milj\u00f8er, hj\u00e6lper udviklerne med at l\u00f8se problemer og udvikler nye tilgange til skalering af milj\u00f8er. Integro udviklingsretning arbejder b\u00e5de med Integro selv og med tilknyttede tjenester, s\u00e5som plugins til Jenkins, Jira, Confluence, og udvikler ogs\u00e5 nyttige v\u00e6rkt\u00f8jer og applikationer til udviklerteams.\u00a0<\/p>\n

DI-teamet arbejder sammen med Platform-teamet, der er ansvarlig for udviklingen af arkitektur, biblioteker og udviklingstilgange inden for virksomheden. Derudover kan enhver udvikler inden for CIAN bidrage til automatiseringen, for eksempel ved at lave mikroautomatisering til teamets behov eller dele et godt id\u00e9 om, hvordan man kan g\u00f8re automatiseringen endnu bedre.<\/p>\n

Lagkage af automatisering i CIAN<\/h2>\n

\n\"Fra
\n
\nAlle systemer involveret i automatiseringen kan opdeles i flere lag:<\/p>\n

    \n
  1. Eksterne systemer (Jira, Bitbucket osv.). Disse bruges af udviklerteamene.\n<\/li>\n
  2. Integro-platformen. Oftest arbejder udviklerne ikke direkte med den, men det er den, der underst\u00f8tter hele automatiseringen.\n<\/li>\n
  3. Leveringstjenester, orkestrering og opdagelse (for eksempel Jenkins, Consul, Nomad). Ved hj\u00e6lp af dem implementerer vi kode p\u00e5 serverne og sikrer, at tjenesterne fungerer sammen.\n<\/li>\n
  4. Det fysiske niveau (servere, OS, ledsagende software). P\u00e5 dette niveau k\u00f8rer vores kode. Det kan v\u00e6re b\u00e5de en fysisk server og en virtuel (LXC, KVM, Docker).\n<\/li>\n<\/ol>\n

    \nBaseret p\u00e5 dette koncept deler vi ansvarsomr\u00e5derne inden for DI-teamet. De to f\u00f8rste lag falder ind under Integro udviklingsretning, mens de to sidste lag er under DevOps. Denne opdeling muligg\u00f8r fokus p\u00e5 opgaver og forstyrrer ikke samarbejdet, da vi er t\u00e6t p\u00e5 hinanden og konstant deler viden og erfaring.<\/p>\n

    Integro<\/h2>\n

    \nLad os fokusere p\u00e5 Integro og starte med teknologistakken:<\/p>\n