Frá skriftum til okkar eigin vettvangs: hvernig við sjálfvirkum þróun hjá CIAN

Á RIT 2019 gerði samstarfsmaður okkar Alexander Korotkov skýrsla um sjálfvirkni þróunar hjá CIAN: til að einfalda líf og starf notum við okkar eigin Integro vettvang. Það fylgist með lífsferli verkefna, léttir forritara við venjubundnar aðgerðir og dregur verulega úr fjölda galla í framleiðslu. Í þessari færslu munum við bæta við skýrslu Alexanders og segja þér hvernig við fórum frá einföldum skriftum yfir í að sameina opinn uppspretta vörur í gegnum okkar eigin vettvang og hvað aðskilið sjálfvirkniteymi okkar gerir.
 

Núll stig

„Það er ekkert til sem heitir núllstig, ég veit ekki um slíkt“
Master Shifu úr myndinni "Kung Fu Panda"

Sjálfvirkni hjá CIAN hófst 14 árum eftir að fyrirtækið var stofnað. Á þeim tíma voru 35 manns í þróunarteymi. Erfitt að trúa, ekki satt? Auðvitað var sjálfvirkni til í einhverri mynd, en sérstök stefna fyrir stöðuga samþættingu og kóðaafhendingu byrjaði að taka á sig mynd árið 2015. 

Á þeim tíma vorum við með gríðarstóran einliða af Python, C# og PHP, uppsett á Linux/Windows netþjónum. Til að dreifa þessu skrímsli höfðum við sett af skriftum sem við keyrðum handvirkt. Það var líka samsetning einliða, sem olli sársauka og þjáningu vegna átaka við sameiningu útibúa, lagfæringu á göllum og endurreisn „með mismunandi verkefnum í smíðinni. Einfaldað ferli leit svona út:

Við vorum ekki ánægð með þetta og við vildum byggja upp endurtekið, sjálfvirkt og viðráðanlegt byggingar- og dreifingarferli. Til þess þurftum við CI/CD kerfi og við völdum á milli ókeypis útgáfunnar af Teamcity og ókeypis útgáfunnar af Jenkins, þar sem við unnum með þær og báðar henta okkur hvað varðar aðgerðir. Við völdum Teamcity sem nýlegri vöru. Á þeim tíma höfðum við ekki enn notað örþjónustuarkitektúr og bjuggumst ekki við miklum fjölda verkefna og verkefna.

Við komumst að hugmyndinni um okkar eigið kerfi

Innleiðing Teamcity fjarlægði aðeins hluta af handavinnunni: það sem eftir stendur er stofnun Pull Requests, kynning á málum eftir stöðu í Jira og val á málum til útgáfu. Teamcity kerfið gat ekki lengur ráðið við þetta. Nauðsynlegt var að velja leið frekari sjálfvirkni. Við skoðuðum möguleika til að vinna með forskriftir í Teamcity eða skipta yfir í sjálfvirknikerfi þriðja aðila. En á endanum ákváðum við að við þyrftum hámarks sveigjanleika, sem aðeins okkar eigin lausn getur veitt. Þannig birtist fyrsta útgáfan af innra sjálfvirknikerfi sem kallast Integro.

Teamcity fjallar um sjálfvirkni á því stigi að ræsa byggingar- og dreifingarferlana, en Integro einbeitti sér að sjálfvirkni þróunarferla á efstu stigi. Nauðsynlegt var að sameina vinnu við málefni í Jira og úrvinnslu á tilheyrandi frumkóða í Bitbucket. Á þessu stigi byrjaði Integro að hafa sín eigin verkflæði til að vinna með verkefni af mismunandi gerð. 

Vegna aukinnar sjálfvirkni í viðskiptaferlum hefur verkefnum og keyrslum í Teamcity fjölgað. Svo kom nýtt vandamál: eitt ókeypis Teamcity tilvik var ekki nóg (3 umboðsmenn og 100 verkefni), við bættum við öðru tilviki (3 umboðsmenn í viðbót og 100 verkefni), svo öðru. Fyrir vikið enduðum við með kerfi nokkurra klasa, sem erfitt var að stjórna:

Þegar spurningin um 4. tilvik kom upp gerðum við okkur grein fyrir því að við gætum ekki lifað svona áfram, vegna þess að heildarkostnaður við framfærslu 4 tilvika var ekki lengur innan nokkurra marka. Spurningin vaknaði um að kaupa Teamcity eða velja ókeypis Jenkins. Við gerðum útreikninga á tilvikum og sjálfvirkniáætlunum og ákváðum að við myndum búa á Jenkins. Eftir nokkrar vikur skiptum við yfir í Jenkins og útrýmdum hluta höfuðverksins sem tengist því að viðhalda mörgum Teamcity tilvikum. Þess vegna gátum við einbeitt okkur að því að þróa Integro og sérsníða Jenkins fyrir okkur sjálf.

Með vexti grunnsjálfvirkni (í formi sjálfvirkrar stofnunar Pull Requests, söfnunar og birtingar kóða umfjöllunar og annarra athugana) er sterkur vilji til að yfirgefa handvirkar útgáfur eins mikið og mögulegt er og gefa vélmenni þessa vinnu. Auk þess fór fyrirtækið að færa sig yfir í örþjónustu innan fyrirtækisins, sem krafðist tíðar útgáfur, og aðskilið frá hvor annarri. Svona komumst við smám saman að sjálfvirkum útgáfum á örþjónustunum okkar (við erum núna að gefa út einlitann handvirkt vegna þess hversu flókið ferlið er). En eins og venjulega kom upp nýtt flókið. 

Við sjálfvirkum prófun

Vegna sjálfvirkni útgáfunnar hefur þróunarferlum hraðað, að hluta til vegna þess að nokkrum prófunarstigum hefur verið sleppt. Og þetta leiddi til tímabundins gæðataps. Það hljómar léttvægt, en samhliða hröðun útgáfunnar var nauðsynlegt að breyta aðferðafræði vöruþróunar. Það var nauðsynlegt að huga að sjálfvirkni prófunar, innleiða persónulega ábyrgð (hér erum við að tala um að „samþykkja hugmyndina í hausnum“, ekki peningasektir) framkvæmdaraðilans fyrir útgefinn kóða og villur í honum, svo og ákvörðun um að losa/sleppa ekki verkefni með sjálfvirkri uppsetningu. 

Með því að útrýma gæðavandamálum komum við að tveimur mikilvægum ákvörðunum: við byrjuðum að framkvæma kanarípróf og kynntum sjálfvirkt eftirlit með villubakgrunninum með sjálfvirkri svörun við ofgnótt hans. Fyrri lausnin gerði það mögulegt að finna augljósar villur áður en kóðinn var að fullu gefinn út í framleiðslu, sú síðari minnkaði viðbragðstíma við vandamálum í framleiðslu. Mistök gerast auðvitað en við eyðum mestum tíma okkar og fyrirhöfn ekki í að leiðrétta þau heldur í að lágmarka þau. 

Sjálfvirkniteymi

Núna erum við með 130 starfsmenn og höldum áfram vaxa. Stöðugt samþættingar- og kóðaafhendingarteymi (hér eftir nefnt Deploy and Integration eða DI teymi) samanstendur af 7 mönnum og vinnur í 2 áttir: þróun á Integro sjálfvirknivettvangi og DevOps. 

DevOps ber ábyrgð á Dev/Beta umhverfi CIAN síðunnar, Integro umhverfinu, hjálpar forriturum að leysa vandamál og þróar nýjar aðferðir til að skala umhverfi. Integro þróunarstefnan fjallar bæði um Integro sjálft og tengda þjónustu, til dæmis viðbætur fyrir Jenkins, Jira, Confluence, og þróar einnig hjálpartæki og forrit fyrir þróunarteymi. 

