Van skrifte tot ons eie platform: hoe ons ontwikkeling by CIAN geoutomatiseer het

By RIT 2019 het ons kollega Alexander Korotkov gemaak die verslag oor outomatisering van ontwikkeling by CIAN: om lewe en werk te vereenvoudig, gebruik ons ​​ons eie Integro-platform. Dit volg die lewensiklus van take, verlig ontwikkelaars van roetine-bedrywighede en verminder die aantal foute in produksie aansienlik. In hierdie pos sal ons Alexander se verslag aanvul en jou vertel hoe ons gegaan het van eenvoudige skrifte na die kombinasie van oopbronprodukte deur ons eie platform en wat ons aparte outomatiseringspan doen.
 

Nul vlak

"Daar is nie iets soos 'n nulvlak nie, ek weet nie so iets nie"
Meester Shifu van die film "Kung Fu Panda"

Outomatisering by CIAN het begin 14 jaar nadat die maatskappy gestig is. Op daardie stadium was daar 35 mense in die ontwikkelingspan. Moeilik om te glo, reg? Natuurlik het outomatisering wel in een of ander vorm bestaan, maar 'n aparte rigting vir deurlopende integrasie en kodelewering het in 2015 begin vorm aanneem. 

Op daardie tydstip het ons 'n groot monoliet van Python, C# en PHP gehad wat op Linux/Windows-bedieners ontplooi is. Om hierdie monster te ontplooi, het ons 'n stel skrifte gehad wat ons met die hand laat loop het. Daar was ook die samestelling van die monoliet, wat pyn en lyding gebring het as gevolg van konflikte wanneer takke saamgevoeg word, defekte reggestel en herbou word "met 'n ander stel take in die bou." 'n Vereenvoudigde proses het soos volg gelyk:

Ons was nie tevrede hiermee nie, en ons wou 'n herhaalbare, outomatiese en hanteerbare bou- en ontplooiingsproses bou. Hiervoor het ons 'n CI/CD-stelsel nodig gehad, en ons het gekies tussen die gratis weergawe van Teamcity en die gratis weergawe van Jenkins, aangesien ons met hulle gewerk het en albei ons gepas het in terme van die stel funksies. Ons het Teamcity as 'n meer onlangse produk gekies. Op daardie stadium het ons nog nie mikrodiensargitektuur gebruik nie en het nie 'n groot aantal take en projekte verwag nie.

Ons kom by die idee van ons eie stelsel

Die implementering van Teamcity het slegs 'n deel van die handwerk verwyder: wat oorbly, is die skep van Pull Requests, bevordering van kwessies volgens status in Jira, en keuse van kwessies vir vrystelling. Die Teamcity-stelsel kon dit nie meer hanteer nie. Dit was nodig om die pad van verdere outomatisering te kies. Ons het opsies oorweeg om met skrifte in Teamcity te werk of na derdeparty-outomatiseringstelsels oor te skakel. Maar op die ou end het ons besluit dat ons maksimum buigsaamheid nodig het, wat net ons eie oplossing kan bied. Dit is hoe die eerste weergawe van die interne outomatiseringstelsel genaamd Integro verskyn het.

Teamcity handel oor outomatisering op die vlak van die bekendstelling van die bou- en ontplooiingsprosesse, terwyl Integro gefokus het op topvlak-outomatisering van ontwikkelingsprosesse. Dit was nodig om werk met kwessies in Jira te kombineer met verwerking van gepaardgaande bronkode in Bitbucket. In hierdie stadium het Integro sy eie werkvloeie begin hê om met take van verskillende tipes te werk. 

As gevolg van die toename in outomatisering in besigheidsprosesse, het die aantal projekte en lopies in Teamcity toegeneem. So 'n nuwe probleem het gekom: een gratis Teamcity-instansie was nie genoeg nie (3 agente en 100 projekte), ons het nog 'n instansie bygevoeg (nog 3 agente en 100 projekte), dan nog een. Gevolglik het ons met 'n stelsel van verskeie groepe beland, wat moeilik was om te bestuur:

Toe die kwessie van 'n 4de instansie opduik, het ons besef dat ons nie so kan bly leef nie, want die totale koste om 4 instansies te ondersteun was nie meer binne enige perke nie. Die vraag het ontstaan ​​oor die aankoop van betaalde Teamcity of die keuse van gratis Jenkins. Ons het berekeninge oor gevalle en outomatiseringsplanne gemaak en besluit dat ons op Jenkins sal woon. Na 'n paar weke het ons na Jenkins oorgeskakel en sommige van die hoofpyn wat verband hou met die instandhouding van verskeie Teamcity-gevalle uitgeskakel. Daarom kon ons daarop fokus om Integro te ontwikkel en Jenkins vir onsself aan te pas.

Met die groei van basiese outomatisering (in die vorm van outomatiese skepping van Pull Requests, versameling en publikasie van Kode-dekking en ander tjeks), is daar 'n sterk begeerte om handvrystellings soveel as moontlik te laat vaar en hierdie werk aan robotte te gee. Daarbenewens het die maatskappy begin beweeg na mikrodienste binne die maatskappy, wat gereelde vrystellings vereis het, en afsonderlik van mekaar. Dit is hoe ons geleidelik by outomatiese vrystellings van ons mikrodienste gekom het (ons stel tans die monoliet met die hand vry as gevolg van die kompleksiteit van die proses). Maar, soos gewoonlik gebeur, het 'n nuwe kompleksiteit ontstaan. 

Ons outomatiseer toetsing

As gevolg van die outomatisering van vrystellings, het ontwikkelingsprosesse versnel, deels as gevolg van die oorslaan van sommige toetsfases. En dit het gelei tot 'n tydelike verlies aan kwaliteit. Dit klink triviaal, maar saam met die versnelling van vrystellings was dit nodig om die produkontwikkelingsmetodologie te verander. Dit was nodig om te dink oor die outomatisering van toetsing, die inlewing van persoonlike verantwoordelikheid (hier praat ons van "aanvaarding van die idee in die kop", nie geldelike boetes nie) van die ontwikkelaar vir die vrygestelde kode en foute daarin, sowel as die besluit om 'n taak vrystel/nie vrystel deur outomatiese ontplooiing nie. 

Om kwaliteitprobleme uit te skakel, het ons tot twee belangrike besluite gekom: ons het begin om kanarie-toetse uit te voer en het outomatiese monitering van die foutagtergrond ingestel met 'n outomatiese reaksie op die oormaat daarvan. Die eerste oplossing het dit moontlik gemaak om ooglopende foute te vind voordat die kode volledig in produksie vrygestel is, die tweede het die reaksietyd op probleme in produksie verminder. Foute gebeur natuurlik, maar ons bestee die meeste van ons tyd en moeite nie daaraan om dit reg te stel nie, maar om dit te minimaliseer. 

Outomatiseringspan

Ons het tans 'n personeel van 130 ontwikkelaars, en ons gaan voort groei. Die span vir deurlopende integrasie en kode-aflewering (hierna na verwys as die Ontplooi en Integrasie of DI-span) bestaan ​​uit 7 mense en werk in 2 rigtings: ontwikkeling van die Integro-outomatiseringsplatform en DevOps. 

DevOps is verantwoordelik vir die Dev/Beta-omgewing van die CIAN-werf, die Integro-omgewing, help ontwikkelaars om probleme op te los en ontwikkel nuwe benaderings tot skaalomgewings. Die Integro-ontwikkelingsrigting handel oor beide Integro self en verwante dienste, byvoorbeeld plugins vir Jenkins, Jira, Confluence, en ontwikkel ook hulpnutsprogramme en toepassings vir ontwikkelingspanne. 

