Îro, piraniya hilberên nermalavê di tîmê de têne pêşve xistin. Mercên ji bo pêşkeftina tîmê serketî dikare di forma diagramek hêsan de were destnîşan kirin.

Dema ku we koda xwe nivîsand, hûn hewce ne ku wê piştrast bikin:

1. Raboetaet.
2. Ew tiştek naşkîne, tevî koda ku hevkarên we nivîsandine.

Ger her du şert û merc pêk bên, wê demê hûn li ser rêya serkeftinê ne. Ji bo ku em van şertan bi hêsanî kontrol bikin û ji riya bikêr dernekevin, em gihîştin Yekbûna Berdewam.

CI karek e ku hûn koda xwe bi qasî ku gengaz dibe di nav koda hilberê ya giştî de yek dikin. Û hûn ne tenê yekgirtî ne, lê di heman demê de bi domdarî kontrol dikin ku her tişt dixebite. Ji ber ku hûn hewce ne ku pir û pir caran kontrol bikin, hêja ye ku li ser otomatê bifikirin. Hûn dikarin her tiştî bi destan kontrol bikin, lê divê hûn nebin, û li vir çima ye.

• Gelî delal. Saetek xebata her bernamesaz ji saetek xebata her serverek bihatir e.
• Mirov xeletiyan dike. Ji ber vê yekê, dema ku ceribandin li ser şaxek xelet hatine meşandin an jî berpirsiyariya xelet ji bo ceribandinan hatî berhev kirin dibe ku rewş derkeve holê.
• Mirov tembel in. Dem bi dem, gava ku ez karekî diqedînim, ev fikir derdikeve holê: “Çi heye ku meriv kontrol bike? Min du rêz nivîsî - her tişt dixebite! Ez difikirim ku hinek ji we jî carinan fikrên weha hene. Lê divê hûn her gav kontrol bikin.

Yekbûna Berdewam çawa di tîmê pêşkeftina mobîl Avito de hate bicîh kirin û pêşve xistin, ew çawa rojane ji 0-an gihîştin 450 avahî, û ku makîneyên çêkirinê rojê 200 demjimêran kom dikin, dibêje Nikolai Nesterov (nnesterov) beşdarî hemî guhertinên evolusyona serîlêdana CI/CD Android-ê ye.

Çîrok li ser mînakek fermanek Android-ê ye, lê piraniya nêzîkatiyan li ser iOS-ê jî têne sepandin.

Carekê, yek kes di tîmê Avito Android de dixebitî. Ji hêla pênasê ve, hewcedariya wî bi tiştek ji Entegrasyona Berdewam tune bû: Kesek tune ku pê re entegre bibe.

Lê serîlêdan mezin bû, bêtir û bêtir karên nû xuya bûn, û tîm li gorî wê mezin bû. Di hin xalan de, ew dem e ku bi fermî pêvajoyek yekbûna kodê were damezrandin. Biryar hat girtin ku Git flow bikar bînin.

Têgeha herikîna Git baş tê zanîn: projeyek şaxek pêşkeftinê ya hevpar heye, û ji bo her taybetmendiyek nû, pêşdebiran şaxek cûda jê dikin, jê re pabend dibin, dişoxilînin û gava ku ew dixwazin koda xwe di şaxê pêşvebirinê de bikin yek, vekin daxwaza kişandinê. Ji bo parvekirina zanînê û nîqaşkirina nêzîkatiyan, me vekolîna kodê destnîşan kir, ango divê hevkar koda hevdu kontrol bikin û piştrast bikin.

Checks

Dîtina kodê bi çavên xwe xweş e, lê ne bes e. Ji ber vê yekê, kontrolên otomatîk têne kirin.

• Berî her tiştî, em kontrol dikin Meclîsa ARK.
• Gelek testên Junit.
• Em vegirtina kodê dihesibînin, ji ber ku em ceribandinan dimeşînin.

Ji bo ku fêm bikin ka divê ev kontrol çawa werin meşandin, em li pêvajoya pêşkeftinê li Avito binêrin.

Ew dikare bi rengek şematîkî wiha were temsîl kirin:

• Pêşdebirek kodê li ser laptopa xwe dinivîse. Hûn dikarin rast li vir kontrolên entegrasyonê bimeşînin - an bi pêvekek birêkûpêk, an jî bi hêsanî kontrolên li paşîn bimeşînin.
• Piştî ku pêşdebir kodê davêje, ew daxwaznameyek kişandinê vedike. Ji bo ku koda wê di şaxê pêşkeftinê de cih bigire, pêdivî ye ku meriv bi vekolînek kodê derbas bibe û hejmara pejirandina pêwîst berhev bike. Hûn dikarin li vir kontrol û avakirinan çalak bikin: heta ku hemî avahî bi ser nekevin, daxwaza kişandinê nikare were yek kirin.
• Piştî ku daxwaza kişandinê hate yek kirin û kod di pêşdebirinê de tête kirin, hûn dikarin demek xweş hilbijêrin: Mînakî, bi şev, dema ku hemî pêşkêşker belaş in, û bi qasî ku hûn dixwazin kontrol bikin.

Kesî ji şaneyên li ser laptopa xwe hez nekir. Dema ku pêşdebirek taybetmendiyek qedand, ew dixwaze bi lez wê bikişîne û daxwazek kişandinê veke. Ger di vê gavê de hin kontrolên dirêj têne destpêkirin, ev ne tenê ne pir xweş e, lê di heman demê de pêşveçûnê jî hêdî dike: dema ku laptop tiştek kontrol dike, ne gengaz e ku meriv bi gelemperî li ser bixebite.

Me bi rastî ji kontrolên şevê hez kir, ji ber ku gelek dem û server hene, hûn dikarin li dora xwe bigerin. Lê, mixabin, gava ku koda taybetmendiyê pêşve diçe, pêşdebir pir kêmtir motîvasyonek heye ku xeletiyên ku CI dîtiye rast bike. Dema ku min li hemî xeletiyên ku di rapora sibehê de hatine dîtin nihêrî ku ez ê rojek paşê wan rast bikim, min xwe bi periyodîk girt ku ez difikirim ku ez tenê dixwazim dest bi kirina wê bikim.

Ger kontrol daxwazek kişandinê asteng bike, wê hingê motîvasyonek têr heye, ji ber ku heya ku avahî kesk nebin, kod dê nekeve pêşkeftinê, ku tê vê wateyê ku dê peywir biqede.

Wekî encamek, me stratejiya jêrîn hilbijart: em bi şev koma herî zêde ya gengaz ên kontrolê dimeşînin, û ji wan herî krîtîk û ya herî girîng, yên herî bilez li ser daxwazek kişandinê dest pê dikin. Lê em li wir ranawestin - bi paralelî, em leza kontrolê xweştir dikin da ku wan ji moda şevê veguhezînin da ku kontrolên daxwazê ​​bikşînin.

Wê demê, hemî avahiyên me pir zû qediyan, ji ber vê yekê me bi tenê avakirina ARK, ceribandinên Junit û hesabên vegirtina kodê wekî astengkerek ji bo daxwaza kişandinê vekir. Me ew vekir, li ser wê fikirîn, û me dev ji vegirtina kodê berda ji ber ku me difikirî ku em ne hewce ne.

Du roj me girt ku em bi tevahî CI-ya bingehîn saz bikin (li vir şûnda texmîna demê nêzikî ye, ji bo pîvanê hewce ye).

Piştî wê, me dest pê kir ku bêtir bifikirin - gelo em jî rast kontrol dikin? Ma em avakirinan li ser daxwazên kişandinê rast dimeşînin?

Me dest bi avakirina paşîn a şaxa ku daxwaza kişandinê jê hat vekirin, kir. Lê ceribandinên vê komîteyê tenê dikarin nîşan bidin ku koda ku pêşdebir nivîsandiye dixebite. Lê ew îspat nakin ku wî tiştek neşikandiye. Bi rastî, hûn hewce ne ku piştî ku taybetmendiyek di nav wê de were yek kirin, rewşa şaxê pêşkeftinê kontrol bikin.

Ji bo vê yekê, me skrîptek bashek hêsan nivîsî premerge.sh:

#!/usr/bin/env bash

set -e

git fetch origin develop

git merge origin/develop

Li vir hemî guhertinên herî dawî yên ji pêşkeftinê bi hêsanî têne kişandin û di şaxê heyî de têne yek kirin. Me di hemî avahiyan de skrîpta premerge.sh wekî gava yekem lê zêde kir û dest pê kir tam tiştê ku em dixwazin kontrol bikin, yanî pêxistinî.

Sê roj derbas bûn ku pirsgirêkê herêmî bikin, çareseriyek bibînin û vê senaryoyê binivîsin.

Serlêdan pêş ket, bêtir û bêtir peywir xuya bûn, tîmê mezin bû, û premerge.sh carinan dest bi me kir. Develop guherînên nakokî hebûn ku avahî şikand.

