Kutoka kwa maandishi hadi jukwaa letu wenyewe: jinsi tulivyoendesha maendeleo katika CIAN

Katika RIT 2019, mwenzetu Alexander Korotkov alifanya ripoti kuhusu uendelezaji kiotomatiki katika CIAN: kurahisisha maisha na kazi, tunatumia jukwaa letu la Integro. Hufuatilia mzunguko wa maisha ya kazi, huwaondolea wasanidi programu shughuli za kawaida na hupunguza kwa kiasi kikubwa idadi ya hitilafu katika uzalishaji. Katika chapisho hili, tutakamilisha ripoti ya Alexander na kukuambia jinsi tulivyotoka kwa hati rahisi hadi kuchanganya bidhaa huria kupitia mfumo wetu wenyewe na kile ambacho timu yetu tofauti ya otomatiki hufanya.
 

Kiwango cha sifuri

"Hakuna kitu kama kiwango cha sifuri, sijui kitu kama hicho"
Mwalimu Shifu kutoka kwa filamu "Kung Fu Panda"

Automation katika CIAN ilianza miaka 14 baada ya kampuni kuanzishwa. Wakati huo kulikuwa na watu 35 katika timu ya maendeleo. Vigumu kuamini, sawa? Kwa kweli, otomatiki ilikuwepo kwa namna fulani, lakini mwelekeo tofauti wa ujumuishaji unaoendelea na utoaji wa nambari ulianza kuchukua sura mnamo 2015. 

Wakati huo, tulikuwa na monolith kubwa ya Python, C # na PHP, iliyotumiwa kwenye seva za Linux/Windows. Ili kupeleka mnyama huyu, tulikuwa na seti ya hati ambazo tuliendesha kwa mikono. Kulikuwa pia na mkusanyiko wa jengo la monolith, ambalo lilileta maumivu na mateso kutokana na migogoro wakati wa kuunganisha matawi, kurekebisha kasoro, na kujenga upya "kwa seti tofauti ya kazi katika ujenzi." Mchakato rahisi ulionekana kama hii:

Hatukufurahishwa na hili, na tulitaka kujenga muundo unaorudiwa, wa kiotomatiki na unaoweza kudhibitiwa na mchakato wa kusambaza. Kwa hili, tulihitaji mfumo wa CI / CD, na tulichagua kati ya toleo la bure la Teamcity na toleo la bure la Jenkins, kwa kuwa tulifanya kazi nao na wote wawili walitufaa kwa suala la seti ya kazi. Tulichagua Teamcity kama bidhaa ya hivi majuzi zaidi. Wakati huo, hatukuwa tumetumia usanifu wa microservice na hatukutarajia idadi kubwa ya kazi na miradi.

Tunakuja kwenye wazo la mfumo wetu wenyewe

Utekelezaji wa Teamcity uliondoa sehemu tu ya kazi ya mwongozo: kilichosalia ni kuunda Maombi ya Kuvuta, kukuza masuala kwa hadhi katika Jira, na uteuzi wa masuala ya kutolewa. Mfumo wa Teamcity haukuweza tena kukabiliana na hili. Ilikuwa ni lazima kuchagua njia ya automatisering zaidi. Tulizingatia chaguo za kufanya kazi na hati katika Teamcity au kubadili mifumo ya otomatiki ya watu wengine. Lakini mwishowe tuliamua kwamba tunahitaji kubadilika kwa kiwango cha juu, ambayo suluhisho letu wenyewe linaweza kutoa. Hivi ndivyo toleo la kwanza la mfumo wa otomatiki wa ndani unaoitwa Integro ulionekana.

Teamcity inashughulika na otomatiki katika kiwango cha kuzindua michakato ya kujenga na kusambaza, huku Integro ikilenga otomatiki wa hali ya juu wa michakato ya maendeleo. Ilihitajika kuchanganya kazi na masuala katika Jira na usindikaji wa msimbo wa chanzo unaohusishwa katika Bitbucket. Katika hatua hii, Integro ilianza kuwa na mtiririko wake wa kufanya kazi na kazi za aina tofauti. 

Kwa sababu ya kuongezeka kwa otomatiki katika michakato ya biashara, idadi ya miradi na uendeshaji katika Teamcity imeongezeka. Kwa hivyo shida mpya ilikuja: mfano mmoja wa bure wa Teamcity haukutosha (mawakala 3 na miradi 100), tuliongeza mfano mwingine (maajenti 3 zaidi na miradi 100), kisha mwingine. Kama matokeo, tuliishia na mfumo wa nguzo kadhaa, ambayo ilikuwa ngumu kudhibiti:

Swali la tukio la 4 lilipoibuka, tuligundua kuwa hatukuweza kuendelea kuishi hivi, kwa sababu gharama zote za kusaidia matukio 4 hazikuwa tena ndani ya kikomo chochote. Swali lilizuka kuhusu kununua Teamcity ya kulipwa au kuchagua Jenkins bila malipo. Tulifanya hesabu kwa matukio na mipango ya otomatiki na tukaamua kuwa tutaishi kwenye Jenkins. Baada ya wiki kadhaa, tulibadilisha Jenkins na tukaondoa baadhi ya maumivu ya kichwa yanayohusiana na kudumisha matukio mengi ya Teamcity. Kwa hiyo, tuliweza kuzingatia kuendeleza Integro na kubinafsisha Jenkins kwa ajili yetu wenyewe.

Pamoja na ukuaji wa automatisering ya msingi (kwa namna ya uundaji wa moja kwa moja wa Maombi ya Kuvuta, ukusanyaji na uchapishaji wa chanjo ya Kanuni na hundi nyingine), kuna hamu kubwa ya kuachana na kutolewa kwa mwongozo iwezekanavyo na kutoa kazi hii kwa robots. Kwa kuongezea, kampuni ilianza kuhamia huduma ndogo ndani ya kampuni, ambayo ilihitaji kutolewa mara kwa mara, na kando kutoka kwa kila mmoja. Hivi ndivyo tulivyokuja hatua kwa hatua kutoa otomatiki za huduma zetu ndogo (kwa sasa tunatoa monolith kwa mikono kwa sababu ya ugumu wa mchakato). Lakini, kama kawaida, ugumu mpya uliibuka. 

Tunafanya majaribio otomatiki

Kwa sababu ya uwekaji wa matoleo otomatiki, michakato ya ukuzaji imeharakishwa, kwa kiasi kutokana na kuruka kwa baadhi ya hatua za majaribio. Na hii ilisababisha hasara ya muda ya ubora. Inaonekana ni ndogo, lakini pamoja na kuongeza kasi ya kutolewa, ilikuwa ni lazima kubadili mbinu ya maendeleo ya bidhaa. Ilihitajika kufikiria juu ya otomatiki ya upimaji, kuingiza uwajibikaji wa kibinafsi (hapa tunazungumza juu ya "kukubali wazo kichwani", sio faini ya pesa) ya msanidi programu kwa nambari iliyotolewa na mende ndani yake, na pia uamuzi wa toa/usiachie kazi kwa kusambaza kiotomatiki. 

Kuondoa matatizo ya ubora, tulikuja kwa maamuzi mawili muhimu: tulianza kufanya uchunguzi wa canary na kuanzisha ufuatiliaji wa moja kwa moja wa historia ya makosa na majibu ya moja kwa moja kwa ziada yake. Suluhisho la kwanza lilifanya iwezekanavyo kupata makosa dhahiri kabla ya msimbo kutolewa kikamilifu katika uzalishaji, pili ilipunguza muda wa kukabiliana na matatizo katika uzalishaji. Makosa, kwa kweli, hufanyika, lakini tunatumia wakati wetu mwingi na bidii sio kurekebisha, lakini kwa kupunguza. 

Timu ya otomatiki

Kwa sasa tuna wafanyakazi wa watengenezaji 130, na tunaendelea kukua. Timu ya ujumuishaji unaoendelea na uwasilishaji wa msimbo (ambayo hapo baadaye itajulikana kama Timu ya Usambazaji na Ujumuishaji au timu ya DI) inajumuisha watu 7 na inafanya kazi katika pande 2: uundaji wa jukwaa la otomatiki la Integro na DevOps. 

DevOps inawajibika kwa mazingira ya Dev/Beta ya tovuti ya CIAN, mazingira ya Integro, huwasaidia wasanidi programu kutatua matatizo na kubuni mbinu mpya za kuongeza mazingira. Mwelekeo wa ukuzaji wa Integro hushughulikia Integro yenyewe na huduma zinazohusiana, kwa mfano, programu-jalizi za Jenkins, Jira, Confluence, na pia hutengeneza huduma na programu-saidizi za timu za maendeleo. 