Die DI-span werk saam met die Platform-span, wat die argitektuur, biblioteke en ontwikkelingsbenaderings intern ontwikkel. Terselfdertyd kan enige ontwikkelaar binne CIAN bydra tot outomatisering, byvoorbeeld, maak mikro-outomatisering om by die behoeftes van die span te pas of deel 'n oulike idee oor hoe om outomatisering nog beter te maak.

Laagkoek van outomatisering by CIAN

Alle stelsels betrokke by outomatisering kan in verskeie lae verdeel word:

1. Eksterne stelsels (Jira, Bitbucket, ens.). Ontwikkelingspanne werk saam met hulle.
2. Integro platform. Meestal werk ontwikkelaars nie direk daarmee nie, maar dit is wat alle outomatisering aan die gang hou.
3. Aflewerings-, orkestrasie- en ontdekkingsdienste (byvoorbeeld Jeknins, Consul, Nomad). Met hul hulp ontplooi ons kode op bedieners en verseker dat dienste met mekaar werk.
4. Fisiese laag (bedieners, bedryfstelsel, verwante sagteware). Ons kode werk op hierdie vlak. Dit kan óf 'n fisiese bediener óf 'n virtuele een wees (LXC, KVM, Docker).

Op grond van hierdie konsep verdeel ons verantwoordelikheidsareas binne die DI-span. Die eerste twee vlakke is in die verantwoordelikheidsgebied van die Integro-ontwikkelingsrigting, en die laaste twee vlakke is reeds in die verantwoordelikheidsgebied van DevOps. Hierdie skeiding stel ons in staat om op take te fokus en belemmer nie interaksie nie, aangesien ons na aan mekaar is en voortdurend kennis en ervaring uitruil.

Vol

Kom ons fokus op Integro en begin met die tegnologiestapel:

• CentOS 7
• Docker + Nomad + Consul + Vault
• Java 11 (die ou Integro-monoliet sal op Java 8 bly)
• Spring Boot 2.X + Spring Cloud Config
• PostgreSql 11
• Konyn MQ 
• Apache ontsteek
• Camunda (ingebed)
• Grafana + Grafiet + Prometheus + Jaeger + ELK
• Web-UI: Reageer (CSR) + MobX
• SSO: Sleutelmantel

Ons hou by die beginsel van mikrodiensontwikkeling, hoewel ons nalatenskap het in die vorm van 'n monoliet van 'n vroeë weergawe van Integro. Elke mikrodiens loop in sy eie Docker-houer, en die dienste kommunikeer met mekaar via HTTP-versoeke en RabbitMQ-boodskappe. Mikrodienste vind mekaar deur Consul en rig 'n versoek aan dit, gee magtiging deur SSO (Keycloak, OAuth 2/OpenID Connect).

As 'n werklike voorbeeld, oorweeg interaksie met Jenkins, wat uit die volgende stappe bestaan:

1. Die werkvloeibestuursmikrodiens (hierna na verwys as die Flow-mikrodiens) wil 'n gebou in Jenkins laat loop. Om dit te doen, gebruik hy Consul om die IP:PORT van die mikrodiens te vind vir integrasie met Jenkins (hierna verwys as Jenkins mikrodiens) en stuur 'n asynchrone versoek daaraan om die bou in Jenkins te begin.
2. Nadat 'n versoek ontvang is, genereer en reageer die Jenkins-mikrodiens met 'n Job ID, wat dan gebruik kan word om die resultaat van die werk te identifiseer. Terselfdertyd aktiveer dit die bou in Jenkins via 'n REST API-oproep.
3. Jenkins voer die bou uit en stuur na voltooiing 'n webhook met die uitvoering resultate na die Jenkins mikrodiens.
4. Die Jenkins-mikrodiens, nadat hy die webhook ontvang het, genereer 'n boodskap oor die voltooiing van versoekverwerking en heg die uitvoeringsresultate daaraan. Die gegenereerde boodskap word na die RabbitMQ-ry gestuur.
5. Deur RabbitMQ bereik die gepubliseerde boodskap die Flow-mikrodiens, wat leer oor die resultaat van die verwerking van sy taak deur die Job ID van die versoek en die ontvangde boodskap te pas.

