Í dag eru flestar hugbúnaðarvörur þróaðar í teymum. Skilyrði fyrir árangursríka liðsþróun geta verið táknuð í formi einfaldrar skýringarmyndar.

Þegar þú hefur skrifað kóðann þinn þarftu að ganga úr skugga um að hann:

Работает.
Það brýtur ekki neitt, þar á meðal kóðann sem samstarfsmenn þínir skrifuðu.

Ef bæði skilyrðin eru uppfyllt, þá ertu á leiðinni til árangurs. Til að athuga þessi skilyrði auðveldlega og ekki víkja frá arðbærri leið, komum við upp með Stöðug samþættingu.

CI er verkflæði þar sem þú samþættir kóðann þinn inn í heildarvörukóðann eins oft og mögulegt er. Og þú samþættir ekki bara, heldur athugar líka stöðugt að allt virki. Þar sem þú þarft að athuga mikið og oft, þá er það þess virði að hugsa um sjálfvirkni. Þú getur athugað allt handvirkt, en þú ættir ekki, og hér er ástæðan.

Kæra fólk. Klukkutími af vinnu hvers forritara er dýrari en klukkutími af vinnu hvaða netþjóns sem er.
Fólk gerir mistök. Þess vegna geta aðstæður komið upp þegar prófanir voru keyrðar á röngum útibúi eða rangt commit var safnað saman fyrir prófunaraðila.
Fólk er letilegt. Af og til, þegar ég klára verkefni, vaknar þessi hugsun: „Hvað er að athuga? Ég skrifaði tvær línur - allt virkar! Ég held að sum ykkar hafi líka stundum slíkar hugsanir. En þú ættir alltaf að athuga.

Hvernig Continuous Integration var innleitt og þróað í Avito farsímaþróunarteymi, hvernig þau fóru úr 0 í 450 smíði á dag og að smíðisvélar settust saman 200 klukkustundir á dag, segir Nikolai Nesterov (nesterov) er þátttakandi í öllum þróunarbreytingum á CI/CD Android forritinu.

Sagan er byggð á dæmi um Android skipun, en flestar aðferðirnar eiga einnig við á iOS.

Einu sinni vann einn aðili í Avito Android teyminu. Samkvæmt skilgreiningu þurfti hann ekkert frá Continuous Integration: það var enginn til að samþætta.

En umsóknin stækkaði, fleiri og fleiri ný verkefni birtust og hópurinn stækkaði í samræmi við það. Á einhverjum tímapunkti er kominn tími til að koma á formlegri samþættingarferli kóða. Ákveðið var að nota Git flow.

Hugmyndin um Git flæði er vel þekkt: verkefni hefur eina sameiginlega þróunargrein og fyrir hvern nýjan eiginleika skera þróunaraðilar sér grein, skuldbinda sig til þess, ýta, og þegar þeir vilja sameina kóðann sinn í þróunargreinina, opna draga beiðni. Til að miðla þekkingu og ræða aðferðir, kynntum við endurskoðun kóða, það er að samstarfsmenn verða að athuga og staðfesta kóða hvers annars.

Athuganir

Að sjá kóða með augunum er flott, en ekki nóg. Því er verið að taka upp sjálfvirkar athuganir.

Fyrst af öllu athugum við ARK samkoma.
A einhver fjöldi Junit próf.
Við íhugum kóðaþekju, þar sem við erum að keyra próf.

Til að skilja hvernig þessar athuganir ættu að fara fram skulum við skoða þróunarferlið í Avito.

Það er hægt að tákna það á skýringarmynd eins og þetta:

Verktaki skrifar kóða á fartölvuna sína. Þú getur keyrt samþættingarathuganir hér - annað hvort með commit krók, eða einfaldlega keyrt athuganir í bakgrunni.
Eftir að verktaki hefur ýtt á kóðann opnar hann dráttarbeiðni. Til þess að kóði þess verði innifalinn í þróunargreininni er nauðsynlegt að fara í gegnum kóðaskoðun og safna tilskildum fjölda staðfestinga. Þú getur virkjað athuganir og smíðar hér: þar til allar smíðar hafa heppnast, er ekki hægt að sameina dráttarbeiðnina.
Eftir að dragbeiðnin er sameinuð og kóðinn er innifalinn í þróun geturðu valið hentugan tíma: til dæmis á kvöldin, þegar allir netþjónarnir eru lausir, og keyrt eins margar athuganir og þú vilt.