Timu ya DI inafanya kazi kwa ushirikiano na timu ya Jukwaa, ambayo inakuza usanifu, maktaba na mbinu za ukuzaji ndani. Wakati huo huo, msanidi programu yeyote ndani ya CIAN anaweza kuchangia otomatiki, kwa mfano, kutengeneza otomatiki ndogo ili kukidhi mahitaji ya timu au kushiriki wazo zuri la jinsi ya kufanya otomatiki kuwa bora zaidi.

Tabaka keki ya automatisering katika CIAN

Mifumo yote inayohusika katika otomatiki inaweza kugawanywa katika tabaka kadhaa:

1. Mifumo ya nje (Jira, Bitbucket, nk). Timu za maendeleo hufanya kazi nao.
2. Jukwaa la Integro. Mara nyingi, watengenezaji hawafanyi kazi nayo moja kwa moja, lakini ndio huweka otomatiki zote kufanya kazi.
3. Uwasilishaji, okestration na huduma za ugunduzi (kwa mfano, Jeknin, Consul, Nomad). Kwa msaada wao, tunasambaza nambari kwenye seva na kuhakikisha kuwa huduma zinafanya kazi pamoja.
4. Safu ya kimwili (seva, OS, programu inayohusiana). Nambari yetu inafanya kazi katika kiwango hiki. Hii inaweza kuwa seva ya mwili au ya kawaida (LXC, KVM, Docker).

Kulingana na dhana hii, tunagawanya maeneo ya wajibu ndani ya timu ya DI. Viwango viwili vya kwanza viko katika eneo la uwajibikaji wa mwelekeo wa maendeleo wa Integro, na viwango viwili vya mwisho tayari viko katika eneo la uwajibikaji wa DevOps. Mgawanyiko huu unatuwezesha kuzingatia kazi na haiingilii na mwingiliano, kwa kuwa sisi ni karibu na kila mmoja na daima tunabadilishana ujuzi na uzoefu.

Imekamilika

Wacha tuangazie Integro na tuanze na safu ya teknolojia:

• CentOS 7
• Docker + Nomad + Consul + Vault
• Java 11 (monolith ya zamani ya Integro itabaki kwenye Java 8)
• Spring Boot 2.X + Spring Cloud Config
• PostgreSql 11
• SunguraMQ 
• Apache Ignite
• Camunda (iliyopachikwa)
• Grafana + Graphite + Prometheus + Jaeger + ELK
• UI ya Wavuti: React (CSR) + MobX
• SSO: Nguo kuu

Tunazingatia kanuni ya ukuzaji wa huduma ndogo, ingawa tuna urithi katika mfumo wa monolith ya toleo la mapema la Integro. Kila huduma ndogo huendeshwa katika chombo chake cha Docker, na huduma huwasiliana kupitia maombi ya HTTP na ujumbe wa RabbitMQ. Huduma ndogo hupatana kupitia Balozi na kutuma ombi kwake, kwa kupitisha idhini kupitia SSO (Keycloak, OAuth 2/OpenID Connect).

Kama mfano wa maisha halisi, fikiria kuingiliana na Jenkins, ambayo ina hatua zifuatazo:

1. Huduma ndogo ya usimamizi wa mtiririko wa kazi (hapa inajulikana kama Flow microservice) inataka kuendesha jengo huko Jenkins. Ili kufanya hivyo, anatumia Consul kupata IP:PORT ya huduma ndogo ya kuunganishwa na Jenkins (hapa inajulikana kama Jenkins microservice) na kutuma ombi lisilo la kawaida kwake ili kuanza ujenzi huko Jenkins.
2. Baada ya kupokea ombi, huduma ndogo ya Jenkins inazalisha na kujibu kwa Kitambulisho cha Kazi, ambacho kinaweza kutumika kutambua matokeo ya kazi. Wakati huo huo, inasababisha ujenzi katika Jenkins kupitia simu ya REST API.
3. Jenkins hufanya ujenzi na, baada ya kukamilika, hutuma kiboreshaji cha wavuti na matokeo ya utekelezaji kwa huduma ndogo ya Jenkins.
4. Huduma ndogo ya Jenkins, ikiwa imepokea webhook, hutoa ujumbe juu ya kukamilika kwa usindikaji wa ombi na inashikilia matokeo ya utekelezaji kwake. Ujumbe unaozalishwa unatumwa kwenye foleni ya RabbitMQ.
5. Kupitia RabbitMQ, ujumbe uliochapishwa unafikia Flow microservice, ambayo hujifunza kuhusu matokeo ya usindikaji kazi yake kwa kulinganisha Kitambulisho cha Kazi kutoka kwa ombi na ujumbe uliopokelewa.