Mînakek çawa ev diqewime:

Du pêşdebir bi hevdemî dest bi xebatê dikin li ser taybetmendiyên A û B. Pêşdebirê taybetmendiya A di projeyê de taybetmendiyek nekarandî keşif dike answer() û mîna kurekî baş, wê jê dike. Di heman demê de, pêşdebirê taybetmendiya B di şaxê xwe de bangek nû li vê fonksiyonê zêde dike.

Pêşdebir karê xwe diqedînin û di heman demê de daxwazek kişandinê vedikin. Avakirin têne destpêkirin, premerge.sh hem daxwazên vekişînê yên di derbarê rewşa pêşkeftina herî dawî de kontrol dike - hemî kontrol kesk in. Piştî wê, daxwaza kişandina taybetmendiya A tê yek kirin, daxwaza kişandina taybetmendiya B tê yek kirin... Boom! Pêşveçûn vediqetîne ji ber ku koda pêşvebirinê bangek fonksiyonek neheyî vedihewîne.

Dema ku ew ê pêş nekeve, ew e karesata herêmî. Tevahiya tîmê nikare tiştek berhev bike û ji bo ceribandinê bişîne.

Wusa çêbû ku ez pir caran li ser karên binesaziyê dixebitim: analîtîk, torê, databas. Ango, ez bûm ku ew fonksiyon û çînên ku pêşdebirên din bikar tînin nivîsandin. Ji ber vê yekê, min pir caran xwe di rewşên wekhev de dît. Heta demekê min ev wêne daliqandibû.

Ji ber ku ev ne li gorî me bû, me dest pê kir vebijarkan li ser ka meriv çawa pêşî li vê yekê bigire.

Çawa neşikestin pêşve bibin

Vebijarka yekem: Dema ku nûvekirin pêşve diçe, hemî daxwazên kişandinê ji nû ve ava bikin. Ger, di mînaka me de, daxwaza kişandina bi taybetmendiya A-yê yekem e ku di pêşkeftinê de tête navandin, dê daxwaza kişandina taybetmendiya B ji nû ve were çêkirin, û, li gorî vê yekê, kontrol dê ji ber xeletiyek berhevkirinê têk biçin.

Ji bo ku hûn fêm bikin ka ev ê çiqas dirêj bike, mînakek bi du PR-an re bifikirin. Em du PR-ê vedikin: du avahî, du rêvekirina kontrolê. Piştî ku PR yekem di pêşkeftinê de tê yek kirin, ya duyemîn hewce ye ku ji nû ve were avakirin. Bi tevahî, du PR sê ceribandinên kontrolê hewce dike: 2 + 1 = 3.

Di prensîbê de, ew baş e. Lê me li statîstîkan mêze kir, û rewşa tîpîk di tîmê me de 10 PR-yên vekirî bûn, û dûv re hejmara kontrolan berhevoka pêşkeftinê ye: 10 + 9 +... + 1 = 55. Ango pejirandina 10 PRs, hûn hewce ne ku 55 carî ji nû ve ava bikin. Û ev di rewşek îdeal de ye, dema ku hemî kontrol cara yekem derbas dibin, dema ku ev bi dehan têne pêvajo kirin kes daxwazek kişandina zêde vedike.

Xwe wekî pêşdebirek ku hewce dike ku yekem be ku li ser bişkoka "hevgirtinê" bikirtîne, ji ber ku heke cîranek wiya bike, wê hingê hûn neçar in ku li bendê bimînin heya ku hemî avahî ji nû ve derbas bibin... Na, ew ê nexebite , ew ê bi giranî pêşveçûnê hêdî bike.

Rêbaza gengaz a duyemîn: piştî vekolîna kodê daxwazên kişandinê berhev bikin. Ango, hûn daxwazek kişandinê vedikin, hejmara pejirandî ya ji hevalbendan berhev dikin, ya ku hewce dike rast bikin, û dûv re avakirinan dest pê bikin. Ger ew serketî bin, daxwaza kişandinê di pêşkeftinê de tê yek kirin. Di vê rewşê de, ji nû ve destpêkirina zêde tune, lê bertek pir hêdî dibe. Wekî pêşdebirek, gava ku ez daxwaznameyek kişandinê vedikim, ez tavilê dixwazim bibînim ka ew ê bixebite. Mînakî, heke ceribandinek biserneket, hûn hewce ne ku wê zû rast bikin. Di bûyera avakirina dereng de, bersiv hêdî dibe, û ji ber vê yekê pêşveçûna tevahî. Ev jî li me nedihat.