Engum líkaði að keyra skannar á fartölvunni sinni. Þegar verktaki hefur lokið við eiginleika vill hann ýta á hann fljótt og opna dráttarbeiðni. Ef á þessu augnabliki eru settar í gang nokkrar langar athuganir, er þetta ekki bara ekki mjög skemmtilegt, heldur hægir það einnig á þróuninni: á meðan fartölvan er að athuga eitthvað er ómögulegt að vinna venjulega á því.

Okkur fannst mjög gaman að keyra eftirlit á nóttunni, því það er mikill tími og netþjónar, þú getur reikað um. En því miður, þegar eiginleikakóðinn fer í þróun, hefur verktaki mun minni hvata til að laga villurnar sem CI fann. Ég lenti reglulega í því að hugsa þegar ég skoðaði allar villurnar sem fundust í morgunskýrslunni að ég myndi laga þær einhvern tíma seinna, því núna er flott nýtt verkefni í Jira sem mig langar bara að byrja að gera.

Ef athuganir loka á dráttarbeiðni, þá er næg hvatning, því þar til smíðin verða græn mun kóðinn ekki komast í þróun, sem þýðir að verkefninu verður ekki lokið.

Fyrir vikið völdum við eftirfarandi stefnu: við keyrum hámarks mögulega sett af tékkum á nóttunni og ræsum þau mikilvægustu af þeim og, síðast en ekki síst, hraðskreiðasta á dráttarbeiðni. En við látum ekki staðar numið þar — samhliða fínstillum við hraða athugana til að flytja þær úr næturstillingu til að draga úr beiðni.

Á þeim tíma var öllum smíðum okkar lokið nokkuð fljótt, þannig að við tókum einfaldlega ARK smíðina, Junit próf og kóðaþekjuútreikninga með sem blokka fyrir dragbeiðnina. Við kveiktum á því, hugsuðum um það og hættum að ná yfir kóða vegna þess að við héldum að við þyrftum þess ekki.

Það tók okkur tvo daga að setja algjörlega upp grunn-CI (hér á eftir er tímaáætlunin áætluð, þarf til stærðar).

Eftir það fórum við að hugsa frekar - erum við jafnvel að athuga rétt? Erum við að keyra uppbyggingar á dráttarbeiðnum rétt?

Við hófum bygginguna á síðustu skuldbindingu útibúsins sem dráttarbeiðnin var opnuð frá. En prófanir á þessari skuldbindingu geta aðeins sýnt að kóðinn sem verktaki skrifaði virkar. En þeir sanna ekki að hann hafi ekki brotið neitt. Reyndar þarftu að athuga stöðu þróunarútibúsins eftir að eiginleiki er sameinaður í hana.

Til að gera þetta skrifuðum við einfalt bash handrit premerge.sh:

#!/usr/bin/env bash

set -e

git fetch origin develop

git merge origin/develop

Hér eru allar nýjustu breytingarnar frá þróun einfaldlega dregnar upp og sameinaðar í núverandi útibú. Við bættum premerge.sh handritinu við sem fyrsta skrefi í öllum smíðum og byrjuðum að athuga nákvæmlega hvað við viljum, þ.e. samþættingu.

Það tók þrjá daga að staðsetja vandamálið, finna lausn og skrifa þetta handrit.

Forritið þróaðist, fleiri og fleiri verkefni birtust, hópurinn stækkaði og premerge.sh fór stundum að svíkja okkur. Develop hafði misvísandi breytingar sem brutu bygginguna.

Dæmi um hvernig þetta gerist:

Tveir forritarar byrja samtímis að vinna að eiginleikum A og B. Hönnuður eiginleika A uppgötvar ónotaðan eiginleika í verkefninu answer() og, eins og góður skáti, fjarlægir það. Á sama tíma bætir verktaki eiginleika B nýju símtali við þessa aðgerð í útibúi sínu.

Hönnuðir klára vinnu sína og opna dráttarbeiðni á sama tíma. Byggingarnar eru settar af stað, premerge.sh athugar báðar dráttarbeiðnir varðandi nýjustu þróunarástandið - allar athuganir eru grænar. Eftir það er dráttarbeiðni eiginleika A sameinuð, dragbeiðni eiginleika B sameinuð... Búmm! Þróa hlé vegna þess að þróunarkóði inniheldur símtal í aðgerð sem ekki er til.

Þegar það er ekki að fara að þróast, þá er það staðbundin hörmung. Allt liðið getur ekki safnað neinu og sent það til prófunar.

Það gerðist þannig að ég vann oftast við innviðaverkefni: greiningar, netkerfi, gagnagrunna. Það er, það var ég sem skrifaði þessar aðgerðir og flokka sem aðrir forritarar nota. Vegna þessa lenti ég mjög oft í svipuðum aðstæðum. Ég var meira að segja með þessa mynd hangandi í smá tíma.

Þar sem þetta hentaði okkur ekki fórum við að kanna möguleika á því hvernig mætti koma í veg fyrir þetta.

Hvernig ekki að brjóta þróa

Fyrsta valkosturinn: endurbyggja allar dráttarbeiðnir við uppfærslu þróunar. Ef, í okkar dæmi, er dráttarbeiðnin með eiginleika A sú fyrsta sem er innifalin í þróun, verður dráttarbeiðnin um eiginleika B endurbyggð og í samræmi við það munu athuganir mistakast vegna samsetningarvillu.

Til að skilja hversu langan tíma þetta mun taka skaltu íhuga dæmi með tveimur PR. Við opnum tvö PR: tvö smíði, tvær ávísanir. Eftir að fyrsta PR er sameinað í þróun, þarf að endurbyggja þann seinni. Alls þurfa tveir PR-aðilar að athuga þrjár ferðir: 2 + 1 = 3.

Í grundvallaratriðum er það í lagi. En við skoðuðum tölfræðina og dæmigerð staðan í teyminu okkar var 10 opnir PR og þá er fjöldi athugana summan af framvindunni: 10 + 9 +... + 1 = 55. Það er að samþykkja 10 PRs, þú þarft að endurbyggja 55 sinnum. Og þetta er í kjöraðstæðum, þegar allar athuganir standast í fyrsta skipti, þegar enginn opnar viðbótarupptökubeiðni á meðan þessi tugi eru í vinnslu.

Ímyndaðu þér sjálfan þig sem þróunaraðila sem þarf að vera fyrstur til að smella á „sameina“ hnappinn, því ef nágranni gerir þetta, þá þarftu að bíða þar til allar smíðin fara í gegn aftur... Nei, það mun ekki virka , mun það hægja verulega á þróuninni.

Önnur möguleg leið: safna dráttarbeiðnum eftir yfirferð kóða. Það er, þú opnar dráttarbeiðni, safnar nauðsynlegum fjölda samþykkja frá samstarfsmönnum, leiðréttir það sem þarf og ræsir síðan smíðina. Ef þær ná árangri er dragbeiðnin sameinuð í þróun. Í þessu tilviki eru engar endurræsingar til viðbótar, heldur hægist mjög á endurgjöfinni. Sem verktaki, þegar ég opna dráttarbeiðni, vil ég strax sjá hvort það muni virka. Til dæmis, ef próf mistekst, þarftu að laga það fljótt. Ef um seinkaða byggingu er að ræða hægir á endurgjöf og þar með allri þróuninni. Þetta hentaði okkur ekki heldur.

Þar af leiðandi var aðeins þriðji kosturinn eftir - reiðhjól. Allur kóðinn okkar, allar heimildir okkar eru geymdar í geymslu á Bitbucket þjóninum. Í samræmi við það þurftum við að þróa viðbót fyrir Bitbucket.