DI teymið vinnur í samvinnu við Platform teymið, sem þróar arkitektúr, bókasöfn og þróunaraðferðir innbyrðis. Á sama tíma getur hvaða þróunaraðili innan CIAN lagt sitt af mörkum til sjálfvirkni, til dæmis gert örsjálfvirkni sem hentar þörfum teymisins eða deilt flottri hugmynd um hvernig eigi að gera sjálfvirkni enn betri.

Lagkaka af sjálfvirkni hjá CIAN

Öllum kerfum sem taka þátt í sjálfvirkni má skipta í nokkur lög:

1. Ytri kerfi (Jira, Bitbucket, osfrv.). Þróunarteymi vinna með þeim.
2. Integro vettvangur. Oftast vinna verktaki ekki beint með það, en það er það sem heldur allri sjálfvirkni gangandi.
3. Sendingar-, hljómsveitar- og uppgötvunarþjónusta (til dæmis Jeknins, Consul, Nomad). Með þeirra hjálp dreifum við kóða á netþjóna og tryggjum að þjónustur vinni saman.
4. Líkamlegt lag (þjónar, stýrikerfi, tengdur hugbúnaður). Kóðinn okkar starfar á þessu stigi. Þetta getur verið annað hvort líkamlegur netþjónn eða sýndarþjónn (LXC, KVM, Docker).

Út frá þessari hugmynd skiptum við ábyrgðarsviðum innan DI teymisins. Fyrstu tvö stigin eru á ábyrgðarsviði Integro þróunarstefnunnar og síðustu tvö stigin eru þegar á ábyrgðarsviði DevOps. Þessi aðskilnaður gerir okkur kleift að einbeita okkur að verkefnum og truflar ekki samskipti, þar sem við erum nálægt hvort öðru og skiptumst stöðugt á þekkingu og reynslu.

Ósnortinn

Einbeitum okkur að Integro og byrjum á tæknistaflanum:

• CentOS 7
• Hafnarmaður + hirðingi + ræðismaður + Vault
• Java 11 (gamli Integro monolith verður áfram á Java 8)
• Spring Boot 2.X + Spring Cloud Config
• PostgreSql 11
• Kanína MQ 
• Apache Ignite
• Camunda (innfelldur)
• Grafana + Grafít + Prometheus + Jaeger + ELK
• Vefviðmót: React (CSR) + MobX
• SSO: Keycloak

Við fylgjum meginreglunni um þróun smáþjónustu, þó að við höfum arfleifð í formi einlita af fyrstu útgáfu af Integro. Hver örþjónusta keyrir í sínum Docker íláti og þjónustan hefur samskipti sín á milli með HTTP beiðnum og RabbitMQ skilaboðum. Örþjónustur finna hver aðra í gegnum Consul og leggja fram beiðni til þess og senda leyfi í gegnum SSO (Keycloak, OAuth 2/OpenID Connect).

Sem raunverulegt dæmi skaltu íhuga samskipti við Jenkins, sem samanstendur af eftirfarandi skrefum:

1. Verkflæðisstjórnunarörþjónustan (hér eftir kölluð Flow örþjónustan) vill keyra byggingu í Jenkins. Til að gera þetta notar hann Consul til að finna IP:PORT örþjónustunnar fyrir samþættingu við Jenkins (hér eftir nefnd Jenkins örþjónusta) og sendir ósamstillta beiðni til hennar um að hefja byggingu í Jenkins.
2. Eftir að beiðni hefur borist, býr Jenkins örþjónustan til og svarar með starfsauðkenni, sem síðan er hægt að nota til að bera kennsl á niðurstöðu vinnunnar. Á sama tíma kveikir það í byggingu Jenkins með REST API símtali.
3. Jenkins framkvæmir smíðina og að því loknu sendir hann vefhook með framkvæmdarniðurstöðum til Jenkins örþjónustunnar.
4. Jenkins örþjónustan, eftir að hafa fengið vefhókinn, býr til skilaboð um að vinnslu beiðninnar sé lokið og lætur framkvæmdarniðurstöðurnar fylgja henni. Skilaboðin sem myndast eru send í RabbitMQ biðröðina.
5. Í gegnum RabbitMQ berast útgefin skilaboð til Flow örþjónustunnar, sem lærir um niðurstöðu vinnslu verkefnis síns með því að passa við starfsauðkenni frá beiðninni og mótteknu skilaboðunum.