Di encamê de, tenê vebijarka sêyemîn ma - bike. Hemî koda me, hemî çavkaniyên me di depoyek li ser servera Bitbucket de têne hilanîn. Li gorî vê yekê, me neçar ma ku ji bo Bitbucket pêvekek pêş bixe.

Ev pêvek mekanîzmaya hevgirtinê ya daxwaza kişandinê derbas dike. Destpêk standard e: PR vedibe, hemî meclîs têne destpêkirin, vekolîna kodê qediya. Lê piştî ku vekolîna kodê qediya û pêşdebir biryar da ku li ser "hevgirtinê" bikirtîne, pêvek li hember kîjan dewleta pêşkeftinê kontrol dike kontrol dike. Ger pêşdeçûn piştî avakirinan hate nûve kirin, pêvek dê nehêle ku daxwazek bi vî rengî di şaxê sereke de were yek kirin. Ew ê tenê avahiyên pêşkeftinek nûjen ji nû ve bide destpêkirin.

Di mînaka me de bi guhertinên nakokî re, avahiyên weha dê ji ber xeletiyek berhevkirinê têk biçin. Li gorî vê yekê, pêşdebirê taybetmendiya B dê pêdivî ye ku kodê rast bike, kontrolan ji nû ve bide destpêkirin, wê hingê pêvek dê bixweber daxwaza kişandinê bicîh bîne.

Berî ku em vê pêvekê bicîh bikin, me 2,7 gerîdeyên vekolînê li her daxwazek kişandinê navînî kir. Bi pêvekê re 3,6 dest pê kirin. Ev li gorî me bû.

Hêjayî gotinê ye ku ev pêvek kêmasiyek heye: ew tenê carek avakirinê ji nû ve dest pê dike. Ango, hîn jî pencereyek piçûk heye ku tê de guhertinên nakokî dikarin pêşve bibin. Lê îhtîmala vê kêm e, û me ev danûstandin di navbera hejmara destpêk û îhtîmala têkçûnê de çêkir. Di nav du salan de tenê carekê gulebaran kir, ji ber vê yekê dibe ku ne vala bû.

Du hefte me girt ku em guhertoya yekem a pêveka Bitbucket binivîsin.

Kontrolên nû

Di vê navberê de, tîmê me mezin bû. Kontrolên nû hatine zêdekirin.

Em difikirîn: gelo çima xeletiyan bikin ger dikarin pêşî lê bigirin? Û ji ber vê yekê wan pêk anîn analîza koda statîk. Me bi lintê, ku di SDK-ya Android-ê de cih digire dest pê kir. Lê di wê demê de wî qet nizanibû ku meriv çawa bi koda Kotlin re bixebite, û me jixwe% 75-ê serlêdanê li Kotlin nivîsandibû. Ji ber vê yekê, yên çêkirî li lincê hatin zêdekirin Android Studio kontrol dike.

Ji bo kirina vê yekê, me neçar ma ku gelek xeletiyan bikin: Android Studio bigirin, wê li Docker pak bikin û bi çavdêriyek virtual li ser CI-ê bimeşînin, da ku ew difikire ku ew li ser laptopek rastîn dimeşîne. Lê kar dikir.

Di vê demê de jî me gelek dest bi nivîsandinê kir testên amûrkirinê û pêk anîn testkirina screenshot. Ev gava ku dîmenek referansê ji bo dîmenek piçûk a cihêreng tê çêkirin, û ceribandin ji girtina dîmenek ji dîmenê û berhevkirina wê bi standarda rasterast re pixel-pixel pêk tê. Ger nakokî hebe, ev tê vê wateyê ku sêwirana li cîhek xelet çûye an tiştek di şêwazan de xelet e.

Lê ceribandinên amûrkirinê û ceribandinên dîmenderê hewce ne ku li ser cîhazan bêne xebitandin: li ser emulatoran an li ser cîhazên rastîn. Bihesibînin ku gelek ceribandin hene û ew bi gelemperî têne meşandin, çandiniyek tevahî hewce ye. Destpêkirina çandiniya xwe pir kedkar e, ji ber vê yekê me vebijarkek amade dît - Firebase Test Lab.

Firebase Test Lab

Ew hate hilbijartin ji ber ku Firebase hilberek Google-ê ye, tê vê wateyê ku ew pêbawer be û ne mimkûn e ku qet bimire. Bihayên maqûl in: 5 $ serê saetê xebitandina amûrek rastîn, 1 $ serê demjimêra xebata emûlatorê.

