Gaur egun, software produktu gehienak taldeka garatzen dira. Talde arrakastatsuaren garapenerako baldintzak diagrama sinple baten moduan irudika daitezke.

Kodea idatzi ondoren, ziurtatu behar duzu:

Работает.
Ez du ezer hausten, zure lankideek idatzitako kodea barne.

Bi baldintzak betetzen badira, arrakastarako bidean zaude. Baldintza hauek erraz egiaztatzeko eta bide errentagarritik ez desbideratzeko, Etengabeko Integrazioa bururatu zitzaigun.

CI lan-fluxu bat da, non zure kodea produktuaren kode orokorrean integratzen duzun ahalik eta gehien. Eta integratzeaz gain, dena funtzionatzen ari den etengabe egiaztatzen duzu. Asko eta askotan egiaztatu behar duzunez, merezi du automatizazioan pentsatzea. Dena eskuz egiaztatu dezakezu, baina ez zenuke egin behar, eta hona hemen zergatik.

Jende maitea. Edozein programatzaileren lan ordu bat garestiagoa da edozein zerbitzariren ordu bat lan egitea baino.
Jendeak akatsak egiten ditu. Hori dela eta, egoerak sor daitezke probak adar okerrean exekutatzen direnean edo probatzaileentzako konpromezu okerra konpilatu denean.
Jendea alferra da. Tarteka, zeregin bat amaitzen dudanean, hauxe sortzen da: “Zer dago egiaztatzeko? Bi lerro idatzi nituen - dena dabil! Uste dut zuetako batzuek ere halako pentsamenduak dituzuela batzuetan. Baina beti egiaztatu behar duzu.

Nola inplementatu eta garatu zen Etengabeko Integrazioa Avito mugikorren garapen-taldean, nola 0-tik 450 konpilazio izatera igaro ziren egunean, eta eraikuntza-makinek egunean 200 ordu muntatzen dituzten, dio Nikolai Nesterovek (nnesterov) CI/CD Android aplikazioaren bilakaera-aldaketa guztietan parte hartzen du.

Istorioa Android komando baten adibidean oinarritzen da, baina planteamendu gehienak iOS-en ere aplikagarriak dira.

Bazen behin pertsona batek Avito Android taldean lan egiten zuen. Definizioz, ez zuen Etengabeko Integraziotik ezer behar: ez zegoen inor integratzeko.

Baina aplikazioa hazi egin zen, gero eta zeregin berri gehiago agertu ziren, eta horren arabera taldea hazi zen. Noizbait, kodea integratzeko prozesu bat formalki ezartzeko garaia da. Git flow erabiltzea erabaki zen.

Git flow-aren kontzeptua ezaguna da: proiektu batek garatzeko adar komun bat du, eta ezaugarri berri bakoitzeko, garatzaileek adar bereizi bat mozten dute, harekin konprometitzen dira, bultzatzen dute eta beren kodea garapen adarrean batu nahi dutenean, ireki bat. tira eskaera. Ezagutza partekatzeko eta planteamenduak eztabaidatzeko, kodearen berrikuspena aurkeztu dugu, hau da, lankideek elkarren kodea egiaztatu eta baieztatu behar dute.

egiaztapen

Kodea begiekin ikustea polita da, baina ez da nahikoa. Hori dela eta, egiaztapen automatikoak sartzen ari dira.

Lehenik eta behin, egiaztatzen dugu ARK batzarra.
Asko Junit probak.
Kode estaldura kontuan hartzen dugu, probak egiten ari garenez.

Egiaztapen hauek nola exekutatu behar diren ulertzeko, ikus dezagun Avito-ko garapen-prozesua.

Horrela irudikatu daiteke eskematikoki:

Garatzaile batek kodea idazten du bere ordenagailu eramangarrian. Integrazio-egiaztapenak exekutatu ditzakezu hemen bertan, bai konpromezuaren kako batekin, edo, besterik gabe, exekutatu egiaztapenak atzeko planoan.
Garatzaileak kodea bultzatu ondoren, tira eskaera bat irekitzen du. Bere kodea garatzeko adarrean sartu ahal izateko, beharrezkoa da kodearen berrikuspena egin eta beharrezko berrespen kopurua biltzea. Hemen egiaztapenak eta eraikuntzak gai ditzakezu: eraikuntza guztiak arrakastatsuak izan arte, tira eskaera ezin da batu.
Pull eskaera batu eta kodea garapenean sartu ondoren, ordu erosoa aukeratu dezakezu: adibidez, gauez, zerbitzari guztiak libre daudenean, eta nahi adina egiaztapen egin.

Inori ez zitzaion gustatzen bere ordenagailu eramangarrian eskaneatzea egitea. Garatzaile batek eginbide bat amaitzen duenean, azkar bultzatu eta tira eskaera bat ireki nahi du. Momentu honetan egiaztapen luze batzuk abiarazten badira, hori ez da oso atsegina izateaz gain, garapena moteltzen du: ordenagailu eramangarria zerbait egiaztatzen ari den bitartean, ezinezkoa da normalean lan egitea.

Asko gustatu zitzaigun gauez egiaztapenak egitea, denbora eta zerbitzari asko daudelako, inguruan ibil zaitezke. Baina, zoritxarrez, funtzio-kodea garatzen denean, garatzaileak askoz motibazio gutxiago du CIk aurkitu dituen akatsak konpontzeko. Goizeko txostenean aurkitutako akats guztiak begiratu nuenean noizbait geroago konponduko nituzkeela pentsatzen harrapatu nuen neure burua, orain Jira-n zeregin berri polit bat dagoelako eta egiten hasi nahi dudana.

Txekeek tira-eskaera bat blokeatzen badute, nahikoa motibazio dago, zeren eta eraikuntzak berde bihurtu arte, kodea ez da garatzen hasiko, eta horrek esan nahi du zeregina ez dela amaituko.

Ondorioz, estrategia hau aukeratu dugu: ahalik eta kontrol sorta handiena egiten dugu gauez, eta horietako kritikoenak abiarazten ditugu eta, batez ere, azkarrenak pull request batean. Baina ez gara hor gelditzen; paraleloan, egiaztapenen abiadura optimizatzen dugu gaueko modutik eskaera egiaztapenak ateratzeko.

Garai hartan, gure eraikuntza guztiak nahiko azkar osatu ziren, beraz, ARK eraikuntza, Junit probak eta kode estaldura kalkuluak sartu genituen tira eskaeraren blokeatzaile gisa. Piztu, pentsatu eta kode estaldura alde batera utzi dugu, ez genuela behar uste genuelako.

Bi egun behar izan genituen oinarrizko CI guztiz konfiguratzeko (aurrerantzean denboraren estimazioa gutxi gorabeherakoa da, eskalarako beharrezkoa).

Horren ostean, gehiago pentsatzen hasi ginen - behar bezala egiaztatzen al dugu? Zuzen exekutatzen ari al gara tira-eskaeretan eraikitzen?

Tire eskaera ireki zen sukurtsalaren azken konpromisoan hasi ginen eraikitzen. Baina konpromiso honen probek garatzaileak idatzitako kodea funtzionatzen duela soilik erakutsi dezakete. Baina ez dute frogatzen ezer hautsi ez zuenik. Izan ere, garapen-adarraren egoera egiaztatu behar duzu ezaugarri bat bertan batu ondoren.

Horretarako, bash script soil bat idatzi dugu premerge.sh:

#!/usr/bin/env bash

set -e

git fetch origin develop

git merge origin/develop

Hemen garapenaren azken aldaketa guztiak atera eta egungo adarrean batzen dira. Premerge.sh script-a gehitu dugu eraikuntza guztietan lehen urrats gisa eta nahi duguna zehazki egiaztatzen hasi gara, hau da. integrazioa.

Hiru egun behar izan dira arazoa lokalizatu, irtenbide bat aurkitzeko eta script hau idazteko.

Aplikazioa garatu, gero eta zeregin gehiago agertzen ziren, taldea hazi zen, eta premerge.sh batzuetan huts egiten hasi zen. Garatzeak aldaketa kontrajarriak izan zituen eraikuntza hautsi zutenak.

