Leo, bidhaa nyingi za programu zinatengenezwa kwa timu. Masharti ya maendeleo ya timu yenye mafanikio yanaweza kuwakilishwa kwa namna ya mchoro rahisi.

Mara tu unapoandika nambari yako, unahitaji kuhakikisha kuwa:

Matumizi.
Haivunji chochote, pamoja na nambari iliyoandikwa na wenzako.

Ikiwa masharti yote mawili yametimizwa, basi uko kwenye njia ya mafanikio. Ili kuangalia kwa urahisi masharti haya na sio kuacha njia ya faida, tulikuja na Ushirikiano wa Kuendelea.

CI ni mtiririko wa kazi ambapo unaunganisha msimbo wako kwenye msimbo wa jumla wa bidhaa mara nyingi iwezekanavyo. Na huna kuunganisha tu, lakini pia angalia mara kwa mara kwamba kila kitu kinafanya kazi. Kwa kuwa unahitaji kuangalia mara nyingi na mara nyingi, inafaa kufikiria juu ya otomatiki. Unaweza kuangalia kila kitu kwa mikono, lakini hupaswi, na hii ndiyo sababu.

Watu wapendwa. Saa ya kazi ya programu yoyote ni ghali zaidi kuliko saa ya kazi ya seva yoyote.
Watu hufanya makosa. Kwa hivyo, hali zinaweza kutokea wakati majaribio yaliendeshwa kwenye tawi lisilofaa au ahadi mbaya iliundwa kwa wanaojaribu.
Watu ni wavivu. Mara kwa mara, ninapomaliza kazi fulani, wazo hutokea: “Ni nini cha kuangalia? Niliandika mistari miwili - kila kitu kinafanya kazi! Nadhani baadhi yenu pia wakati mwingine mna mawazo kama hayo. Lakini unapaswa kuangalia kila wakati.

Jinsi Ujumuishaji Unaoendelea ulivyotekelezwa na kuendelezwa katika timu ya maendeleo ya rununu ya Avito, jinsi walivyotoka kwa ujenzi wa 0 hadi 450 kwa siku, na kwamba mashine za ujenzi hukusanyika masaa 200 kwa siku, anasema Nikolai Nesterov (nnesterov) ni mshiriki katika mabadiliko yote ya CI/CD programu ya Android.

Hadithi inategemea mfano wa amri ya Android, lakini mbinu nyingi zinatumika kwenye iOS pia.

Wakati mmoja, mtu mmoja alifanya kazi katika timu ya Avito Android. Kwa ufafanuzi, hakuhitaji chochote kutoka kwa Ushirikiano wa Kuendelea: hapakuwa na mtu wa kuunganisha.

Lakini maombi yalikua, kazi zaidi na zaidi zilionekana, na timu ilikua ipasavyo. Wakati fulani, ni wakati wa kuanzisha rasmi mchakato wa ujumuishaji wa nambari. Iliamuliwa kutumia mtiririko wa Git.

Wazo la mtiririko wa Git linajulikana sana: mradi una tawi moja la kawaida la kukuza, na kwa kila kipengele kipya, watengenezaji hukata tawi tofauti, kujitolea, kushinikiza, na wanapotaka kuunganisha nambari zao kwenye tawi la kukuza, fungua a. ombi la kuvuta. Ili kushiriki maarifa na kujadili mbinu, tulianzisha ukaguzi wa msimbo, yaani, wafanyakazi wenzetu lazima waangalie na kuthibitisha msimbo wa kila mmoja wao.

Hundi

Kuona nambari kwa macho yako ni nzuri, lakini haitoshi. Kwa hiyo, hundi za moja kwa moja zinaanzishwa.

Kwanza kabisa, tunaangalia Mkutano wa ARK.
Mengi ya Vipimo vya Junit.
Tunazingatia chanjo ya nambari, kwa kuwa tunaendesha majaribio.

Ili kuelewa jinsi hundi hizi zinapaswa kuendeshwa, hebu tuangalie mchakato wa maendeleo katika Avito.

Inaweza kuwakilishwa kimkakati kama hii:

Msanidi programu anaandika msimbo kwenye kompyuta yake ndogo. Unaweza kuendesha ukaguzi wa ujumuishaji hapa - ama kwa ndoano ya ahadi, au endesha tu ukaguzi nyuma.
Baada ya msanidi programu kusukuma msimbo, anafungua ombi la kuvuta. Ili msimbo wake ujumuishwe katika tawi la kuendeleza, ni muhimu kupitia ukaguzi wa kanuni na kukusanya idadi inayotakiwa ya uthibitisho. Unaweza kuwezesha ukaguzi na kujenga hapa: hadi muundo wote ufanikiwe, ombi la kuvuta haliwezi kuunganishwa.
Baada ya ombi la kuvuta limeunganishwa na msimbo umejumuishwa katika kuendeleza, unaweza kuchagua wakati unaofaa: kwa mfano, usiku, wakati seva zote ziko huru, na kukimbia hundi nyingi kama unavyopenda.