Þessi viðbót hnekkir samrunabúnaði fyrir dráttarbeiðni. Upphafið er staðlað: PR opnar, allar samsetningar eru settar af stað, endurskoðun kóða er lokið. En eftir að endurskoðun kóðans er lokið og verktaki ákveður að smella á „sameina“, athugar viðbótin við hvaða þróunarástand eftirlitið var keyrt. Ef þróun hefur verið uppfærð eftir smíðina mun viðbótin ekki leyfa slíkri dráttarbeiðni að sameinast aðalútibúinu. Það mun einfaldlega endurræsa smíði tiltölulega nýlegrar þróunar.

Í dæminu okkar með misvísandi breytingum munu slíkar byggingar mistakast vegna samsetningarvillu. Í samræmi við það, verktaki eiginleika B verður að leiðrétta kóðann, endurræsa athuganir, þá mun viðbótin sjálfkrafa beita dragbeiðninni.

Áður en þessi viðbót var innleidd, vorum við að meðaltali 2,7 endurskoðunarkeyrslur á hverja dráttarbeiðni. Með viðbótinni voru 3,6 kynningar. Þetta hentaði okkur.

Það er athyglisvert að þessi viðbót hefur galli: hún endurræsir bygginguna aðeins einu sinni. Það er, það er enn lítill gluggi þar sem misvísandi breytingar geta þróast. En líkurnar á þessu eru litlar og við gerðum þetta skipting milli fjölda ræsinga og líkinda á bilun. Á tveimur árum var aðeins skotið einu sinni þannig að það var líklega ekki til einskis.

Það tók okkur tvær vikur að skrifa fyrstu útgáfuna af Bitbucket viðbótinni.

Nýjar ávísanir

Á sama tíma hélt teymi okkar áfram að stækka. Nýjum ávísunum hefur verið bætt við.

Við hugsuðum: til hvers að gera mistök ef hægt er að koma í veg fyrir þau? Og þess vegna framkvæmdu þeir statísk kóðagreining. Við byrjuðum á lint, sem er innifalið í Android SDK. En á þeim tíma vissi hann alls ekki hvernig á að vinna með Kotlin kóða og við höfðum þegar skrifað 75% af umsókninni í Kotlin. Þess vegna var innbyggðum bætt við ló Android Studio athuganir.

Til að gera þetta þurftum við að gera mikið af öfuguggum: Taktu Android Studio, pakkaðu því í Docker og keyrðu það á CI með sýndarskjá, svo að það haldi að það sé í gangi á alvöru fartölvu. En það tókst.

Það var líka á þessum tíma sem við fórum að skrifa mikið tækjabúnaðarprófanir og komið til framkvæmda skjáskotsprófun. Þetta er þegar viðmiðunarskjámynd er búin til fyrir aðskilda litla sýn og prófið samanstendur af því að taka skjáskot af skjánum og bera það saman við venjulegan beint pixla fyrir pixla. Ef það er ósamræmi þýðir það að útlitið hefur klikkað einhvers staðar eða eitthvað er rangt í stílunum.

En tækjapróf og skjámyndapróf þarf að keyra á tækjum: á keppinautum eða á raunverulegum tækjum. Miðað við að það er mikið af prófum og þau eru keyrð oft, þarf heilt bú. Að stofna eigin bæ er of vinnufrekt, svo við fundum tilbúinn valkost - Firebase Test Lab.

Firebase prófunarstöð

Það var valið vegna þess að Firebase er Google vara, sem þýðir að hún ætti að vera áreiðanleg og ólíklegt að hún deyi nokkurn tíma. Verðin eru sanngjörn: $ 5 á klukkustund af notkun alvöru tækis, 1 $ á klukkustund af rekstri keppinautar.

Það tók um það bil þrjár vikur að innleiða Firebase Test Lab í CI okkar.