Hau gertatzen denaren adibide bat:

Bi garatzaile aldi berean hasten dira A eta B funtzioetan lanean. A funtzioaren garatzaileak erabiltzen ez duen funtzio bat aurkitzen du proiektuan answer() eta, boy scout on batek bezala, kentzen du. Aldi berean, B funtzioaren garatzaileak dei berri bat gehitzen dio funtzio honi bere adarrean.

Garatzaileek beren lana amaitzen dute eta tira eskaera bat irekitzen dute aldi berean. Eraikuntzak abiarazten dira, premerge.sh-ek bi tira-eskaerak egiaztatzen ditu azken garapen-egoerari buruz - egiaztapen guztiak berdeak dira. Horren ostean, A ezaugarriaren tira-eskaera batu egiten da, B funtzioaren tira-eskaera batu egiten da... Boom! Garatu etenaldiak garatzeko kodeak existitzen ez den funtzio baterako deia duelako.

Garatzen ez denean, hala da tokiko hondamendia. Talde osoak ezin du ezer bildu eta probara aurkeztu.

Gertatu zen gehienetan azpiegitura lanetan lan egiten nuela: analitika, sarea, datu-baseak. Hau da, ni izan nintzen beste garatzaile batzuek erabiltzen dituzten funtzio eta klase horiek idatzi zituena. Horregatik, sarritan aurkitzen nintzen antzeko egoeretan. Argazki hau ere zintzilik izan nuen denbora batez.

Hau komeni ez zaigunez, hori saihesteko aukerak aztertzen hasi ginen.

Nola ez hautsi garatzen

Lehenengo aukera: birsortu tira eskaera guztiak garatzen diren eguneratzean. Gure adibidean, A ezaugarria duen pull eskaera garapenean sartzen den lehenengoa bada, B funtzioaren pull eskaera berreraiki egingo da, eta, horren arabera, egiaztapenek huts egingo dute konpilazio-errore baten ondorioz.

Zenbat denbora beharko duen ulertzeko, kontuan hartu bi PRrekin adibide bat. Bi PR irekitzen ditugu: bi eraikuntza, bi egiaztapen. Lehenengo PRa garatzeko batu ondoren, bigarrena berreraiki behar da. Guztira, bi PRek hiru egiaztapen-lanak behar dituzte: 2 + 1 = 3.

Printzipioz, ondo dago. Baina estatistikak aztertu genituen, eta gure taldean egoera tipikoa 10 PR ireki ziren, eta gero kontrol kopurua progresioaren batura da: 10 + 9 +... + 1 = 55. Hau da, 10 onartzea. PR, 55 aldiz berreraiki behar duzu. Eta egoera ezin hobean dago, egiaztapen guztiak lehen aldiz pasatzen direnean, inork ez duenean tira-eskaera gehigarririk irekitzen dozena horiek prozesatzen ari diren bitartean.

Imajinatu zeure burua “Bateatu” botoian sakatzen lehena izan behar duen garatzaile gisa, auzokide batek hau egiten badu, eraikuntza guztiak berriro igaro arte itxaron beharko duzulako... Ez, horrek ez du funtzionatuko. , garapena larri motelduko du.

Bigarren modu posiblea: bildu tira-eskaerak kodea berrikusi ondoren. Hau da, tira-eskaera bat ireki, lankideen behar den onespen-kopurua bildu, behar dena zuzentzen duzu eta, ondoren, eraikuntzak abiarazten dituzu. Arrakasta badute, tira eskaera garapenean batzen da. Kasu honetan, ez dago berrabiarazi gehigarririk, baina feedbacka asko moteltzen da. Garatzaile gisa, tira eskaera bat irekitzen dudanean, berehala ikusi nahi dut funtzionatuko duen. Adibidez, proba batek huts egiten badu, azkar konpondu behar duzu. Atzeratutako eraikuntza baten kasuan, feedbacka moteldu egiten da eta, beraz, garapen osoa. Hau ere ez zitzaigun komeni.