Núna höfum við um 30 örþjónustur, sem hægt er að skipta í nokkra hópa:

1. Stillingarstjórnun.
2. Upplýsingar og samskipti við notendur (boðberar, póstur).
3. Að vinna með frumkóða.
4. Samþætting við dreifingartæki (jenkins, hirðingja, ræðismaður osfrv.).
5. Eftirlit (útgáfur, villur osfrv.).
6. Vefforrit (UI til að stjórna prófunarumhverfi, safna tölfræði osfrv.).
7. Samþætting við verkefni rekja spor einhvers og svipuð kerfi.
8. Verkflæðisstjórnun fyrir mismunandi verkefni.

Verkflæðisverkefni

Integro gerir sjálfvirkan aðgerðir sem tengjast lífsferli verkefnisins. Í einfölduðu máli verður lífsferill verkefnis skilinn sem verkflæði verkefnis í Jira. Þróunarferlar okkar eru með nokkrum afbrigðum verkflæðis eftir verkefninu, tegund verks og valmöguleikum í tilteknu verkefni. 

Við skulum skoða verkflæðið sem við notum oftast:

Á skýringarmyndinni gefur gírinn til kynna að umskipti séu kölluð sjálfkrafa af Integro, en mannsmyndin gefur til kynna að umskipti séu kölluð handvirkt af einstaklingi. Við skulum skoða nokkrar leiðir sem verkefni getur farið í þessu verkflæði.

Alveg handvirk prófun á DEV+BETA án kanaríprófa (venjulega er þetta hvernig við gefum út einlita):

Það kunna að vera aðrar umbreytingarsamsetningar. Stundum er hægt að velja leiðina sem mál mun fara í gegnum valkosti í Jira.

Verkefnahreyfing

Við skulum skoða helstu skrefin sem eru framkvæmd þegar verkefni fer í gegnum „DEV Testing + Canary Tests“ verkflæðið:

1. Verktaki eða PM býr til verkefnið.

2. Framkvæmdaraðili tekur verkefnið til starfa. Eftir að því er lokið skiptir það yfir í Í REVIEW stöðu.

3. Jira sendir Webhook til Jira örþjónustunnar (ábyrgur fyrir samþættingu við Jira).

4. Jira örþjónustan sendir beiðni til Flow þjónustunnar (sem ber ábyrgð á innri verkflæði þar sem vinna er unnin) um að ræsa verkflæðið.

5. Inni í flæðisþjónustunni:

• Gagnrýnendum er úthlutað verkefninu (Notenda örþjónusta sem veit allt um notendur + Jira örþjónusta).
• Í gegnum Source örþjónustuna (hún veit um geymslur og útibú, en virkar ekki með kóðanum sjálfum), er leitað að geymslum sem innihalda útibú af útgáfunni okkar (til að einfalda leitina fellur nafn útibúsins saman við útgáfuna númer í Jira). Oftast hefur verkefni aðeins eina útibú í einni geymslu; þetta einfaldar stjórnun á dreifingarröðinni og dregur úr tengingu milli geymslu.
• Fyrir hverja grein sem fannst er eftirfarandi röð aðgerða framkvæmd:

  i) Uppfærsla aðalútibúsins (Git microservice til að vinna með kóða).
  ii) Útibúið er lokað fyrir breytingum af þróunaraðila (Bitbucket microservice).
  iii) Pull Request er búin til fyrir þetta útibú (Bitbucket microservice).
  iv) Skilaboð um nýja Pull Request eru send til þróunarspjalla (Tilkynna örþjónustu fyrir að vinna með tilkynningar).
  v) Byggja, prófa og dreifa verkefni eru hafin á DEV (Jenkins örþjónustu til að vinna með Jenkins).
  vi) Ef öllum fyrri skrefum er lokið með góðum árangri, þá setur Integro samþykki sitt í Pull Request (Bitbucket microservice).