Nêzîkî sê hefte girt ku ceribandina Firebase Test Lab di CI-ya me de bicîh bike.

Lê tîmê mezinbûna xwe berdewam kir, û Firebase, mixabin, dest pê kir ku me bêzar kir. Wê demê tu SLA tunebû. Carinan Firebase me dikir ku em li bendê bimînin heya ku jimara pêdivî ya cîhazan ji bo ceribandinan belaş bibin, û wekî ku me dixwest tavilê dest bi cîbicîkirina wan nekir. Li bendê sekinîn heta nîv saetê dirêj kir, ev demek pir dirêj e. Testên amûrkirinê li ser her PR-ê hatin meşandin, dereng bi rastî pêşkeftinê sist kir, û dûv re fatûreya mehane bi dravê dor hat. Bi gelemperî, biryar hate girtin ku Firebase dev ji Firebase berde û di hundurê xwe de bixebite, ji ber ku tîm têra xwe mezin bû.

Docker + Python + bash

Me Docker girt, emûlatoran daxist nav wê, bernameyek hêsan di Python de nivîsand, ku di wextê rast de di guhertoya pêwîst de hejmara pêwîst a emûlatoran derdixe û gava hewce dike wan disekinîne. Û, bê guman, çend nivîsarên bash - em ê bêyî wan li ku bin?

Pênc hefte girt ku hawîrdora ceribandina xwe biafirînin.

Wekî encamek, ji bo her daxwazek kişandinê navnîşek kontrol-astengkirina berfireh hebû:

• Meclîsa ARK;
• testên Junit;
• Lint;
• Android Studio kontrol dike;
• Testên amûrkirinê;
• testên Screenshot.

Vê yekê rê li ber gelek şikestinên gengaz girt. Ji hêla teknîkî ve her tişt xebitî, lê pêşdebiran gilî kirin ku li benda encaman pir dirêj bû.

Çiqas dirêj e? Me daneyên ji Bitbucket û TeamCity di pergala analîzê de bar kir û fêhm kir dema li benda navînî 45 deqeyan. Ango, pêşdebirek, dema ku daxwazek kişandinê vedike, bi navînî 45 hûrdem li benda encamên çêkirinê dimîne. Bi dîtina min, ev pir e, û hûn nekarin wusa bixebitin.

Bê guman, me biryar da ku em hemî avahiyên xwe bilez bikin.

Em lez bikin

Bi dîtina ku avahî bi gelemperî di dorê de radiwestin, yekem tiştê ku em dikin ev e hardware zêdetir kirî - pêşveçûna berfireh ya herî hêsan e. Avahî li rêzê rawestiyan, lê dema bendê tenê hinekî kêm bû, ji ber ku hin kontrolan bixwe demek pir dirêj girt.

Rakirina kontrolên ku pir dirêj digirin

Yekbûna meya Berdewam dikare van celeb xeletî û pirsgirêkan bigire.

• Naçe. Dema ku tiştek ji ber guhertinên nakokî çênebe, CI dikare xeletiyek berhevkirinê bigire. Wekî ku min berê jî got, wê hingê kes nikare tiştek berhev bike, pêşkeftin disekine, û her kes aciz dibe.
• Di tevgerê de xeletî. Mînakî, dema ku serîlêdan tê çêkirin, lê gava ku hûn bişkokek pêdixin têk diçe, an jî bişkok qet nayê pêl kirin. Ev xirab e ji ber ku xeletiyek wusa dikare bigihîje bikarhêner.
• Di layout de çewtî. Mînakî, bişkokek tê tikandin, lê 10 pixel li çepê bar kiriye.
• Zêdebûna deynê teknîkî.

Piştî ku li vê navnîşê mêze kir, me fêm kir ku tenê du xalên pêşîn krîtîk in. Em dixwazin pêşî li pirsgirêkên wiha bigirin. Çewtiyên di sêwiranê de di qonaxa sêwiranê-vekolînê de têne kifş kirin û wê hingê bi hêsanî têne rast kirin. Danûstandina bi deynê teknîkî pêvajoyek û plansaziyek cûda hewce dike, ji ber vê yekê me biryar da ku em wê li ser daxwazek kişandinê ceribînin.