Ondorioz, hirugarren aukera bakarrik geratu zen - bizikleta. Gure kode guztia, gure iturri guztiak Bitbucket zerbitzariko biltegi batean gordetzen dira. Horren arabera, Bitbucket-erako plugin bat garatu behar izan dugu.

Plugin honek tira-eskaerak bateratzeko mekanismoa gainidazten du. Hasiera estandarra da: PR irekitzen da, asanblada guztiak abiarazten dira, kodearen berrikuspena amaitu da. Baina kodearen berrikuspena amaitu eta garatzaileak "bateratu" sakatzea erabaki ondoren, pluginak egiaztatzen du zein garapen-egoera exekutatu diren. Eraikiketen ondoren garapena eguneratu bada, pluginak ez du onartuko tira-eskaera hori adar nagusiarekin bateratzea. Besterik gabe, nahiko berria den garapen baten eraikuntzak berrabiaraziko ditu.

Aldaketa kontrajarriak dituen gure adibidean, konpilazio-errore baten ondorioz huts egingo dute konpilazio horiek. Horren arabera, B funtzioaren garatzaileak kodea zuzendu beharko du, berrabiarazi egiaztapenak, eta gero pluginak automatikoki aplikatuko du pull eskaera.

Plugin hau inplementatu aurretik, tira-eskaera bakoitzeko 2,7 berrikuspen egin genituen batez beste. Pluginarekin 3,6 abiarazi ziren. Hau egokitu zitzaigun.

Kontuan izan behar da plugin honek eragozpen bat duela: behin bakarrik berrabiarazten du eraikuntza. Hau da, badago oraindik leiho txiki bat aldaketa gatazkatsuak garatzeko. Baina hori izateko probabilitatea txikia da, eta abiarazte kopuruaren eta huts egiteko probabilitatearen arteko truke-off hau egin dugu. Bi urtean behin bakarrik tiro egin zuen, beraz, ziurrenik, ez zen alferrik izan.

Bi aste behar izan genituen Bitbucket pluginaren lehen bertsioa idazteko.

Txeke berriak

Bitartean, gure taldea hazten joan zen. Kontrol berriak gehitu dira.

Pentsatu genuen: zergatik egin akatsak ekidin badaitezke? Eta horregatik ezarri zuten kode estatikoen azterketa. Android SDK-n sartzen den lint-ekin hasi ginen. Baina garai hartan ez zekien batere nola lan egin Kotlin kodearekin, eta dagoeneko genuen aplikazioaren %75 Kotlin idatzita. Hori dela eta, barneratuak gehitu zitzaizkion lintetara Android Studio egiaztapenak.

Horretarako, perbertsio asko egin behar izan ditugu: Android Studio hartu, Docker-en paketatu eta monitore birtual batekin CI-n exekutatu, benetako ordenagailu eramangarri batean exekutatzen ari dela pentsa dezan. Baina funtzionatu zuen.

Garai honetan ere asko hasi ginen idazten tresneria probak eta ezarri pantaila-argazkiaren proba. Hau da, erreferentziazko pantaila-argazki bat sortzen da ikuspegi txiki bereizi baterako, eta proba ikuspegitik pantaila-argazkia hartu eta pixelez pixel zuzenean estandarrekin alderatzean datza. Desadostasunik badago, diseinua gaizki joan dela esan nahi du nonbait edo estiloetan zerbait gaizki dagoela.

Baina tresneria-probak eta pantaila-argazki-probak gailuetan egin behar dira: emuladoreetan edo gailu errealetan. Proba asko daudela eta maiz egiten direla kontuan hartuta, baserri oso bat behar da. Zure etxaldea abiaraztea oso lan handia da, beraz, prest egindako aukera bat aurkitu dugu: Firebase Test Lab.

Firebase Test Lab

Firebase Google-ren produktu bat delako aukeratu zen, hau da, fidagarria izan behar duela eta litekeena da inoiz hilko dela. Prezioak arrazoizkoak dira: 5 $ benetako gailu baten funtzionamendu orduko, $ 1 emuladore baten funtzionamendu ordu bakoitzeko.

Hiru aste inguru behar izan ziren Firebase Test Lab gure CIn inplementatzeko.