En liðið hélt áfram að stækka og Firebase, því miður, byrjaði að svíkja okkur. Á þeim tíma var hann ekki með neinn SLA. Stundum lét Firebase okkur bíða þar til tilskilinn fjöldi tækja var laus fyrir prófanir og byrjaði ekki að keyra þau strax, eins og við vildum. Bið í röð tók allt að hálftíma, sem er mjög langur tími. Tækjapróf voru keyrð á hverjum PR, tafir hægðu virkilega á þróuninni og svo kom mánaðarreikningurinn með hringupphæð. Almennt var ákveðið að yfirgefa Firebase og vinna innanhúss þar sem teymið hafði stækkað nóg.

Docker + Python + bash

Við tókum Docker, tróðum keppinautum inn í það, skrifuðum einfalt forrit í Python, sem á réttu augnabliki færir upp nauðsynlegan fjölda keppinauta í tilskildri útgáfu og stöðvar þá þegar þörf krefur. Og auðvitað nokkur bash-handrit - hvar værum við án þeirra?

Það tók fimm vikur að búa til okkar eigin prófunarumhverfi.

Fyrir vikið var fyrir hverja dráttarbeiðni víðtækur listi yfir samrunalokandi athuganir:

ARK samkoma;
Junit próf;
Lint;
Android Studio athuganir;
Tækjapróf;
Skjáskotpróf.

Þetta kom í veg fyrir margar hugsanlegar bilanir. Tæknilega virkaði allt, en verktaki kvartaði yfir því að biðin eftir niðurstöðum væri of löng.

Hversu lengi er of langt? Við hlóðum upp gögnum frá Bitbucket og TeamCity inn í greiningarkerfið og áttuðum okkur á því meðalbiðtími 45 mínútur. Það er, þróunaraðili, þegar hann opnar dráttarbeiðni, bíður að meðaltali í 45 mínútur eftir niðurstöðum byggingar. Að mínu mati er þetta mikið og þú getur ekki unnið svona.

Við ákváðum að sjálfsögðu að flýta öllum byggingum okkar.

Við skulum flýta okkur

Þegar við sjáum að byggingar standa oft í biðröð er það fyrsta sem við gerum keypti meiri vélbúnað — víðtæk þróun er einfaldast. Byggingar hættu biðraðir, en biðtíminn minnkaði aðeins, vegna þess að sumar athuganir sjálfar tóku mjög langan tíma.

Að fjarlægja ávísanir sem taka of langan tíma

Stöðug samþætting okkar gæti lent í þessum tegundum villna og vandamála.

Ætla ekki. CI getur lent í samsetningarvillu þegar eitthvað byggist ekki upp vegna misvísandi breytinga. Eins og ég sagði þegar, þá getur enginn sett neitt saman, þróunin hættir og allir verða kvíðin.
Galla í hegðun. Til dæmis, þegar forritið er byggt, en hrynur þegar þú ýtir á hnapp, eða hnappurinn er alls ekki ýtt á. Þetta er slæmt vegna þess að slík villa getur náð til notandans.
Villa í skipulagi. Til dæmis er smellt á hnapp en hann hefur færst 10 pixla til vinstri.
Aukning tæknilegra skulda.

Eftir að hafa skoðað þennan lista komumst við að því að aðeins fyrstu tveir punktarnir eru mikilvægir. Við viljum ná slíkum vandamálum fyrst. Villur í útlitinu uppgötvast á hönnunar-endurskoðunarstigi og þá er auðvelt að leiðrétta þær. Að takast á við tæknilegar skuldir krefst sérstakt ferli og skipulagningu, svo við ákváðum að prófa það ekki á pull beiðni.

Miðað við þessa flokkun hristum við upp allan ávísanalistann. Strikað yfir Lint og frestaði kynningu þess á einni nóttu: bara til að það myndi gefa skýrslu um hversu mörg vandamál voru í verkefninu. Við samþykktum að vinna sérstaklega með tækniskuldina, og Android Studio athuganir voru algjörlega yfirgefnar. Android Studio í Docker til að keyra skoðanir hljómar áhugavert, en veldur miklum vandræðum í stuðningi. Allar uppfærslur á Android Studio útgáfum þýðir baráttu við óskiljanlegar villur. Það var líka erfitt að styðja við skjáskotapróf, vegna þess að bókasafnið var ekki mjög stöðugt og það voru rangar jákvæðar. Skjáskotpróf hafa verið fjarlægð af gátlistanum.