Sasa tunayo huduma ndogo 30, ambazo zinaweza kugawanywa katika vikundi kadhaa:

1. Usimamizi wa usanidi.
2. Habari na mwingiliano na watumiaji (wajumbe, barua).
3. Kufanya kazi na msimbo wa chanzo.
4. Kuunganishwa na zana za kupeleka (jenkins, nomad, consul, nk).
5. Ufuatiliaji (matoleo, makosa, nk).
6. Huduma za wavuti (UI ya kudhibiti mazingira ya majaribio, kukusanya takwimu, n.k.).
7. Kuunganishwa na wafuatiliaji wa kazi na mifumo inayofanana.
8. Usimamizi wa mtiririko wa kazi kwa kazi tofauti.

Kazi za mtiririko wa kazi

Integro huendesha shughuli zinazohusiana na mzunguko wa maisha wa kazi. Kwa maneno yaliyorahisishwa, mzunguko wa maisha wa kazi utaeleweka kama mtiririko wa kazi katika Jira. Michakato yetu ya ukuzaji ina tofauti kadhaa za mtiririko wa kazi kulingana na mradi, aina ya kazi na chaguo zilizochaguliwa katika kazi fulani. 

Wacha tuangalie mtiririko wa kazi ambao tunatumia mara nyingi:

Katika mchoro, gear inaonyesha kwamba mpito huitwa moja kwa moja na Integro, wakati takwimu ya binadamu inaonyesha kwamba mpito inaitwa manually na mtu. Wacha tuangalie njia kadhaa ambazo kazi inaweza kuchukua katika mtiririko huu wa kazi.

Majaribio ya kibinafsi kabisa kwenye DEV+BETA bila majaribio ya canary (kawaida hivi ndivyo tunavyotoa monolith):

Kunaweza kuwa na michanganyiko mingine ya mpito. Wakati mwingine njia ambayo suala litachukua inaweza kuchaguliwa kupitia chaguo katika Jira.

Harakati ya kazi

Hebu tuangalie hatua kuu zinazotekelezwa wakati kazi inaposogezwa kwenye mtiririko wa kazi wa "Majaribio ya DEV + Majaribio ya Canary":

1. Msanidi programu au PM huunda kazi.

2. Msanidi huchukua kazi kufanya kazi. Baada ya kukamilika, inabadilika hadi hali ya KATIKA MAONI.

3. Jira hutuma Webhook kwa huduma ndogo ya Jira (inayohusika na kuunganishwa na Jira).

4. Huduma ndogo ya Jira inatuma ombi kwa huduma ya Mtiririko (inayohusika na utiririshaji wa kazi wa ndani ambao kazi inafanywa) ili kuanza utiririshaji wa kazi.

5. Ndani ya huduma ya Mtiririko:

• Wakaguzi wamepewa kazi (Watumiaji microservice ambayo inajua kila kitu kuhusu watumiaji + Jira microservice).
• Kupitia Chanzo cha microservice (inajua juu ya hazina na matawi, lakini haifanyi kazi na nambari yenyewe), utaftaji unafanywa kwa hazina ambazo zina tawi la suala letu (ili kurahisisha utaftaji, jina la tawi linaambatana na suala hilo. nambari katika Jira). Mara nyingi, kazi huwa na tawi moja tu kwenye hazina moja; hii hurahisisha usimamizi wa foleni ya upelekaji na kupunguza muunganisho kati ya hazina.
• Kwa kila tawi lililopatikana, mlolongo ufuatao wa vitendo hufanywa:

  i) Kusasisha tawi kuu (Git microservice kwa kufanya kazi na nambari).
  ii) Tawi limezuiwa kutokana na mabadiliko na msanidi programu (Bitbucket microservice).
  iii) Ombi la Kuvuta limeundwa kwa tawi hili (Bitbucket microservice).
  iv) Ujumbe kuhusu Ombi jipya la Kuvuta hutumwa kwa gumzo za wasanidi programu (Arifu huduma ndogo kwa kufanya kazi na arifa).
  v) Kuunda, kujaribu na kupeleka kazi huanzishwa kwenye DEV (Jenkins microservice ya kufanya kazi na Jenkins).
  vi) Ikiwa hatua zote za awali zimekamilika kwa mafanikio, basi Integro inaweka Idhini yake katika Ombi la Kuvuta (Bitbucket microservice).