Baina taldeak hazten jarraitu zuen, eta Firebase, zoritxarrez, usteltzen hasi zen. Garai hartan, ez zuen SLArik. Batzuetan, Firebasek probak egiteko eskatutako gailu kopurua libre egon arte itxaron egiten gintuen eta ez zen berehala exekutatzen hasi, nahi genuen bezala. Ilaran itxaronaldiak ordu erdi iraun zuen, hau da, oso denbora luzea. Tresneria probak PR guztietan egin ziren, atzerapenek benetan moteldu zuten garapena, eta, ondoren, hileroko fakturak batura biribila zuen. Oro har, Firebase alde batera utzi eta etxean lan egitea erabaki zen, taldea nahikoa hazi baitzen.

Docker + Python + bash

Docker hartu genuen, emuladoreak beteta, programa soil bat idatzi genuen Python-en, une egokian behar den emuladore kopurua behar den bertsioan ekartzen duena eta beharrezkoa denean geldiarazten dituena. Eta, noski, bash script pare bat - non egongo ginateke haiek gabe?

Bost aste behar izan ditugu gure proba-ingurune propioa sortzeko.

Ondorioz, tira-eskaera bakoitzeko egiaztapenen bateratze-blokeatzeko zerrenda zabala zegoen:

ARK batzarra;
Junit probak;
Lint;
Android Studio egiaztapenak;
Tresneria-probak;
Pantaila-argazkien probak.

Horrek matxura posible asko ekidin zituen. Teknikoki dena funtzionatu zuen, baina garatzaileek emaitzen itxaronaldia luzeegia zela salatu zuten.

Zenbat denbora luzeegia da? Bitbucket eta TeamCity-ko datuak analisi sistemara igo genituen eta horretaz konturatu ginen batez besteko itxaronaldia 45 minutu. Hau da, garatzaile batek, tira-eskaera bat irekitzean, batez beste 45 minutu itxaroten ditu eraikuntza-emaitzak lortzeko. Nire ustez, hau asko da, eta ezin duzu horrela lan egin.

Jakina, gure eraikuntza guztiak bizkortzea erabaki genuen.

Azkartu dezagun

Eraikuntzak sarritan ilaran jartzen direla ikusita, egiten dugun lehenengo gauza da hardware gehiago erosi — garapen zabala da errazena. Eraikitzek ilaran jartzeari utzi zioten, baina itxaron-denbora apur bat murriztu zen, egiaztapen batzuek beraiek oso denbora luzea izan zutelako.

Luzeegi irauten duten egiaztapenak kentzen

Gure etengabeko integrazioak akats eta arazo mota hauek har ditzake.

Ez joango. CI-k konpilazio-errore bat har dezake aldaketa gatazkatsuen ondorioz zerbait eraikitzen ez denean. Esan bezala, orduan inork ezin du ezer muntatu, garapena gelditzen da eta denak urduri jartzen dira.
Portaeran akatsa. Adibidez, aplikazioa eraikitzen denean, baina botoi bat sakatzean huts egiten du, edo botoia batere sakatzen ez denean. Hau txarra da, horrelako akats bat erabiltzailearengana hel daitekeelako.
Akatsa diseinuan. Adibidez, botoi bat sakatzen da, baina 10 pixel mugitu ditu ezkerrera.
Zor teknikoa handitzea.

Zerrenda hau aztertu ondoren, lehen bi puntuak soilik kritikoak direla konturatu ginen. Lehenik eta behin, horrelako arazoak harrapatu nahi ditugu. Diseinuaren akatsak diseinu-berrikuspen fasean aurkitzen dira eta orduan erraz zuzendu daitezke. Zor teknikoari aurre egiteko prozesu eta plangintza bereizi bat behar da, beraz, tira eskaera batean ez probatzea erabaki genuen.