Hakuna mtu aliyependa kuendesha skana kwenye kompyuta yake ndogo. Msanidi programu anapomaliza kipengele, anataka kukisukuma haraka na kufungua ombi la kuvuta. Ikiwa kwa wakati huu hundi za muda mrefu zimezinduliwa, hii sio tu ya kupendeza sana, lakini pia hupunguza kasi ya maendeleo: wakati kompyuta ya mkononi inaangalia kitu, haiwezekani kufanya kazi kwa kawaida juu yake.

Tulipenda sana kufanya ukaguzi usiku, kwa sababu kuna muda mwingi na seva, unaweza kuzurura. Lakini, kwa bahati mbaya, msimbo wa kipengele unapoanza kutengenezwa, msanidi anakuwa na motisha ndogo sana ya kurekebisha makosa ambayo CI ilipata. Mara kwa mara nilijikuta nikifikiria nilipoangalia makosa yote yaliyopatikana katika ripoti ya asubuhi kwamba ningeyarekebisha siku moja baadaye, kwa sababu sasa kuna kazi mpya nzuri huko Jira ambayo ninataka tu kuanza kuifanya.

Ikiwa hundi huzuia ombi la kuvuta, basi kuna motisha ya kutosha, kwa sababu mpaka kujenga kugeuka kijani, msimbo hautaingia katika kuendeleza, ambayo ina maana kwamba kazi haitakamilika.

Kama matokeo, tulichagua mkakati ufuatao: tunaendesha seti ya juu zaidi ya ukaguzi usiku, na kuzindua muhimu zaidi kati yao na, muhimu zaidi, zile za haraka sana kwenye ombi la kuvuta. Lakini hatuashi hapo—sambamba, tunaboresha kasi ya ukaguzi ili kuzihamisha kutoka kwa hali ya usiku ili kuvuta ukaguzi wa ombi.

Wakati huo, miundo yetu yote ilikamilishwa haraka sana, kwa hivyo tulijumuisha tu muundo wa ARK, vipimo vya Junit na hesabu za chanjo ya msimbo kama kizuizi cha ombi la kuvuta. Tuliiwasha, tukaifikiria, na tukaachana na uwekaji wa msimbo kwa sababu tulifikiri kwamba hatukuihitaji.

Ilituchukua siku mbili kusanidi kabisa CI ya msingi (baadaye makadirio ya wakati ni makadirio, yanahitajika kwa kiwango).

Baada ya hapo, tulianza kufikiria zaidi - je, tunaangalia kwa usahihi? Je, tunaendesha ujenzi kwa ombi la kuvuta kwa usahihi?

Tulianza ujenzi kwenye ahadi ya mwisho ya tawi ambalo ombi la kuvuta lilifunguliwa. Lakini majaribio ya ahadi hii yanaweza tu kuonyesha kwamba nambari ambayo msanidi aliandika inafanya kazi. Lakini hawathibitishi kwamba hakuvunja chochote. Kwa kweli, unahitaji kuangalia hali ya tawi la kukuza baada ya kipengele kuunganishwa ndani yake.

Ili kufanya hivyo, tuliandika hati rahisi ya bash premerge.sh:

#!/usr/bin/env bash

set -e

git fetch origin develop

git merge origin/develop

Hapa mabadiliko yote ya hivi punde kutoka kwa ukuzaji yanavutwa tu na kuunganishwa kwenye tawi la sasa. Tuliongeza hati ya premerge.sh kama hatua ya kwanza katika ujenzi wote na tukaanza kuangalia kile tunachotaka, ambayo ni. ushirikiano.

Ilichukua siku tatu kubinafsisha tatizo, kutafuta suluhu, na kuandika hati hii.

Programu iliendelezwa, kazi zaidi na zaidi zilionekana, timu ilikua, na premerge.sh wakati mwingine ilianza kutuangusha. Kuendeleza kulikuwa na mabadiliko yanayokinzana ambayo yalivunja muundo.

Mfano wa jinsi hii inavyotokea:

Watengenezaji wawili kwa wakati mmoja huanza kufanyia kazi vipengele A na B. Msanidi wa kipengele A hugundua kipengele ambacho hakijatumika katika mradi. answer() na, kama skauti mzuri wa mvulana, huiondoa. Wakati huo huo, msanidi wa kipengele B anaongeza simu mpya kwa kazi hii katika tawi lake.