• Integro inasubiri Kuidhinisha Ombi la Kuvuta kutoka kwa wakaguzi walioteuliwa.
• Mara tu idhini zote muhimu zinapopokelewa (ikiwa ni pamoja na majaribio ya kiotomatiki yamefaulu vyema), Integro huhamisha jukumu hilo hadi kwenye Test on Dev (Jira microservice) hali.

6. Wajaribu hujaribu kazi. Ikiwa hakuna matatizo, basi kazi inahamishiwa kwenye hali ya Tayari kwa Kujenga.

7. Integro "inaona" kwamba kazi iko tayari kwa kutolewa na kuanza kupelekwa kwake katika hali ya canary (Jenkins microservice). Utayari wa kutolewa umedhamiriwa na seti ya sheria. Kwa mfano, kazi iko katika hali inayohitajika, hakuna kufuli kwenye kazi zingine, kwa sasa hakuna upakiaji wa kazi wa huduma hii ndogo, nk.

8. Kazi inahamishiwa kwenye hali ya Canary (Jira microservice).

9. Jenkins huzindua kazi ya kupeleka kupitia Nomad katika hali ya canary (kwa kawaida matukio 1-3) na kuarifu huduma ya ufuatiliaji wa uchapishaji (DeployWatch microservice) kuhusu uwekaji.

10. Huduma ndogo ya DeployWatch hukusanya mandharinyuma ya hitilafu na kujibu ikiwa ni lazima. Ikiwa usuli wa hitilafu umepitwa (kaida ya usuli inakokotolewa kiotomatiki), wasanidi programu wanaarifiwa kupitia huduma ndogo ya Arifa. Ikiwa baada ya dakika 5 msanidi programu hajajibu (alibofya Rejesha au Kaa), basi urejeshaji wa kiotomatiki wa matukio ya canary utazinduliwa. Ikiwa mandharinyuma haijapitwa, basi msanidi lazima azindue mwenyewe uwekaji kazi kwenye Uzalishaji (kwa kubofya kitufe kwenye Kiolesura). Iwapo ndani ya dakika 60 msanidi atakuwa hajaanzisha utumaji kwa Uzalishaji, basi matukio ya canary pia yatarejeshwa kwa sababu za usalama.

11. Baada ya kuzindua kupelekwa kwa Uzalishaji:

• Kazi inahamishiwa kwa hali ya Uzalishaji (Jira microservice).
• Huduma ndogo ya Jenkins huanza mchakato wa kusambaza na kuarifu huduma ndogo ya DeployWatch kuhusu uwekaji.
• Huduma ndogo ya DeployWatch hukagua ikiwa kontena zote kwenye Uzalishaji zimesasishwa (kulikuwa na visa wakati sio zote zilisasishwa).
• Kupitia Notify microservice, arifa kuhusu matokeo ya utumaji hutumwa kwa Uzalishaji.

12. Wasanidi watakuwa na dakika 30 za kuanza kurejesha kazi kutoka kwa Uzalishaji ikiwa tabia isiyo sahihi ya huduma ndogo itagunduliwa. Baada ya wakati huu, kazi itaunganishwa kiotomatiki kuwa master (Git microservice).

13. Baada ya kuunganishwa kwa mafanikio kuwa bwana, hali ya kazi itabadilishwa kuwa Iliyofungwa (Jira microservice).

Mchoro haujifanya kuwa wa kina kabisa (kwa kweli kuna hatua zaidi), lakini hukuruhusu kutathmini kiwango cha ujumuishaji katika michakato. Hatuoni mpango huu kuwa bora na tunaboresha michakato ya kutolewa kiotomatiki na usaidizi wa kusambaza.

Nini kifuatacho

Tuna mipango mikubwa ya ukuzaji wa otomatiki, kwa mfano, kuondoa shughuli za mikono wakati wa kutolewa kwa monolith, kuboresha ufuatiliaji wakati wa kusambaza kiotomatiki, na kuboresha mwingiliano na wasanidi.

Lakini tuishie hapa kwa sasa. Tulishughulikia mada nyingi katika ukaguzi wa kiotomatiki juu juu, zingine hazikuguswa hata kidogo, kwa hivyo tutafurahi kujibu maswali. Tunasubiri mapendekezo juu ya nini cha kufunika kwa undani, kuandika katika maoni.

Chanzo: mapenzi.com