Li ser bingeha vê dabeşkirinê, me tevahiya navnîşa kontrolê hejand. Xaç kirin Lint û destpêkirina wê di şevekê de taloq kir: tenê ji bo ku ew raporek li ser çend pirsgirêkan di projeyê de amade bike. Me li hev kir ku bi deynê teknîkî cuda bixebitin, û Kontrolên Android Studio bi tevahî hatin berdan. Android Studio li Docker-ê ji bo xebitandina vekolînan balkêş xuya dike, lê di piştgirîyê de dibe sedema gelek tengasiyan. Her nûvekirina guhertoyên Android Studio tê wateya têkoşînek bi xeletiyên nefêmkirî. Di heman demê de piştgirîkirina ceribandinên dîmenderê jî dijwar bû, ji ber ku pirtûkxane ne pir aram bû û erênîyên derewîn hebûn. Testên dîmenê ji navnîşa kontrolê hatine derxistin.

Di encamê de, em bi wan re ma:

• Meclîsa ARK;
• testên Junit;
• Testên amûrkirinê.

Gradle cache dûr

Bê kontrolên giran, her tişt çêtir bû. Lê ti sînorek ji bo kamilbûnê tune!

Serlêdana me jixwe li dora 150 modulên gradle hate dabeş kirin. Cache dûr a Gradle bi gelemperî di vê rewşê de baş dixebite, ji ber vê yekê me biryar da ku em wê biceribînin.

Cache-a dûr a Gradle karûbarek e ku dikare ji bo karên kesane di modulên kesane de destanên çêkirinê cache bike. Gradle, li şûna ku bi rastî kodê berhev bike, HTTP-ê bikar tîne da ku li cache-ya dûr bixe û bipirse gelo kesek berê vî karî kiriye. Ger erê, ew tenê encamê dakêşîne.

Rakirina cache-ya dûr a Gradle hêsan e ji ber ku Gradle wêneyek Docker peyda dike. Me ev yek di sê saetan de kir.

Tiştê ku divê hûn bikin ev bû ku Docker dest pê bikin û yek rêzek di projeyê de binivîsin. Lê her çend ew dikare zû were destpêkirin jî, ji bo ku her tişt baş bixebite dê pir dem bigire.

Li jêr grafika cache winda ye.

Di destpêkê de, rêjeya windabûna cache nêzîkî 65 bû. Piştî sê hefteyan, me karî em vê nirxê bigihînin %20. Derket holê ku peywirên ku serîlêdana Android-ê berhev dike xwedan girêdanên gerguhêz ên ecêb in, ji ber vê yekê Gradle cache winda kir.

Bi girêdana cache, me pir lez da avakirinê. Lê ji bilî meclîsê, testên amûrkirinê jî hene, û ew demek dirêj digire. Dibe ku ne hewce ye ku hemî ceribandin ji bo her daxwazek kişandinê bêne meşandin. Ji bo ku em fêr bibin, em analîza bandorê bikar tînin.

Analîza bandorê

Li ser daxwazek kişandinê, em git cudahiyê berhev dikin û modulên Gradle-ê yên guhertî bibînin.

Aqil e ku meriv tenê ceribandinên amûrkirinê yên ku modulên guheztin û hemî modulên ku bi wan ve girêdayî ne kontrol dikin. Tiştek tune ku ceribandinên ji bo modulên cîran bimeşînin: koda li wir nehatiye guhertin û tiştek nikare bişkîne.

Testên amûrkirinê ne ew qas hêsan in, ji ber ku divê ew di modula Serlêdanê ya asta jorîn de cih bigirin. Me bi analîza bytecode re heurîstîk bikar anî da ku fam bikin ku her ceribandin ji kîjan modulê ye.

Nûvekirina xebata ceribandinên amûrkirinê da ku ew tenê modulên tevlê ceribandin bi qasî heşt hefte girt.

Tedbîrên ji bo lezkirina teftîşan bi serkeftî xebitîne. Ji 45 hûrdeman em çûn dor 15. Jixwe normal e ku meriv çaryek saetekê li benda avahiyekê bimîne.

Lê naha pêşdebiran dest bi giliyê kirine ku ew fêm nakin ka kîjan avahî têne destpêkirin, li ku derê têketinê bibînin, çima avahî sor e, kîjan ceribandin têk çû, hwd.

Pirsgirêkên bi bertek pêşkeftinê hêdî dikin, ji ber vê yekê me hewl da ku di derheqê her PR û avahî de bi qasî ku gengaz agahdariya zelal û berfireh peyda bikin. Me bi şîroveyên li Bitbucket-ê ji PR-ê re dest pê kir, ku destnîşan kir ku kîjan avahî têk çûye û çima, û peyamên armanckirî di Slack de nivîsandin. Di dawiyê de, me dashboardek PR-ê ji bo rûpelê bi navnîşek hemî avahiyên ku niha têne xebitandin û statûya wan çêkir: li rêzê, xebitandin, têkçû an qediya. Hûn dikarin li ser çêkirinê bikirtînin û bigihîjin têketina wê.