Watengenezaji humaliza kazi yao na kufungua ombi la kuvuta kwa wakati mmoja. Miundo imezinduliwa, premerge.sh hukagua maombi yote mawili kuhusu hali ya hivi punde ya ukuzaji - ukaguzi wote ni wa kijani. Baada ya hayo, ombi la kuvuta la kipengele A limeunganishwa, ombi la kuvuta la kipengele B limeunganishwa ... Boom! Tengeneza mapumziko kwa sababu msimbo wa usanidi una simu kwa chaguo la kukokotoa ambalo halipo.

Wakati si kwenda kuendeleza, ni maafa ya ndani. Timu nzima haiwezi kukusanya chochote na kuwasilisha kwa majaribio.

Ilifanyika kwamba mara nyingi nilifanya kazi kwenye kazi za miundombinu: uchanganuzi, mtandao, hifadhidata. Hiyo ni, ni mimi ambaye niliandika kazi hizo na madarasa ambayo watengenezaji wengine hutumia. Kwa sababu ya hili, nilijikuta katika hali kama hizo mara nyingi sana. Hata nilikuwa na picha hii kuning'inia kwa muda.

Kwa kuwa hii haikufaa, tulianza kuchunguza chaguzi za jinsi ya kuzuia hili.

Jinsi si kuvunja kuendeleza

Chaguo la kwanza: jenga upya maombi yote ya kuvuta wakati wa kusasisha kuendeleza. Ikiwa, katika mfano wetu, ombi la kuvuta na kipengele A ni la kwanza kujumuishwa katika kuendeleza, ombi la kuvuta la kipengele B litajengwa upya, na, ipasavyo, hundi zitashindwa kwa sababu ya kosa la mkusanyiko.

Ili kuelewa ni muda gani hii itachukua, fikiria mfano na PR mbili. Tunafungua PR mbili: mbili hujenga, hundi mbili za hundi. Baada ya PR ya kwanza kuunganishwa katika kuendeleza, ya pili inahitaji kujengwa upya. Kwa jumla, PR mbili zinahitaji ukaguzi tatu: 2 + 1 = 3.

Kimsingi, ni sawa. Lakini tuliangalia takwimu, na hali ya kawaida katika timu yetu ilikuwa PRs 10 wazi, na kisha idadi ya hundi ni jumla ya maendeleo: 10 + 9 +... + 1 = 55. Hiyo ni, kukubali 10. PRs, unahitaji kujenga upya mara 55. Na hii ni katika hali nzuri, wakati ukaguzi wote unapita mara ya kwanza, wakati hakuna mtu anayefungua ombi la ziada la kuvuta wakati dazeni hizi zinachakatwa.

Jifikirie kama msanidi programu ambaye anahitaji kuwa wa kwanza kubofya kitufe cha "unganisha", kwa sababu ikiwa jirani atafanya hivi, basi itabidi usubiri hadi ujenzi wote upitie tena ... Hapana, hiyo haitafanya kazi. , itapunguza kasi ya maendeleo.

Njia ya pili inayowezekana: kukusanya maombi ya kuvuta baada ya ukaguzi wa msimbo. Hiyo ni, unafungua ombi la kuvuta, kukusanya idadi inayotakiwa ya vibali kutoka kwa wenzake, kurekebisha kile kinachohitajika, na kisha uzindua hujenga. Ikiwa zimefaulu, ombi la kuvuta linaunganishwa katika ukuzaji. Katika kesi hii, hakuna kuanza tena kwa ziada, lakini maoni yanapungua sana. Kama msanidi programu, ninapofungua ombi la kuvuta, mara moja nataka kuona ikiwa itafanya kazi. Kwa mfano, ikiwa jaribio linashindwa, unahitaji kurekebisha haraka. Katika kesi ya kujenga kuchelewa, maoni hupungua, na kwa hiyo maendeleo yote. Hili pia halikufaa.

Kama matokeo, chaguo la tatu pekee lilibaki - kuendesha baiskeli. Nambari zetu zote, vyanzo vyetu vyote vimehifadhiwa kwenye hazina kwenye seva ya Bitbucket. Ipasavyo, tulilazimika kuunda programu-jalizi ya Bitbucket.