Sailkapen horretan oinarrituta, txekeen zerrenda osoa astindu genuen. Lint markatua eta egun batetik bestera atzeratu zuen abian jartzea: proiektuan zenbat arazo zeuden txostena egin zezan. Zor teknikoarekin aparte lan egitea adostu genuen, eta Android Studio-ren egiaztapenak erabat utzi ziren. Ikuskapenak egiteko Docker-eko Android Studio interesgarria dirudi, baina arazo asko eragiten ditu laguntzan. Android Studio bertsioen eguneratzeak akats ulertezinekin borrokatzea esan nahi du. Pantaila-argazkien probak onartzea ere zaila zen, liburutegia ez zelako oso egonkorra eta positibo faltsuak zeudelako. Pantaila-argazkiaren probak kontrol-zerrendatik kendu dira.

Ondorioz, hauek geratu ginen:

ARK batzarra;
Junit probak;
Tresneria-probak.

Gradle urruneko cachea

Kontrol handirik gabe, dena hobetu zen. Baina ez dago perfekzioaren mugarik!

Gure aplikazioa jada 150 graduko modulutan banatuta zegoen. Gradle urruneko cacheak ondo funtzionatzen du kasu honetan, beraz, probatzea erabaki dugu.

Gradle urruneko cachea modulu indibidualetan zeregin indibidualetarako eraikitzeko artefaktuak gorde ditzakeen zerbitzua da. Gradlek, kodea benetan konpilatu beharrean, HTTP erabiltzen du urruneko cachea kolpatzeko eta norbaitek zeregin hori egin duen ala ez galdetzeko. Baiezkoa bada, emaitza deskargatu besterik ez du egiten.

Gradle urruneko cachea exekutatzen erraza da Gradle-k Docker irudi bat eskaintzen duelako. Hiru ordutan lortu dugu hau egitea.

Egin behar zenuen guztia Docker abiarazi eta proiektuan lerro bat idaztea zen. Baina azkar abiarazi daitekeen arren, denbora asko beharko da dena ondo funtzionatzeko.

Jarraian, cachearen hutsegiteen grafikoa dago.

Hasieran, cache hutsen ehunekoa 65 ingurukoa zen. Hiru asteren buruan, balio hori % 20ra igotzea lortu genuen. Android aplikazioak biltzen dituen zereginek mendekotasun iragankor bitxiak dituztela ikusi zen, eta horregatik Gradlek cachea galdu zuen.

Cachea konektatuz, asko bizkortu dugu eraikuntza. Baina muntaketaz gain, tresneria probak ere badaude, eta denbora luzea izaten dute. Agian ez dira proba guztiak exekutatu behar tira-eskaera bakoitzerako. Jakiteko, eraginaren analisia erabiltzen dugu.

Eraginaren analisia

Pull-eskaeran, git diff biltzen dugu eta Gradle modulu aldatuak aurkitzen ditugu.

Zentzuzkoa da aldatutako moduluak eta horien menpe dauden modulu guztiak egiaztatzen dituzten tresneria probak bakarrik egitea. Alboko moduluetarako probak egiteak ez du balio: han kodea ez da aldatu eta ezin da ezer hautsi.

Tresneria-probak ez dira hain sinpleak, goi-mailako Aplikazio-moduluan kokatu behar baitira. Bytecode analisiarekin heuristikoak erabili ditugu proba bakoitza zein moduluri dagokion ulertzeko.

Tresneriaren proben funtzionamendua berritzea, inplikatutako moduluak soilik probatu ahal izateko, zortzi aste inguru behar izan zituen.

Ikuskapenak bizkortzeko neurriek arrakastaz funtzionatu dute. 45 minututik 15 ingurura igo ginen. Dagoeneko normala da ordu laurden bat itxarotea eraikuntza baterako.

Baina orain garatzaileak kexatzen hasi dira ez dutela ulertzen zein eraikuntza abiarazten diren, non ikusi erregistroa, zergatik den eraikuntza gorria, zein probak huts egin duen, etab.

Iritziarekin lotutako arazoek garapena moteltzen dute, beraz, PR bakoitzari eta eraikitzen ahalik eta informazio argi eta zehatzena ematen saiatu gara. Bitbucket-en iruzkinekin hasi ginen PR-ra, zein eraikuntzak huts egin zuen eta zergatik adieraziz, eta zuzendutako mezuak idatzi genituen Slack-en. Azkenean, orrialderako PR panel bat sortu genuen, une honetan exekutatzen ari diren eraikuntza guztien zerrenda eta haien egoerarekin: ilaran, martxan, huts egin edo amaituta. Eraikuntzan klik egin eta bere erregistrora joan zaitezke.