Şeş hefte li ser bertekên berfireh derbas bûn.

Plans

Ka em derbasî dîroka nêz bibin. Piştî ku pirsgirêka bersivdayînê çareser kir, em gihîştin astek nû - me biryar da ku em çandiniya xweya emulatorê ava bikin. Gava ku gelek ceribandin û emulator hene, birêvebirina wan dijwar e. Wekî encamek, hemî emulatorên me bi rêveberiya çavkaniyê ya maqûl ve çûn koma k8s.

Li gel vê, planên din jî hene.

• Vegere Lint (û analîzên statîk ên din). Jixwe em di vî warî de dixebitin.
• Her tiştî li ser astengkerek PR-ê bimeşînin testên dawî-to-end li ser hemî guhertoyên SDK.

Ji ber vê yekê, me dîroka pêşveçûna Yekbûna Berdewam li Avito şopand. Niha ez dixwazim hinek şîretan ji nêrînek bi tecrûbe bikim.

Tiştên

Ger ez bikaribim tenê şîretek bidim ew ê ev be:

Ji kerema xwe ji nivîsarên şêlê haydar bin!

Bash amûrek pir maqûl û bi hêz e, nivîsandina senaryoyan pir hêsan û bilez e. Lê hûn dikarin bi wê re bikevin xefikê û mixabin em ketine nav wê.

Hemî bi skrîptên hêsan ên ku li ser makîneyên avakirina me dimeşandin dest pê kir:

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

Lê, wekî ku hûn dizanin, her tişt bi demê re pêş dikeve û tevlihevtir dibe - ka em skrîptekê ji ya din bimeşînin, werin em hin pîvanan li wir derbas bikin - di dawiyê de neçar ma ku fonksiyonek binivîsanda ku diyar dike ku em niha di kîjan astê de hêlîna bashê de ne. ji bo têxistina quotes pêwîst, ji bo ku ew hemû dest pê bike.

Hûn dikarin lêçûnên kedê yên ji bo pêşkeftina nivîsarên weha bifikirin. Ez ji we re şîret dikim ku hûn nekevin vê xefikê.

Çi dikare li şûna?

• Her zimanê nivîsandinê. Binivîsin Python an Kotlin Script hêsantir e ji ber ku ew bername ye, ne nivîsar.
• An jî hemî mantiqa avakirinê di formê de diyar bikin Karên gradle Custom ji bo projeya xwe.

Me biryar da ku vebijarka duyemîn hilbijêrin, û naha em bi rêkûpêk hemî nivîsarên bash jêbirin û gelek karên gradle yên xwerû dinivîsin.

Serişteyek #2: Binesaziya di kodê de hilînin.

Dema ku mîhenga Yekbûna Berdewam ne di navgîniya UI ya Jenkins an TeamCity, hwd., lê di forma pelên nivîsê de rasterast di depoya projeyê de were hilanîn hêsan e. Ev guhertoyê dide. Vegerandin an avakirina kodê li ser şaxek din dê ne dijwar be.

Skrîpt dikarin di projeyekê de werin hilanîn. Bi jîngehê re çi bikin?

Serişte #3: Docker dikare bi jîngehê re bibe alîkar.

Ew ê bê guman alîkariya pêşdebirên Android-ê bike; Mixabin, iOS hîn tune ye.

Ev mînakek pelek docker a hêsan e ku jdk û android-sdk vedihewîne:

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

Piştî nivîsandina vê pelê Docker (ez ê sirekek ji we re bibêjim, ne hewce ye ku hûn wê binivîsin, lê tenê wê ji GitHub-ê amade bikişîne) û wêneyê berhev bikin, hûn makîneyek virtual ya ku hûn dikarin serîlêdanê li ser ava bikin digirin. û testên Junit bimeşînin.

Du sedemên sereke yên ku ev yek watedar dike mezinbûn û dubarebûn in. Bi karanîna docker, hûn dikarin bi lez bi dehan ajanên avakirinê ku dê tam jîngeha heman ya berê hebe rakin. Ev jiyana endezyarên CI-ê pir hêsantir dike. Zehfkirina android-sdk-ê di dokerê de pir hêsan e, lê bi emulatoran re ew hinekî dijwartir e: hûn ê hewce ne ku hinekî dijwartir bixebitin (an jî ya qedandî ji GitHub dîsa dakêşin).