Nou het ons ongeveer 30 mikrodienste, wat in verskeie groepe verdeel kan word:

1. Konfigurasiebestuur.
2. Inligting en interaksie met gebruikers (boodskappers, pos).
3. Werk met bronkode.
4. Integrasie met ontplooiingsinstrumente (jenkins, nomad, konsul, ens.).
5. Monitering (vrystellings, foute, ens.).
6. Webhulpprogramme (UI vir die bestuur van toetsomgewings, die insameling van statistieke, ens.).
7. Integrasie met taakopsporers en soortgelyke stelsels.
8. Werkvloeibestuur vir verskillende take.

Werkvloei take

Integro outomatiseer aktiwiteite wat verband hou met die taaklewensiklus. In vereenvoudigde terme sal die lewensiklus van 'n taak verstaan ​​word as die werkvloei van 'n taak in Jira. Ons ontwikkelingsprosesse het verskeie werkvloeivariasies na gelang van die projek, die tipe taak en die opsies wat in 'n spesifieke taak gekies is. 

Kom ons kyk na die werkvloei wat ons die meeste gebruik:

In die diagram dui die rat aan dat oorgang outomaties deur Integro geroep word, terwyl die menslike figuur aandui dat oorgang met die hand deur 'n persoon geroep word. Kom ons kyk na verskeie paaie wat 'n taak in hierdie werkvloei kan volg.

Heeltemal handmatige toetsing op DEV+BETA sonder kanarietoetse (gewoonlik is dit hoe ons 'n monoliet vrystel):

Daar kan ander oorgangskombinasies wees. Soms kan die pad wat 'n probleem sal neem, gekies word deur opsies in Jira.

Taakbeweging

Kom ons kyk na die hoofstappe wat uitgevoer word wanneer 'n taak deur die "DEV Testing + Canary Tests" werkvloei beweeg:

1. Die ontwikkelaar of PM skep die taak.

2. Die ontwikkelaar neem die taak om te werk. Na voltooiing skakel dit oor na IN OORSIG-status.

3. Jira stuur 'n Webhook na die Jira-mikrodiens (verantwoordelik vir integrasie met Jira).

4. Die Jira-mikrodiens stuur 'n versoek aan die Flow-diens (verantwoordelik vir interne werkvloeie waarin werk verrig word) om die werkvloei te begin.

5. Binne die vloeidiens:

• Beoordelaars word aan die taak toegewys (Gebruikers mikrodiens wat alles van gebruikers weet + Jira mikrodiens).
• Deur die Bron-mikrodiens (dit weet van bewaarplekke en takke, maar werk nie met die kode self nie), word 'n soektog gemaak vir bewaarplekke wat 'n vertakking van ons uitgawe bevat (om die soektog te vereenvoudig, val die naam van die tak saam met die uitgawe nommer in Jira). Dikwels het 'n taak net een tak in een bewaarplek; dit vergemaklik die bestuur van die ontplooiingstou en verminder konneksie tussen bewaarplekke.
• Vir elke gevind tak word die volgende volgorde van aksies uitgevoer:

  i) Opdatering van die meestertak (Git-mikrodiens om met kode te werk).
  ii) Die tak word geblokkeer van veranderinge deur die ontwikkelaar (Bitbucket-mikrodiens).
  iii) 'n Trekversoek word vir hierdie tak geskep (Bitbucket-mikrodiens).
  iv) 'n Boodskap oor 'n nuwe trekversoek word na ontwikkelaarkletse gestuur (Stel mikrodiens in kennis om met kennisgewings te werk).
  v) Bou-, toets- en ontplooi-take word op DEV (Jenkins-mikrodiens om met Jenkins te werk) begin.
  vi) As alle vorige stappe suksesvol voltooi is, plaas Integro sy goedkeuring in die Pull Request (Bitbucket-mikrodiens).