Sei aste eman ziren iritzi zehatzak jasotzen.

Planak

Goazen historia hurbilera. Iritzi-arazoa konponduta, maila berri batera iritsi ginen: gure emulatzaile baserria eraikitzea erabaki genuen. Proba eta emuladore asko daudenean, zaila da kudeatzea. Ondorioz, gure emuladore guztiak k8s klusterera eraman ziren baliabideen kudeaketa malguarekin.

Horrez gain, beste plan batzuk ere badaude.

Itzuli Lint (eta beste analisi estatiko batzuk). Dagoeneko ildo horretan ari gara lanean.
Exekutatu dena PR blokeatzaile batean amaierako probak SDK bertsio guztietan.

Beraz, Aviton Etengabeko Integrazioaren garapenaren historia egin dugu. Orain aholku batzuk eman nahi ditut esperientziadun ikuspuntutik.

Советы

Aholku bakarra emango banu, hau izango litzateke:

Kontuz ibili shell scriptekin!

Bash oso tresna malgua eta indartsua da, oso erosoa eta azkarra da gidoiak idazteko. Baina harekin tranpa batean erori zaitezke, eta, tamalez, bertan erori ginen.

Guztia gure eraikuntza-makinetan exekutatzen ziren script sinpleekin hasi zen:

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

Baina, dakizuenez, dena garatu eta konplikatu egiten da denborarekin - exekuta ditzagun script bat beste batetik, pasa ditzagun parametro batzuk hor - azkenean bash habia zein mailatan gauden zehazten duen funtzio bat idatzi behar izan dugu orain. beharrezko komatxoak sartzeko, dena hasteko.

Imajina dezakezue horrelako gidoiak garatzeko lan-kostuak. Aholkatzen dizut tranpa honetan ez erortzeko.

Zer ordezkatu daiteke?

Edozein gidoi hizkuntza. Idatzi Python edo Kotlin Script erosoagoa programazioa delako, ez gidoiak.
Edo deskribatu inprimakian eraikitze-logika guztia Graduko zeregin pertsonalizatuak zure proiekturako.

Bigarren aukera aukeratzea erabaki genuen, eta orain bash script guztiak sistematikoki ezabatzen ari gara eta pertsonalizatutako gradle zeregin asko idazten ari gara.

2. aholkua: gorde azpiegitura kodean.

Erosoa da Etengabeko Integrazio ezarpena ez Jenkins edo TeamCity-ren interfazean eta abarretan gordetzen denean, baizik eta proiektuaren biltegian zuzenean testu-fitxategietan. Horrek bertsioagarritasuna ematen du. Ez da zaila izango kodea beste adar batean atzera egitea edo eraikitzea.

Scriptak proiektu batean gorde daitezke. Zer egin ingurumenarekin?

3. aholkua: Docker-ek ingurumenarekin lagun dezake.

Zalantzarik gabe, Android garatzaileei lagunduko die; iOS-ek ez du oraindik, zoritxarrez.

Hau jdk eta android-sdk dituen docker fitxategi sinple baten adibidea da:

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

Docker fitxategi hau idatzita (sekretu bat kontatuko dizut, ez duzu idatzi beharrik, GitHub-etik prest dagoen tira) eta irudia muntatu ondoren, aplikazioa eraiki dezakezun makina birtual bat lortuko duzu. eta egin Junit probak.

Honek zentzua izateko bi arrazoi nagusiak eskalagarritasuna eta errepikakortasuna dira. Docker erabiliz, aurrekoaren ingurune bera izango duten dozena bat eraikuntza-agente azkar igo ditzakezu. Horrek CI ingeniarien bizitza asko errazten du. Nahiko erraza da Android-sdk dockerra bultzatzea, baina emuladoreekin apur bat zailagoa da: pixka bat gehiago lan egin beharko duzu (edo amaitutakoa GitHub-etik deskargatu berriro).