Programu-jalizi hii inabatilisha utaratibu wa kuunganisha ombi la kuvuta. Mwanzo ni wa kawaida: PR inafungua, makusanyiko yote yanazinduliwa, ukaguzi wa kanuni umekamilika. Lakini baada ya ukaguzi wa msimbo kukamilika na msanidi anaamua kubofya "unganisha", hundi ya programu-jalizi ambayo hali ya ukaguzi iliendeshwa. Ikiwa usanidi umesasishwa baada ya ujenzi, programu-jalizi haitaruhusu ombi kama hilo la kuvuta kuunganishwa kwenye tawi kuu. Itaanza tena ujenzi wa maendeleo ya hivi karibuni.

Katika mfano wetu na mabadiliko yanayokinzana, miundo kama hii itashindwa kwa sababu ya kosa la mkusanyiko. Ipasavyo, msanidi wa kipengele B atalazimika kusahihisha msimbo, kuanzisha upya ukaguzi, kisha programu-jalizi itatumia ombi la kuvuta kiotomatiki.

Kabla ya kutekeleza programu-jalizi hii, tulifanya wastani wa mapitio 2,7 kwa kila ombi la kuvuta. Pamoja na programu-jalizi kulikuwa na uzinduzi 3,6. Hii ilitufaa.

Inafaa kumbuka kuwa programu-jalizi hii ina shida: inaanza tena ujenzi mara moja. Hiyo ni, bado kuna dirisha ndogo ambalo mabadiliko yanayopingana yanaweza kuingia katika kuendeleza. Lakini uwezekano wa hili ni mdogo, na tulifanya biashara hii kati ya idadi ya kuanza na uwezekano wa kushindwa. Katika miaka miwili ilifukuzwa mara moja tu, kwa hivyo labda haikuwa bure.

Ilituchukua wiki mbili kuandika toleo la kwanza la programu-jalizi ya Bitbucket.

Hundi mpya

Wakati huo huo, timu yetu iliendelea kukua. Hundi mpya zimeongezwa.

Tulifikiri: kwa nini kufanya makosa ikiwa yanaweza kuzuiwa? Na ndio maana walitekeleza uchambuzi wa kanuni tuli. Tulianza na lint, ambayo imejumuishwa kwenye SDK ya Android. Lakini wakati huo hakujua jinsi ya kufanya kazi na nambari ya Kotlin hata kidogo, na tayari tulikuwa na 75% ya maombi yaliyoandikwa huko Kotlin. Kwa hivyo, zilizojengwa ziliongezwa kwa pamba Hundi za Android Studio.

Ili kufanya hivyo, tulilazimika kufanya upotoshaji mwingi: kuchukua Studio ya Android, kuipakia kwenye Docker na kuiendesha kwenye CI na mfuatiliaji wa kawaida, ili ifikirie kuwa inaendesha kwenye kompyuta ya kweli. Lakini ilifanya kazi.

Ilikuwa pia wakati huu ambapo tulianza kuandika mengi vipimo vya vifaa na kutekelezwa jaribio la picha ya skrini. Huu ndio wakati picha ya skrini ya marejeleo inatolewa kwa mwonekano mdogo tofauti, na jaribio linajumuisha kuchukua picha ya skrini kutoka kwenye mwonekano na kuilinganisha na pikseli ya kawaida moja kwa moja kwa pikseli. Ikiwa kuna kutofautiana, inamaanisha kuwa mpangilio umeenda vibaya mahali fulani au kitu kibaya katika mitindo.

Lakini majaribio ya ala na vipimo vya picha za skrini vinahitaji kuendeshwa kwenye vifaa: kwenye emulators au kwenye vifaa halisi. Kwa kuzingatia kwamba kuna vipimo vingi na vinaendeshwa mara kwa mara, shamba zima linahitajika. Kuanzisha kilimo chako mwenyewe ni kazi ngumu sana, kwa hivyo tumepata chaguo ambalo tayari limetengenezwa - Firebase Test Lab.

Maabara ya Majaribio ya Firebase

Ilichaguliwa kwa sababu Firebase ni bidhaa ya Google, kumaanisha kwamba inafaa kutegemewa na hakuna uwezekano wa kufa. Bei ni nzuri: $ 5 kwa saa ya uendeshaji wa kifaa halisi, 1 $ kwa saa ya uendeshaji wa emulator.

Ilichukua takriban wiki tatu kutekeleza Maabara ya Majaribio ya Firebase kwenye CI yetu.

Lakini timu iliendelea kukua, na Firebase, kwa bahati mbaya, ikaanza kutuangusha. Wakati huo, hakuwa na SLA yoyote. Wakati fulani Firebase ilitufanya tusubiri hadi nambari inayohitajika ya vifaa iwe bila malipo kwa majaribio, na hatukuanza kuvitekeleza mara moja, kama tulivyotaka. Kusubiri kwenye mstari kulichukua hadi nusu saa, ambayo ni muda mrefu sana. Majaribio ya ala yaliendeshwa kwa kila PR, ucheleweshaji ulipunguza kasi ya maendeleo, na kisha muswada wa kila mwezi ukaja na jumla ya pande zote. Kwa ujumla, iliamuliwa kuachana na Firebase na kufanya kazi ndani ya nyumba, kwani timu ilikuwa imekua vya kutosha.