• Integro wag op Goedkeur in trek-versoek van aangewese beoordelaars.
• Sodra alle nodige goedkeurings ontvang is (insluitend outomatiese toetse positief geslaag het), dra Integro die taak oor na Toets op Dev (Jira mikrodiens) status.

6. Toetsers toets die taak. As daar geen probleme is nie, word die taak oorgedra na die Gereed vir Bou-status.

7. Integro "sien" dat die taak gereed is vir vrystelling en begin sy ontplooiing in kanariemodus (Jenkins mikrodiens). Gereedheid vir vrylating word bepaal deur 'n stel reëls. Die taak is byvoorbeeld in die vereiste status, daar is geen slotte op ander take nie, daar is tans geen aktiewe oplaaie van hierdie mikrodiens nie, ens.

8. Die taak word oorgedra na Kanariese status (Jira mikrodiens).

9. Jenkins loods 'n ontplooiingstaak deur Nomad in kanariemodus (gewoonlik 1-3 gevalle) en stel die vrystellingmoniteringdiens (DeployWatch-mikrodiens) in kennis van die ontplooiing.

10. Die DeployWatch-mikrodiens versamel die foutagtergrond en reageer daarop, indien nodig. As die foutagtergrond oorskry word (die agtergrondnorm word outomaties bereken), word ontwikkelaars via die Notify-mikrodiens in kennis gestel. As die ontwikkelaar na 5 minute nie gereageer het nie (Keer Terug of Bly geklik het), dan word 'n outomatiese terugrol van die kanarie-gevalle geloods. As die agtergrond nie oorskry word nie, moet die ontwikkelaar die taakontplooiing handmatig na Produksie begin (deur op 'n knoppie in die gebruikerskoppelvlak te klik). As die ontwikkelaar nie binne 60 minute die ontplooiing na Produksie van stapel gestuur het nie, sal die kanarie-gevalle ook om sekuriteitsredes teruggerol word.

11. Nadat die ontplooiing na Produksie bekendgestel is:

• Die taak word oorgedra na Produksiestatus (Jira mikrodiens).
• Die Jenkins-mikrodiens begin die ontplooiingsproses en stel die DeployWatch-mikrodiens in kennis van die ontplooiing.
• Die DeployWatch-mikrodiens kontroleer dat alle houers op produksie opgedateer is (daar was gevalle waar nie almal opgedateer is nie).
• Deur die Notify-mikrodiens word 'n kennisgewing oor die resultate van die ontplooiing na Produksie gestuur.

12. Ontwikkelaars sal 30 minute hê om 'n taak van Produksie te begin terugrol indien verkeerde mikrodiensgedrag bespeur word. Na hierdie tyd sal die taak outomaties saamgevoeg word in meester (Git mikrodiens).

13. Na 'n suksesvolle samesmelting in meester, sal die taakstatus verander word na Geslote (Jira mikrodiens).

Die diagram gee nie voor om heeltemal gedetailleerd te wees nie (in werklikheid is daar selfs meer stappe), maar dit laat jou toe om die mate van integrasie in prosesse te assesseer. Ons beskou hierdie skema nie as ideaal nie en is besig om die prosesse van outomatiese vrystelling en ontplooiingsondersteuning te verbeter.

Wat is volgende?

Ons het groot planne vir die ontwikkeling van outomatisering, byvoorbeeld die uitskakeling van handbewerkings tydens monolietvrystellings, die verbetering van monitering tydens outomatiese ontplooiing, en die verbetering van interaksie met ontwikkelaars.

Maar kom ons stop vir eers hier. Ons het baie onderwerpe in die outomatiseringsoorsig oppervlakkig gedek, sommige is glad nie aangeraak nie, so ons sal graag vrae beantwoord. Ons wag vir voorstelle oor wat om in detail te dek, skryf in die kommentaar.

Bron: will.com