4. aholkua: ez ahaztu ikuskapenak ez direla ikuskapenen mesedetan egiten, pertsonentzat baizik.

Iritzi azkarra eta, batez ere, argia oso garrantzitsua da garatzaileentzat: zer apurtu den, zer probak huts egin duen, non ikus dezaket buildlog-a.

5. aholkua: Izan pragmatikoa Etengabeko Integrazioa garatzean.

Uler ezazu argi zein motatako akatsak saihestu nahi dituzun, zenbat baliabide, denbora eta ordenagailuko denbora gastatzeko prest zauden. Luzeegi irauten duten egiaztapenak, adibidez, egun batetik bestera atzera daitezke. Eta oso garrantzitsuak ez diren akatsak harrapatzen dituztenak erabat baztertu behar dira.

6. aholkua: Erabili prest egindako tresnak.

Hodeiko CI eskaintzen duten enpresa asko daude orain.

Talde txikientzako irtenbide ona da. Ez duzu ezer lagundu behar, diru apur bat ordaindu, zure aplikazioa eraiki eta instrumentazio probak ere egin behar dituzu.

7. aholkua: talde handi batean, barneko irtenbideak errentagarriagoak dira.

Baina lehenago edo beranduago, taldea hazi ahala, barneko soluzioak errentagarriagoak izango dira. Erabaki hauekin arazo bat dago. Ekonomian errentagarritasun txikiagoko lege bat dago: edozein proiektutan, gero eta hobekuntza bakoitza gero eta zailagoa da eta gero eta inbertsio gehiago eskatzen du.

Ekonomiak gure bizitza osoa deskribatzen du, etengabeko integrazioa barne. Gure Etengabeko Integrazioaren garapen-etapa bakoitzerako lan-kostuen egutegia eraiki nuen.

Argi dago edozein hobekuntza gero eta zailagoa dela. Grafiko honi erreparatuz, uler dezakezu Etengabeko Integrazioa taldearen tamainaren hazkuntzaren arabera garatu behar dela. Bi pertsonako talde batentzat, 50 egun pasatzea barne emuladore-baserri bat garatzen ideia kaskarra da. Baina aldi berean, talde handi batentzat, Etengabeko Integrazioa batere ez egitea ere ideia txarra da, integrazio arazoak, komunikazioa konpontzea, etab. are denbora gehiago beharko du.

Automatizazioa beharrezkoa dela ideiarekin hasi ginen, jendea garestia delako, akatsak egiten dituztelako eta alferra delako. Baina jendeak ere automatizatzen du. Beraz, automatizazioari arazo berdinak aplikatzen zaizkio.

Automatizazioa garestia da. Gogoratu lan-egutegia.
Automatizazioari dagokionez, jendeak akatsak egiten ditu.
Batzuetan oso alferra da automatizatzea, dena horrela funtzionatzen duelako. Zergatik hobetu beste ezer, zergatik Etengabeko Integrazio hori guztia?

Baina badaukat estatistikak: akatsak muntaien %20an atzematen dira. Eta hau ez da gure garatzaileek kodea gaizki idazten dutelako. Hau da, garatzaileek ziur daudelako akatsen bat egiten badute, ez dela garatzen amaituko, egiaztapen automatikoek harrapatuko dutela. Horren arabera, garatzaileek denbora gehiago eman dezakete kodea eta gauza interesgarriak idazten, zerbait lokalean exekutatu eta probatzen beharrean.

Etengabeko Integrazioa landu. Baina neurrian.

Bide batez, Nikolai Nesterovek berak txosten bikainak emateaz gain, programa batzordeko kide ere bada. AppsConf eta besteei zuretzako hitzaldi esanguratsuak prestatzen laguntzen die. Hurrengo hitzaldiaren programaren osotasuna eta erabilgarritasuna gaien arabera ebaluatu daitezke ordutegia. Eta xehetasunetarako, zatoz Infospacera apirilaren 22tik 23ra.

Iturria: www.habr.com

CIren bilakaera mugikorren garapen taldean