Fyrir vikið stóðum við eftir með:

ARK samkoma;
Junit próf;
Tækjapróf.

Gradle fjarstýring

Án þungra athugana varð allt betra. En það eru engin takmörk fyrir fullkomnun!

Umsókn okkar var þegar skipt upp í um 150 stigaeiningar. Gradle fjarstýringin virkar venjulega vel í þessu tilfelli, svo við ákváðum að prófa það.

Gradle fjarskyndiminni er þjónusta sem getur smíðað gripi í skyndiminni fyrir einstök verkefni í einstökum einingum. Gradle, í stað þess að setja saman kóðann, notar HTTP til að banka á ytri skyndiminni og spyrja hvort einhver hafi þegar framkvæmt þetta verkefni. Ef já, þá halar það einfaldlega niður niðurstöðunni.

Auðvelt er að keyra fjarstýrða skyndiminni Gradle vegna þess að Gradle veitir Docker mynd. Við náðum þessu á þremur tímum.

Allt sem þú þurftir að gera var að ræsa Docker og skrifa eina línu í verkefnið. En þó það sé hægt að setja það fljótt af stað mun það taka töluverðan tíma fyrir allt að virka vel.

Hér að neðan er grafið yfir skyndiminni missir.

Strax í upphafi var hlutfall skyndiminnis mistaka um 65. Eftir þrjár vikur tókst okkur að hækka þetta gildi í 20%. Það kom í ljós að verkefnin sem Android forritið safnar eru með undarlegar breytilegar ósjálfstæði, vegna þess að Gradle missti af skyndiminni.

Með því að tengja skyndiminni flýttum við byggingunni til muna. En auk samsetningar eru einnig tækjaprófanir og þær taka langan tíma. Kannski þarf ekki að keyra öll próf fyrir hverja togbeiðni. Til að komast að því notum við áhrifagreiningu.

Áhrifagreining

Við dragbeiðni söfnum við git diff og finnum breyttu Gradle einingarnar.

Það er skynsamlegt að keyra aðeins tækjaprófanir sem athuga breyttar einingar og allar einingar sem eru háðar þeim. Það þýðir ekkert að keyra próf fyrir nærliggjandi einingar: kóðinn þar hefur ekki breyst og ekkert getur brotnað.

Tækjapróf eru ekki svo einföld, vegna þess að þau verða að vera staðsett í efstu stigi umsóknareiningarinnar. Við notuðum heuristics með bætikóðagreiningu til að skilja hvaða einingu hvert próf tilheyrir.

Það tók um átta vikur að uppfæra rekstur tækjaprófanna þannig að þau prófuðu aðeins þær einingar sem um ræðir.

Aðgerðir til að flýta eftirliti hafa gefist vel. Frá 45 mínútum fórum við upp í um 15. Það er nú þegar eðlilegt að bíða í korter eftir smíði.

En nú eru forritarar farnir að kvarta yfir því að þeir skilji ekki hvaða smíði er verið að hleypa af stokkunum, hvar sé hægt að sjá logann, hvers vegna smíðin er rauð, hvaða próf mistókst o.s.frv.

Vandamál með endurgjöf hægja á þróun, svo við reyndum að veita eins skýrar og ítarlegar upplýsingar um hverja PR og byggingu og mögulegt var. Við byrjuðum á athugasemdum í Bitbucket við PR, sem gaf til kynna hvaða smíði hefði mistekist og hvers vegna, og skrifuðum markviss skilaboð í Slack. Að lokum bjuggum við til PR mælaborð fyrir síðuna með lista yfir allar byggingar sem eru í gangi og stöðu þeirra: í biðröð, í gangi, hrun eða lokið. Þú getur smellt á smíðina og komist í log hennar.