Docker + Python + bash

Tulichukua Docker, tukaingiza emulators ndani yake, tukaandika programu rahisi katika Python, ambayo kwa wakati unaofaa huleta idadi inayotakiwa ya emulators katika toleo linalohitajika na kuwazuia inapohitajika. Na, kwa kweli, maandishi kadhaa ya bash - tungekuwa wapi bila wao?

Ilichukua wiki tano kuunda mazingira yetu ya majaribio.

Kama matokeo, kwa kila ombi la kuvuta kulikuwa na orodha kubwa ya kuzuia-kuunganisha ya hundi:

mkusanyiko wa ARK;
Vipimo vya Junit;
Lint;
hundi za Android Studio;
Uchunguzi wa vyombo;
Vipimo vya picha za skrini.

Hii ilizuia uharibifu mwingi unaowezekana. Kitaalam kila kitu kilifanya kazi, lakini watengenezaji walilalamika kuwa kusubiri kwa matokeo ni muda mrefu sana.

Muda gani ni mrefu sana? Tulipakia data kutoka Bitbucket na TeamCity kwenye mfumo wa uchanganuzi na tukagundua hilo wastani wa kusubiri dakika 45. Hiyo ni, msanidi programu, wakati wa kufungua ombi la kuvuta, anasubiri wastani wa dakika 45 kwa matokeo ya kujenga. Kwa maoni yangu, hii ni mengi, na huwezi kufanya kazi kama hiyo.

Bila shaka, tuliamua kuharakisha ujenzi wetu wote.

Hebu tuongeze kasi

Kuona kwamba hujenga mara nyingi husimama kwenye foleni, jambo la kwanza tunalofanya ni kununuliwa vifaa zaidi - maendeleo ya kina ni rahisi zaidi. Majengo yaliacha kupanga foleni, lakini muda wa kusubiri ulipungua kidogo tu, kwa sababu baadhi ya hundi zenyewe zilichukua muda mrefu sana.

Kuondoa hundi zinazochukua muda mrefu sana

Muunganisho wetu Unaoendelea unaweza kupata aina hizi za hitilafu na matatizo.

Si kwenda. CI inaweza kupata hitilafu ya mkusanyiko wakati kitu hakijengi kwa sababu ya mabadiliko yanayokinzana. Kama nilivyokwisha sema, basi hakuna mtu anayeweza kukusanya chochote, maendeleo yanasimama, na kila mtu anapata woga.
Mdudu katika tabia. Kwa mfano, wakati programu imejengwa, lakini huanguka unapobonyeza kitufe, au kifungo hakijasisitizwa kabisa. Hii ni mbaya kwa sababu hitilafu kama hiyo inaweza kufikia mtumiaji.
Hitilafu katika mpangilio. Kwa mfano, kitufe kinabofya, lakini kimesogeza pikseli 10 upande wa kushoto.
Kuongezeka kwa deni la kiufundi.

Baada ya kuangalia orodha hii, tuligundua kwamba ni pointi mbili za kwanza tu ambazo ni muhimu. Tunataka kupata shida kama hizo kwanza. Hitilafu katika mpangilio hugunduliwa katika hatua ya uhakiki wa muundo na zinaweza kusahihishwa kwa urahisi wakati huo. Kushughulikia deni la kiufundi kunahitaji mchakato tofauti na kupanga, kwa hivyo tuliamua kutojaribu kwa ombi la kuvuta.

Kulingana na uainishaji huu, tulitikisa orodha nzima ya hundi. Lint iliyovuka na kuahirisha uzinduzi wake hadi usiku: ili tu itoe ripoti juu ya shida ngapi katika mradi huo. Tulikubali kufanya kazi tofauti na deni la kiufundi, na Ukaguzi wa Studio ya Android uliachwa kabisa. Studio ya Android katika Docker ya kufanya ukaguzi inasikika ya kufurahisha, lakini husababisha shida nyingi katika usaidizi. Usasishaji wowote wa matoleo ya Studio ya Android unamaanisha kupambana na hitilafu zisizoeleweka. Pia ilikuwa vigumu kuunga mkono vipimo vya skrini, kwa sababu maktaba haikuwa imara sana na kulikuwa na chanya za uwongo. Majaribio ya picha za skrini yameondolewa kwenye orodha ya kuteua.