Serişteya Hejmar 4: Ji bîr nekin ku kontrol ne ji bo kontrolê, ji bo mirovan têne kirin.

Bersiva bilez û ya herî girîng, zelal ji bo pêşdebiran pir girîng e: çi şikest, çi ceribandin têk çû, ez dikarim li ku derê buildlogê bibînim.

Serişte #5: Dema ku entegrasyona Berdewam pêş dixin pragmatîk bin.

Eşkere fam bikin ka hûn dixwazin çi celeb xeletiyan asteng bikin, çiqas çavkanî, dem û dema komputerê hûn amade ne ku xerc bikin. Kontrolên ku pir dirêj dibin, dikarin, wek nimûne, di şevekê de werin paşxistin. Û yên ji wan ên ku xeletiyên ne pir girîng digirin divê bi tevahî werin berdan.

Serişteyek #6: Amûrên hazir bikar bînin.

Naha gelek pargîdan hene ku ewr CI peyda dikin.

Ev ji bo tîmên piçûk çareseriyek baş e. Hûn ne hewce ne ku hûn tiştek piştgirî bikin, tenê dravek piçûk bidin, serîlêdana xwe ava bikin û tewra ceribandinên amûrkirinê jî bikin.

Serişte #7: Di tîmek mezin de, çareseriyên hundurîn bikêrtir in.

Lê zû an dereng, her ku tîmê mezin dibe, çareseriyên hundurîn dê bikêrtir bibin. Di van biryaran de yek pirsgirêk heye. Di aboriyê de zagonek kêmbûna vegerê heye: di her projeyekê de, her pêşkeftinek dûv re her ku diçe dijwartir û dijwartir e û bêtir veberhênan hewce dike.

Aborî tevahiya jiyana me, tevî Yekbûna Berdewam, vedibêje. Min ji bo her qonaxa pêşkeftina Yekbûna meya Berdewam bernameyek lêçûnên kedê çêkir.

Eşkere ye ku her pêşketin her ku diçe dijwartir dibe. Li vê grafîkê mêze dikin, hûn dikarin fêm bikin ku Pêwîst e ku Yekbûna Berdewam li gorî mezinbûna mezinahiya tîmê were pêşve xistin. Ji bo tîmek ji du kesan, derbaskirina 50 rojan ji bo pêşxistina çandiniyek emulatorê hundurîn ramanek navîn e. Lê di heman demê de, ji bo tîmek mezin, nekirina întegrasyona Berdewam jî ramanek xirab e, ji ber ku pirsgirêkên entegrasyonê, rastkirina ragihandinê, hwd. ew ê hê bêtir dem bigire.

Me bi wê fikrê dest pê kir ku otomasyon hewce ye ji ber ku mirov biha ne, xeletiyan dikin û tembel in. Lê mirov jî otomatîk dikin. Ji ber vê yekê, hemî heman pirsgirêk ji bo otomatê re derbas dibin.

• Otomasyon biha ye. Bernameya xebatê bi bîr bînin.
• Dema ku dor tê ser otomatê, mirov xeletiyan dikin.
• Carinan pir tembel e ku meriv bixweber bike, ji ber ku her tişt bi vî rengî dixebite. Çima tiştek din çêtir bikin, çima ev hemî Yekbûna Berdewam?

Lê statîstîkên min hene: xeletî di 20% ji civînan de têne girtin. Û ev ne ji ber ku pêşdebirên me kodê xirab dinivîsin. Ev e ji ber ku pêşdebiran pê bawer in ku heke ew hin xeletiyek bikin, ew ê pêşkeftinê neqede, ew ê ji hêla kontrolên otomatîkî ve were girtin. Li gorî vê yekê, pêşdebir dikarin bêtir wextê xwe bi nivîsandina kod û tiştên balkêş derbas bikin, ji bilî xebitandin û ceribandina tiştek herêmî.

Yekbûna Berdewam Pratîk bikin. Lê bi nermî.

Bi awayê, Nikolai Nesterov ne tenê bi xwe raporên mezin dide, lê di heman demê de endamê komîteya bernameyê ye AppsConf û alîkariya kesên din dike ku ji we re axaftinên watedar amade bikin. Temamî û bikêrhatina bernameya konferansa paşîn dikare ji hêla mijarên tê de were nirxandin pîlan. Û ji bo hûrguliyan, di 22-23-ê Avrêlê de werin Infospace.

Source: www.habr.com