Sex vikur fóru í ítarlegar athugasemdir.

Áætlun

Við skulum halda áfram að nýlegri sögu. Eftir að hafa leyst álitsvandamálið komumst við á nýtt stig - við ákváðum að byggja okkar eigin hermibú. Þegar það eru mörg próf og hermir er erfitt að stjórna þeim. Fyrir vikið fluttu allir hermir okkar yfir í k8s klasann með sveigjanlegri auðlindastjórnun.

Auk þess eru önnur áform.

Skila Lint (og önnur kyrrstöðugreining). Við erum nú þegar að vinna í þessa átt.
Keyra allt á PR blocker próf frá enda til enda á öllum SDK útgáfum.

Þannig að við höfum rakið sögu þróunar stöðugrar samþættingar í Avito. Nú vil ég gefa nokkur ráð frá reyndum sjónarhóli.

Советы

Ef ég gæti gefið aðeins eitt ráð væri það þetta:

Vinsamlegast farðu varlega með skeljaforskriftir!

Bash er mjög sveigjanlegt og öflugt tól, það er mjög þægilegt og fljótlegt að skrifa handrit. En þú getur fallið í gildru með því, og því miður lentum við í því.

Þetta byrjaði allt með einföldum skriftum sem keyrðu á byggingarvélunum okkar:

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

En eins og þú veist, þróast allt og verður flóknara með tímanum - við skulum keyra eitt handrit af öðru, við skulum senda nokkrar breytur þangað - á endanum þurftum við að skrifa fall sem ákvarðar á hvaða stigi bash hreiður við erum núna í röð að setja inn nauðsynlegar tilvitnanir, til að koma þessu öllu af stað.

Þú getur ímyndað þér launakostnaðinn við þróun slíkra handrita. Ég ráðlegg þér að falla ekki í þessa gryfju.

Hvað er hægt að skipta um?

Hvaða forskriftarmál sem er. Skrifaðu til Python eða Kotlin Script þægilegra vegna þess að það er forritun, ekki forskriftir.
Eða lýstu allri byggingarlógíkinni í formi Sérsniðin stigaverkefni fyrir verkefnið þitt.

Við ákváðum að velja seinni valkostinn og nú erum við kerfisbundið að eyða öllum bash forskriftum og skrifa mikið af sérsniðnum stigaverkefnum.

Ábending #2: Geymdu innviði í kóða.

Það er þægilegt þegar stillingin Continuous Integration er geymd ekki í UI viðmóti Jenkins eða TeamCity osfrv., heldur í formi textaskráa beint í verkefnageymslunni. Þetta gefur útgáfumöguleika. Það verður ekki erfitt að afturkalla eða byggja kóðann á annarri grein.

Forskriftir geta verið geymdar í verkefni. Hvað á að gera við umhverfið?

Ábending #3: Docker getur hjálpað til við umhverfið.

Það mun örugglega hjálpa Android forriturum; iOS er ekki með einn ennþá, því miður.

Þetta er dæmi um einfalda docker skrá sem inniheldur jdk og 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

Eftir að hafa skrifað þessa Docker skrá (ég skal segja þér leyndarmál, þú þarft ekki að skrifa hana, heldur bara draga hana tilbúna frá GitHub) og setja saman myndina, færðu sýndarvél sem þú getur byggt forritið á og keyra Junit próf.

Tvær meginástæðurnar fyrir því að þetta er skynsamlegt eru sveigjanleiki og endurtekningarhæfni. Með því að nota docker geturðu fljótt hækkað tugi byggingarefna sem munu hafa nákvæmlega sama umhverfi og það fyrra. Þetta gerir líf CI verkfræðinga miklu auðveldara. Það er frekar auðvelt að ýta Android-sdk inn í docker, en með keppinautum er það aðeins erfiðara: þú verður að vinna aðeins betur (eða hlaða niður fullbúnu frá GitHub aftur).