Kama matokeo, tuliachwa na:

mkusanyiko wa ARK;
Vipimo vya Junit;
Vipimo vya zana.

Kache ya mbali ya Gradle

Bila ukaguzi mzito, kila kitu kilikuwa bora. Lakini hakuna kikomo kwa ukamilifu!

Programu yetu ilikuwa tayari imegawanywa katika moduli 150 za taratibu. Cache ya mbali ya Gradle kawaida hufanya kazi vizuri katika kesi hii, kwa hivyo tuliamua kuijaribu.

Akiba ya kijijini ya Gradle ni huduma inayoweza kuweka akiba ya mabaki ya kazi za kibinafsi katika moduli za kibinafsi. Gradle, badala ya kuunda msimbo, hutumia HTTP kugonga kache ya mbali na kuuliza ikiwa kuna mtu tayari amefanya kazi hii. Ikiwa ndio, inapakua tu matokeo.

Kuendesha kashe ya mbali ya Gradle ni rahisi kwa sababu Gradle hutoa picha ya Docker. Tulifanikiwa kufanya hivi kwa saa tatu.

Ulichopaswa kufanya ni kuzindua Docker na kuandika mstari mmoja kwenye mradi huo. Lakini ingawa inaweza kuzinduliwa haraka, itachukua muda mwingi kwa kila kitu kufanya kazi vizuri.

Chini ni kache hukosa grafu.

Mwanzoni kabisa, asilimia ya misses ya cache ilikuwa karibu 65. Baada ya wiki tatu, tuliweza kuongeza thamani hii hadi 20%. Ilibadilika kuwa kazi ambazo programu ya Android hukusanya zina utegemezi wa ajabu wa mpito, kwa sababu ambayo Gradle alikosa kache.

Kwa kuunganisha cache, tuliharakisha sana kujenga. Lakini pamoja na kusanyiko, pia kuna vipimo vya vifaa, na huchukua muda mrefu. Labda sio vipimo vyote vinahitaji kuendeshwa kwa kila ombi la kuvuta. Ili kujua, tunatumia uchambuzi wa athari.

Uchambuzi wa athari

Kwa ombi la kuvuta, tunakusanya git diff na kupata moduli za Gradle zilizobadilishwa.

Inaeleweka kuendesha tu majaribio ya ala ambayo huangalia moduli zilizobadilishwa na moduli zote zinazozitegemea. Hakuna maana katika kuendesha vipimo kwa moduli za jirani: msimbo hapo haujabadilika na hakuna kitu kinachoweza kuvunja.

Kwa majaribio ya vifaa, sio kila kitu ni rahisi sana, kwa sababu lazima ziwe kwenye moduli ya kiwango cha juu cha Maombi. Tulitumia heuristics na uchanganuzi wa bytecode ili kuelewa kila jaribio ni la moduli gani.

Kusasisha utendakazi wa majaribio ya ala ili zijaribu tu moduli zinazohusika kulichukua takriban wiki nane.

Hatua za kuharakisha ukaguzi zimefanya kazi kwa mafanikio. Kutoka dakika 45 tulikwenda hadi karibu 15. Tayari ni kawaida kusubiri robo ya saa kwa ajili ya kujenga.

Lakini sasa watengenezaji wameanza kulalamika kwamba hawaelewi ni ujenzi gani unazinduliwa, wapi kuona logi, kwa nini jengo ni nyekundu, ni mtihani gani ulishindwa, nk.

Matatizo ya maoni hupunguza kasi ya ukuzaji, kwa hivyo tulijaribu kutoa maelezo wazi na ya kina kuhusu kila PR na kuunda iwezekanavyo. Tulianza na maoni katika Bitbucket kwa PR, ikionyesha ni muundo gani umeshindwa na kwa nini, na tukaandika ujumbe uliolengwa katika Slack. Mwishowe, tuliunda dashibodi ya PR ya ukurasa iliyo na orodha ya miundo yote ambayo inaendeshwa kwa sasa na hali yake: iliyopangwa, kukimbia, kuanguka au kukamilika. Unaweza kubofya kwenye kujenga na kupata logi yake.

Wiki sita zilitumika kwa maoni ya kina.

Mipango

Wacha tuendelee kwenye historia ya hivi karibuni. Baada ya kusuluhisha suala la maoni, tulifikia kiwango kipya - tuliamua kujenga shamba letu la kuiga. Wakati kuna vipimo vingi na emulators, ni vigumu kusimamia. Kwa hivyo, waigizaji wetu wote walihamia kwenye nguzo ya k8s yenye usimamizi rahisi wa rasilimali.

Kwa kuongeza, kuna mipango mingine.