• Integro bíður samþykktar í Pull beiðni frá tilnefndum gagnrýnendum.
• Um leið og öll nauðsynleg samþykki hafa borist (þar á meðal sjálfvirk próf hafa staðist jákvætt), flytur Integro verkefnið yfir í Test on Dev (Jira microservice) stöðuna.

6. Prófendur prófa verkefnið. Ef það eru engin vandamál, þá er verkefnið flutt í stöðuna Tilbúið til smíði.

7. Integro „sér“ að verkefnið er tilbúið til útgáfu og byrjar uppsetningu þess í kanaríham (Jenkins microservice). Tilbúinn til losunar ræðst af settum reglum. Til dæmis er verkefnið í þeirri stöðu sem krafist er, það eru engir læsingar á öðrum verkefnum, það eru engar virkar upphleðslur á þessari örþjónustu sem stendur o.s.frv.

8. Verkefnið er flutt yfir í stöðuna Kanarí (Jira microservice).

9. Jenkins setur af stað dreifingarverkefni í gegnum Nomad í kanaríham (venjulega 1-3 tilvik) og lætur losunareftirlitsþjónustuna (DeployWatch microservice) vita um dreifinguna.

10. DeployWatch örþjónustan safnar villubakgrunni og bregst við honum ef þörf krefur. Ef farið er yfir villubakgrunninn (bakgrunnsviðmiðið er reiknað sjálfkrafa) fá þróunaraðilar tilkynningu í gegnum Notify örþjónustuna. Ef eftir 5 mínútur hefur verktaki ekki svarað (smellt á Til baka eða Vertu), þá er sjálfvirk afturköllun á kanarítilvikunum ræst. Ef ekki er farið yfir bakgrunninn, þá verður verktaki að ræsa verkefnadreifingu handvirkt í framleiðslu (með því að smella á hnapp í notendaviðmótinu). Ef verktaki hefur ekki sett dreifinguna í framleiðslu innan 60 mínútna, þá verður kanarítilvikunum einnig afturkallað af öryggisástæðum.

11. Eftir að hafa sett dreifinguna í framleiðslu:

• Verkefnið er flutt í framleiðslustöðu (Jira microservice).
• Jenkins örþjónustan byrjar dreifingarferlið og lætur DeployWatch örþjónustuna vita um dreifinguna.
• DeployWatch örþjónustan athugar að allir gámar í framleiðslu hafi verið uppfærðir (það voru tilvik þar sem ekki allir voru uppfærðir).
• Í gegnum Notify örþjónustuna er tilkynning um niðurstöður dreifingarinnar send til framleiðslu.

12. Hönnuðir munu hafa 30 mínútur til að byrja að afturkalla verkefni úr framleiðslu ef röng örþjónustuhegðun greinist. Eftir þennan tíma verður verkefnið sjálfkrafa sameinað í master (Git microservice).

13. Eftir árangursríka sameiningu í master verður verkefnastöðunni breytt í Lokað (Jira microservice).

Skýringarmyndin þykist ekki vera alveg ítarleg (í raun og veru eru enn fleiri skref), en hún gerir þér kleift að meta hversu samþætting ferla er. Við teljum þetta kerfi ekki tilvalið og erum að bæta ferla sjálfvirkrar útgáfu og dreifingarstuðnings.

Hvað er næst

Við höfum stórar áætlanir um þróun sjálfvirkni, til dæmis að útrýma handvirkum aðgerðum við útgáfur af einlitum, bæta eftirlit meðan á sjálfvirkri uppsetningu stendur og bæta samskipti við þróunaraðila.

En stoppum hér í bili. Við fórum yfir mörg efni í sjálfvirkniendurskoðuninni á yfirborðinu, sum voru alls ekki snert, svo við munum vera fús til að svara spurningum. Við bíðum eftir tillögum um hvað eigi að fjalla um í smáatriðum, skrifaðu í athugasemdirnar.

Heimild: www.habr.com