Ábending nr. 4: ekki gleyma því að skoðanir eru ekki gerðar vegna eftirlits, heldur fyrir fólk.

Fljótleg og, síðast en ekki síst, skýr endurgjöf er mjög mikilvæg fyrir þróunaraðila: hvað bilaði, hvaða próf mistókst, hvar get ég séð byggingarskrána.

Ábending #5: Vertu raunsær þegar þú þróar stöðuga samþættingu.

Skildu greinilega hvaða tegundir villna þú vilt koma í veg fyrir, hversu miklu fjármagni, tíma og tölvutíma þú ert tilbúinn að eyða. Tékka sem taka of langan tíma getur til dæmis verið frestað yfir nótt. Og þeir þeirra sem ná ekki mjög mikilvægum villum ættu að vera algjörlega yfirgefin.

Ráð #6: Notaðu tilbúin verkfæri.

Það eru mörg fyrirtæki núna sem veita skýja-CI.

Þetta er góð lausn fyrir lítil teymi. Þú þarft ekki að styðja neitt, borgaðu bara smá pening, smíðaðu forritið þitt og keyrðu jafnvel tækjapróf.

Ábending #7: Í stóru teymi eru innanhúslausnir arðbærari.

En fyrr eða síðar, eftir því sem teymið stækkar, verða innanhúslausnir arðbærari. Það er eitt vandamál við þessar ákvarðanir. Það er lögmál um minnkandi ávöxtun í hagfræði: í hvaða verkefni sem er er hver síðari umbót erfiðari og erfiðari og krefst sífellt meiri fjárfestingar.

Hagfræði lýsir öllu lífi okkar, þar á meðal stöðugri samþættingu. Ég smíðaði áætlun um launakostnað fyrir hvert þróunarstig stöðugu samþættingarinnar okkar.

Það er ljóst að allar umbætur verða sífellt erfiðari. Þegar þú horfir á þetta graf geturðu skilið að þróa þarf stöðuga samþættingu í samræmi við vöxt teymisins. Fyrir tveggja manna teymi er miðlungs hugmynd að eyða 50 dögum í að þróa innri hermibú. En á sama tíma, fyrir stórt teymi, er það líka slæm hugmynd að gera alls ekki Continuous Integration, vegna þess að samþættingarvandamál, laga samskipti osfrv. það mun taka enn lengri tíma.

Við byrjuðum á þeirri hugmynd að sjálfvirkni sé þörf vegna þess að fólk er dýrt, það gerir mistök og er latur. En fólk gerir líka sjálfvirkt. Þess vegna eiga öll sömu vandamálin við um sjálfvirkni.

Sjálfvirkni er dýr. Mundu vinnuáætlunina.
Þegar kemur að sjálfvirkni gera menn mistök.
Stundum er mjög latur að gera sjálfvirkan, því allt virkar þannig. Af hverju að bæta eitthvað annað, hvers vegna öll þessi stöðuga samþætting?

En ég er með tölfræði: villur finnast í 20% af þingum. Og þetta er ekki vegna þess að verktaki okkar skrifa kóða illa. Þetta er vegna þess að forritarar eru fullvissir um að ef þeir gera einhver mistök, mun það ekki enda í þróun, það verður gripið af sjálfvirkum athugunum. Í samræmi við það geta verktaki eytt meiri tíma í að skrifa kóða og áhugaverða hluti, frekar en að keyra og prófa eitthvað á staðnum.

Æfðu stöðuga samþættingu. En í hófi.

Við the vegur, Nikolai Nesterov gefur ekki bara frábærar skýrslur sjálfur, heldur er hann einnig meðlimur í dagskrárnefndinni AppsConf og hjálpar öðrum að undirbúa innihaldsríkar ræður fyrir þig. Hægt er að meta heilleika og notagildi næstu ráðstefnudagskrár eftir viðfangsefnum í áætlun. Og fyrir frekari upplýsingar, komdu á Infospace 22.-23. apríl.

Heimild: www.habr.com

Þróun CI í farsímaþróunarteymi