Rudia Mwanga (na uchambuzi mwingine tuli). Tayari tunafanya kazi katika mwelekeo huu.
Endesha kila kitu kwenye kizuizi cha PR vipimo vya mwisho hadi mwisho kwenye matoleo yote ya SDK.

Kwa hiyo, tumefuatilia historia ya maendeleo ya Ushirikiano wa Kuendelea katika Avito. Sasa nataka kutoa ushauri kutoka kwa mtazamo wa uzoefu.

Советы

Ikiwa ningeweza kutoa ushauri mmoja tu itakuwa hivi:

Tafadhali kuwa mwangalifu na maandishi ya ganda!

Bash ni zana inayobadilika sana na yenye nguvu, ni rahisi sana na haraka kuandika maandishi. Lakini unaweza kuanguka kwenye mtego nayo, na, kwa bahati mbaya, tulianguka ndani yake.

Yote ilianza na maandishi rahisi ambayo yaliendeshwa kwenye mashine zetu za ujenzi:

#!/usr/bin/env bash
./gradlew assembleDebug

Lakini, kama unavyojua, kila kitu hukua na kuwa ngumu zaidi kwa wakati - wacha tuendeshe hati moja kutoka kwa nyingine, wacha tupitishe vigezo kadhaa hapo - mwisho ilibidi tuandike kazi ambayo huamua ni kwa kiwango gani cha bash nesting sisi ni sasa ili. kuingiza nukuu muhimu, ili kuanza yote.

Unaweza kufikiria gharama za kazi kwa ajili ya maendeleo ya scripts vile. Nakushauri usiingie kwenye mtego huu.

Ni nini kinachoweza kubadilishwa?

Lugha yoyote ya uandishi. Andika kwa Hati ya Python au Kotlin rahisi zaidi kwa sababu ni programu, sio maandishi.
Au eleza mantiki yote ya ujenzi katika fomu Kazi maalum za taratibu kwa mradi wako.

Tuliamua kuchagua chaguo la pili, na sasa tunafuta kwa utaratibu hati zote za bash na kuandika kazi nyingi za taratibu maalum.

Kidokezo #2: Hifadhi miundombinu katika msimbo.

Ni rahisi wakati mpangilio wa Ujumuishaji Unaoendelea hauhifadhiwa kwenye kiolesura cha UI cha Jenkins au TeamCity, n.k., lakini katika mfumo wa faili za maandishi moja kwa moja kwenye hazina ya mradi. Hii inatoa uwezo wa kubadilika. Haitakuwa vigumu kurejesha au kuunda msimbo kwenye tawi lingine.

Maandishi yanaweza kuhifadhiwa katika mradi. Nini cha kufanya na mazingira?

Kidokezo #3: Docker inaweza kusaidia na mazingira.

Hakika itasaidia watengenezaji wa Android; iOS haina moja bado, kwa bahati mbaya.

Huu ni mfano wa faili rahisi ya docker ambayo ina jdk na android-sdk:

FROM openjdk:8

ENV SDK_URL="https://dl.google.com/android/repository/sdk-tools-linux-3859397.zip" 
    ANDROID_HOME="/usr/local/android-sdk" 
    ANDROID_VERSION=26 
    ANDROID_BUILD_TOOLS_VERSION=26.0.2

# Download Android SDK
RUN mkdir "$ANDROID_HOME" .android 
    && cd "$ANDROID_HOME" 
    && curl -o sdk.zip $SDK_URL 
    && unzip sdk.zip 
    && rm sdk.zip 
    && yes | $ANDROID_HOME/tools/bin/sdkmanager --licenses

# Install Android Build Tool and Libraries
RUN $ANDROID_HOME/tools/bin/sdkmanager --update
RUN $ANDROID_HOME/tools/bin/sdkmanager "build-tools;${ANDROID_BUILD_TOOLS_VERSION}" 
    "platforms;android-${ANDROID_VERSION}" 
    "platform-tools"

RUN mkdir /application
WORKDIR /application

Baada ya kuandika faili hii ya Docker (nitakuambia siri, sio lazima uandike, lakini vuta tu iliyotengenezwa tayari kutoka kwa GitHub) na kukusanya picha, unapata mashine ya kawaida ambayo unaweza kuunda programu. na endesha vipimo vya Junit.

Sababu kuu mbili kwa nini hii ina maana ni scalability na kurudiwa. Kwa kutumia docker, unaweza kuinua haraka mawakala kadhaa wa ujenzi ambao watakuwa na mazingira sawa na ile ya awali. Hii inafanya maisha ya wahandisi wa CI kuwa rahisi sana. Ni rahisi sana kusukuma android-sdk kwenye docker, lakini kwa emulators ni ngumu zaidi: itabidi ufanye kazi kwa bidii kidogo (au pakua iliyokamilishwa kutoka GitHub tena).

Kidokezo cha 4: usisahau kwamba ukaguzi haufanyiki kwa ajili ya ukaguzi, bali kwa watu.

Haraka na, muhimu zaidi, maoni wazi ni muhimu sana kwa watengenezaji: ni nini kilivunja, ni mtihani gani umeshindwa, wapi ninaweza kuona logi ya ujenzi.

Kidokezo #5: Kuwa pragmatiki wakati wa kuunda Ujumuishaji Unaoendelea.

Elewa kwa uwazi ni aina gani za makosa ungependa kuzuia, ni rasilimali ngapi, muda na muda wa kompyuta uko tayari kutumia. Hundi zinazochukua muda mrefu sana, kwa mfano, zinaweza kuahirishwa mara moja. Na wale ambao hawakupata makosa muhimu sana wanapaswa kuachwa kabisa.

Kidokezo #6: Tumia zana zilizotengenezwa tayari.

Kuna makampuni mengi sasa ambayo hutoa CI ya wingu.

Hii ni suluhisho nzuri kwa timu ndogo. Huhitaji kuunga mkono chochote, lipa tu pesa kidogo, tengeneza programu yako na hata endesha majaribio ya utumiaji wa vifaa.

Kidokezo #7: Katika timu kubwa, ufumbuzi wa ndani ni wa faida zaidi.

Lakini mapema au baadaye, wakati timu inakua, suluhisho za ndani zitakuwa na faida zaidi. Kuna tatizo moja katika maamuzi haya. Kuna sheria ya kupungua kwa mapato katika uchumi: katika mradi wowote, kila uboreshaji unaofuata ni ngumu zaidi na inahitaji uwekezaji zaidi na zaidi.

Uchumi hufafanua maisha yetu yote, ikijumuisha Ushirikiano Unaoendelea. Nilijenga ratiba ya gharama za kazi kwa kila hatua ya maendeleo ya Ushirikiano wetu Unaoendelea.

Ni wazi kwamba uboreshaji wowote unazidi kuwa mgumu zaidi. Ukiangalia grafu hii, unaweza kuelewa kuwa Ushirikiano Unaoendelea unahitaji kuendelezwa kulingana na ukuaji wa saizi ya timu. Kwa timu ya watu wawili, kutumia siku 50 kukuza shamba la emulator ya ndani ni wazo la kawaida. Lakini wakati huo huo, kwa timu kubwa, si kufanya Ushirikiano wa Kuendelea wakati wote pia ni wazo mbaya, kwa sababu matatizo ya ushirikiano, kurekebisha mawasiliano, nk. itachukua muda zaidi.

Tulianza na wazo kwamba automatisering inahitajika kwa sababu watu ni ghali, wanafanya makosa na ni wavivu. Lakini watu pia hujiendesha otomatiki. Kwa hiyo, matatizo yote sawa yanatumika kwa automatisering.

Automation ni ghali. Kumbuka ratiba ya kazi.
Linapokuja suala la automatisering, watu hufanya makosa.
Wakati mwingine ni wavivu sana kujiendesha, kwa sababu kila kitu hufanya kazi kwa njia hiyo. Kwa nini kuboresha kitu kingine chochote, kwa nini Ushirikiano huu wote Unaoendelea?

Lakini nina takwimu: makosa hupatikana katika 20% ya makusanyiko. Na hii si kwa sababu watengenezaji wetu huandika msimbo vibaya. Hii ni kwa sababu watengenezaji wana uhakika kwamba ikiwa watafanya makosa fulani, haitaishia katika maendeleo, itanaswa na ukaguzi wa kiotomatiki. Ipasavyo, watengenezaji wanaweza kutumia muda zaidi kuandika msimbo na mambo ya kuvutia, badala ya kuendesha na kujaribu kitu ndani ya nchi.

Fanya Mazoezi ya Ujumuishaji Unaoendelea. Lakini kwa kiasi.

Kwa njia, Nikolai Nesterov sio tu anatoa ripoti nzuri mwenyewe, lakini pia ni mjumbe wa kamati ya programu ProgramuConf na husaidia wengine kuandaa hotuba zenye maana kwa ajili yako. Ukamilifu na manufaa ya programu inayofuata ya mkutano inaweza kutathminiwa na mada katika ratiba. Na kwa maelezo, njoo kwa Infospace mnamo Aprili 22-23.

Chanzo: mapenzi.com

Mageuzi ya CI katika timu ya maendeleo ya simu