Heddiw, mae'r rhan fwyaf o gynhyrchion meddalwedd yn cael eu datblygu mewn timau. Gellir cynrychioli'r amodau ar gyfer datblygiad tîm llwyddiannus ar ffurf diagram syml.

Unwaith y byddwch wedi ysgrifennu eich cod, mae angen i chi sicrhau ei fod:

1. Rаботает.
2. Nid yw'n torri unrhyw beth, gan gynnwys y cod a ysgrifennodd eich cydweithwyr.

Os bodlonir y ddau amod, yna rydych ar y llwybr i lwyddiant. Er mwyn gwirio'r amodau hyn yn hawdd a pheidio â gwyro o'r llwybr proffidiol, fe wnaethom lunio Integreiddio Parhaus.

Llif gwaith yw CI lle rydych chi'n integreiddio'ch cod i'r cod cynnyrch cyffredinol mor aml â phosib. Ac nid yn unig rydych chi'n integreiddio, ond hefyd yn gwirio'n gyson bod popeth yn gweithio. Gan fod angen i chi wirio llawer ac yn aml, mae'n werth meddwl am awtomeiddio. Gallwch wirio popeth â llaw, ond ni ddylech chi, a dyma pam.

• Annwyl bobl. Mae awr o waith unrhyw raglennydd yn ddrytach nag awr o waith unrhyw weinydd.
• Mae pobl yn gwneud camgymeriadau. Felly, gall sefyllfaoedd godi pan gafodd profion eu rhedeg ar y gangen anghywir neu pan luniwyd yr ymrwymiad anghywir ar gyfer profwyr.
• Mae pobl yn ddiog. O bryd i'w gilydd, pan fyddaf yn gorffen tasg, mae'r meddwl yn codi: “Beth sydd yna i'w wirio? Ysgrifennais ddwy linell - mae popeth yn gweithio! Rwy'n meddwl bod gan rai ohonoch hefyd feddyliau o'r fath weithiau. Ond dylech wirio bob amser.

Sut y gweithredwyd a datblygwyd Integreiddio Parhaus yn nhîm datblygu symudol Avito, sut aethant o 0 i 450 adeilad y dydd, a bod peiriannau adeiladu yn ymgynnull 200 awr y dydd, meddai Nikolai Nesterov (nnesterov) yn cymryd rhan yn holl newidiadau esblygiadol y cymhwysiad CI/CD Android.

Mae'r stori yn seiliedig ar yr enghraifft o orchymyn Android, ond mae'r rhan fwyaf o'r dulliau yn berthnasol ar iOS hefyd.

Un tro, roedd un person yn gweithio yn nhîm Avito Android. Yn ôl diffiniad, nid oedd arno angen unrhyw beth o Integreiddio Parhaus: nid oedd unrhyw un i integreiddio ag ef.

Ond tyfodd y cais, ymddangosodd mwy a mwy o dasgau newydd, a thyfodd y tîm yn unol â hynny. Ar ryw adeg, mae'n bryd sefydlu proses integreiddio cod yn fwy ffurfiol. Penderfynwyd defnyddio llif Git.

Mae'r cysyniad o lif Git yn adnabyddus: mae gan brosiect un gangen ddatblygu gyffredin, ac ar gyfer pob nodwedd newydd, mae datblygwyr yn torri cangen ar wahân, yn ymrwymo iddo, yn gwthio, a phan fyddant am uno eu cod i'r gangen ddatblygu, agorwch a cais tynnu. Er mwyn rhannu gwybodaeth a thrafod dulliau gweithredu, fe wnaethom gyflwyno adolygiad cod, hynny yw, rhaid i gydweithwyr wirio a chadarnhau cod ei gilydd.

Sieciau

Mae gweld cod gyda'ch llygaid yn cŵl, ond dim digon. Felly, mae gwiriadau awtomatig yn cael eu cyflwyno.

• Yn gyntaf oll, rydym yn gwirio cynulliad ARCH.
• Llawer Profion Junit.
• Rydym yn ystyried cwmpas y cod, gan ein bod yn cynnal profion.

Er mwyn deall sut y dylid rhedeg y gwiriadau hyn, gadewch i ni edrych ar y broses ddatblygu yn Avito.

Gellir ei gynrychioli yn sgematig fel hyn:

• Mae datblygwr yn ysgrifennu cod ar ei liniadur. Gallwch redeg gwiriadau integreiddio yma - naill ai gyda bachyn ymrwymo, neu yn syml rhedeg sieciau yn y cefndir.
• Ar ôl i'r datblygwr wthio'r cod, mae'n agor cais tynnu. Er mwyn i'w god gael ei gynnwys yn y gangen ddatblygu, mae angen mynd trwy adolygiad cod a chasglu'r nifer ofynnol o gadarnhadau. Gallwch alluogi sieciau ac adeiladau yma: nes bod pob adeiladwaith yn llwyddiannus, ni ellir cyfuno'r cais tynnu.
• Ar ôl i'r cais tynnu gael ei uno a bod y cod wedi'i gynnwys wrth ddatblygu, gallwch ddewis amser cyfleus: er enghraifft, gyda'r nos, pan fydd yr holl weinyddion yn rhad ac am ddim, a rhedeg cymaint o wiriadau ag y dymunwch.

Doedd neb yn hoffi rhedeg sganiau ar eu gliniadur. Pan fydd datblygwr wedi gorffen nodwedd, mae am ei wthio'n gyflym ac agor cais tynnu. Os bydd rhai gwiriadau hir yn cael eu lansio ar hyn o bryd, nid yw hyn nid yn unig yn ddymunol iawn, ond mae hefyd yn arafu datblygiad: tra bod y gliniadur yn gwirio rhywbeth, mae'n amhosibl gweithio arno fel arfer.

Roeddem yn hoff iawn o redeg sieciau yn y nos, oherwydd mae llawer o amser a gweinyddwyr, gallwch grwydro o gwmpas. Ond, yn anffodus, pan fydd y cod nodwedd yn dechrau datblygu, mae gan y datblygwr lawer llai o gymhelliant i drwsio'r gwallau a ddarganfuwyd gan CI. O bryd i'w gilydd fe wnes i ddal fy hun yn meddwl pan edrychais ar yr holl wallau a ddarganfuwyd yn adroddiad y bore y byddwn yn eu trwsio ryw ddydd yn ddiweddarach, oherwydd nawr mae tasg newydd cŵl yn Jira yr wyf am ddechrau ei gwneud.

Os yw gwiriadau'n rhwystro cais tynnu, yna mae digon o gymhelliant, oherwydd nes bod yr adeiladau'n troi'n wyrdd, ni fydd y cod yn dechrau datblygu, sy'n golygu na fydd y dasg yn cael ei chwblhau.

O ganlyniad, fe wnaethom ddewis y strategaeth ganlynol: rydym yn rhedeg y set fwyaf posibl o wiriadau yn y nos, ac yn lansio'r rhai mwyaf beirniadol ohonynt ac, yn bwysicaf oll, y rhai cyflymaf ar gais tynnu. Ond nid ydym yn stopio yno - yn gyfochrog, rydym yn gwneud y gorau o gyflymder gwiriadau er mwyn eu trosglwyddo o'r modd nos i dynnu sieciau cais.

Bryd hynny, cwblhawyd ein holl adeiladau yn eithaf cyflym, felly fe wnaethom gynnwys adeiladu ARK, profion Junit a chyfrifiadau cwmpas cod fel rhwystr ar gyfer y cais tynnu. Fe wnaethon ni ei droi ymlaen, meddwl amdano, a rhoi'r gorau i sylw cod oherwydd ein bod ni'n meddwl nad oedd ei angen arnom.

Cymerodd ddau ddiwrnod i ni sefydlu'r CI sylfaenol yn llwyr (o hyn ymlaen mae'r amcangyfrif amser yn fras, sydd ei angen ar gyfer graddfa).

Ar ôl hynny, dechreuon ni feddwl ymhellach - ydyn ni hyd yn oed yn gwirio'n gywir? A ydym yn rhedeg ceisiadau adeiladu ar dynnu yn gywir?

Dechreuasom adeiladu ar ymrwymiad olaf y gangen yr agorwyd y cais tynnu ohoni. Ond ni all profion o'r ymrwymiad hwn ond dangos bod y cod a ysgrifennodd y datblygwr yn gweithio. Ond nid ydynt yn profi na thorodd efe ddim. Mewn gwirionedd, mae angen i chi wirio cyflwr y gangen ddatblygu ar ôl i nodwedd gael ei huno iddi.

I wneud hyn, fe wnaethon ni ysgrifennu sgript bash syml premerge.sh:

#!/usr/bin/env bash

set -e

git fetch origin develop

git merge origin/develop

Yma mae'r holl newidiadau diweddaraf o ddatblygiad yn cael eu tynnu i fyny a'u huno â'r gangen bresennol. Fe wnaethom ychwanegu'r sgript premerge.sh fel y cam cyntaf ym mhob adeilad a dechrau gwirio'n union yr hyn yr ydym ei eisiau, hynny yw integreiddio.

Cymerodd dri diwrnod i leoleiddio'r broblem, dod o hyd i ateb, ac ysgrifennu'r sgript hon.

Datblygodd y cais, ymddangosodd mwy a mwy o dasgau, tyfodd y tîm, a dechreuodd premerge.sh weithiau ein siomi. Roedd gan Datblygu newidiadau gwrthgyferbyniol a dorrodd yr adeilad.

Enghraifft o sut mae hyn yn digwydd:

Mae dau ddatblygwr ar yr un pryd yn dechrau gweithio ar nodweddion A a B. Mae datblygwr nodwedd A yn darganfod nodwedd nas defnyddiwyd yn y prosiect answer() ac, fel sgowt bachgen da, yn ei ddileu. Ar yr un pryd, mae datblygwr nodwedd B yn ychwanegu galwad newydd i'r swyddogaeth hon yn ei gangen.

Mae datblygwyr yn gorffen eu gwaith ac yn agor cais tynnu ar yr un pryd. Mae'r adeiladau'n cael eu lansio, mae premerge.sh yn gwirio'r ddau gais tynnu ynghylch y cyflwr datblygu diweddaraf - mae pob siec yn wyrdd. Ar ôl hynny, mae cais tynnu nodwedd A yn cael ei uno, mae cais tynnu nodwedd B yn cael ei uno... Boom! Datblygu seibiannau oherwydd bod y cod datblygu yn cynnwys galwad i swyddogaeth nad yw'n bodoli.

Pan nad yw'n mynd i ddatblygu, mae'n trychineb lleol. Ni all y tîm cyfan gasglu unrhyw beth a'i gyflwyno i'w brofi.

Digwyddodd felly fy mod yn gweithio amlaf ar dasgau seilwaith: dadansoddeg, rhwydwaith, cronfeydd data. Hynny yw, fi a ysgrifennodd y swyddogaethau a'r dosbarthiadau hynny y mae datblygwyr eraill yn eu defnyddio. Oherwydd hyn, cefais fy hun mewn sefyllfaoedd tebyg yn aml iawn. Cefais hyd yn oed y llun hwn yn hongian am ychydig.

Gan nad oedd hyn yn addas i ni, fe ddechreuon ni archwilio opsiynau ar sut i atal hyn.

Sut i beidio â thorri datblygu

Yr opsiwn cyntaf: ailadeiladu pob cais tynnu wrth ddiweddaru datblygu. Os, yn ein hesiampl ni, y cais tynnu gyda nodwedd A yw'r cyntaf i'w gynnwys yn y datblygiad, bydd cais tynnu nodwedd B yn cael ei ailadeiladu, ac, yn unol â hynny, bydd y gwiriadau'n methu oherwydd gwall llunio.

I ddeall pa mor hir y bydd hyn yn ei gymryd, ystyriwch enghraifft gyda dau PR. Rydym yn agor dau PR: dau adeiladu, dau rediad o wiriadau. Ar ôl i'r cysylltiadau cyhoeddus cyntaf gael eu huno i ddatblygu, mae angen ailadeiladu'r ail un. Yn gyfan gwbl, mae dau PR yn gofyn am dri rhediad o wiriadau: 2 + 1 = 3.

Mewn egwyddor, mae'n iawn. Ond fe edrychon ni ar yr ystadegau, a'r sefyllfa arferol yn ein tîm oedd 10 PR agored, ac yna nifer y sieciau yw cyfanswm y dilyniant: 10 + 9 +... + 1 = 55. Hynny yw, derbyn 10 Cysylltiadau cyhoeddus, mae angen i chi ailadeiladu 55 gwaith. Ac mae hyn mewn sefyllfa ddelfrydol, pan fydd yr holl wiriadau'n pasio'r tro cyntaf, pan nad oes neb yn agor cais tynnu ychwanegol tra bod y dwsin hyn yn cael eu prosesu.

Dychmygwch eich hun fel datblygwr sydd angen bod y cyntaf i glicio ar y botwm “uno”, oherwydd os bydd cymydog yn gwneud hyn, yna bydd yn rhaid i chi aros nes bod yr holl adeiladau'n mynd drwodd eto... Na, ni fydd hynny'n gweithio , bydd yn arafu datblygiad yn ddifrifol.

Ail ffordd bosibl: casglu ceisiadau tynnu ar ôl adolygu cod. Hynny yw, rydych chi'n agor cais tynnu, yn casglu'r nifer ofynnol o gymeradwyaethau gan gydweithwyr, yn cywiro'r hyn sydd ei angen, ac yna'n lansio'r adeiladau. Os ydynt yn llwyddiannus, mae'r cais tynnu yn cael ei gyfuno i ddatblygu. Yn yr achos hwn, nid oes unrhyw ailgychwyniadau ychwanegol, ond mae'r adborth yn cael ei arafu'n fawr. Fel datblygwr, pan fyddaf yn agor cais tynnu, rwyf am weld ar unwaith a yw'n mynd i weithio. Er enghraifft, os bydd prawf yn methu, mae angen i chi ei drwsio'n gyflym. Yn achos oedi cyn adeiladu, mae adborth yn arafu, ac felly'r datblygiad cyfan. Nid oedd hyn yn ein siwtio ni chwaith.

O ganlyniad, dim ond y trydydd opsiwn oedd ar ôl - beic. Mae ein holl god, ein holl ffynonellau yn cael eu storio mewn ystorfa ar y gweinydd Bitbucket. Yn unol â hynny, roedd yn rhaid i ni ddatblygu ategyn ar gyfer Bitbucket.

Mae'r ategyn hwn yn diystyru'r mecanwaith uno cais tynnu. Mae'r dechrau'n safonol: mae'r cysylltiadau cyhoeddus yn agor, mae pob cynulliad yn cael ei lansio, mae adolygiad cod wedi'i gwblhau. Ond ar ôl i'r adolygiad cod gael ei gwblhau a bod y datblygwr yn penderfynu clicio ar “uno”, mae'r ategyn yn gwirio yn erbyn pa gyflwr datblygu y cynhaliwyd y gwiriadau. Os yw datblygu wedi'i ddiweddaru ar ôl yr adeiladu, ni fydd yr ategyn yn caniatáu i gais tynnu o'r fath gael ei gyfuno â'r brif gangen. Yn syml, bydd yn ailgychwyn adeiladau datblygiad cymharol ddiweddar.

Yn ein hesiampl gyda newidiadau sy'n gwrthdaro, bydd adeiladau o'r fath yn methu oherwydd gwall llunio. Yn unol â hynny, bydd yn rhaid i ddatblygwr nodwedd B gywiro'r cod, ailgychwyn y gwiriadau, yna bydd yr ategyn yn cymhwyso'r cais tynnu yn awtomatig.

Cyn gweithredu'r ategyn hwn, gwnaethom gyfartaledd o 2,7 rhediad adolygu fesul cais tynnu. Gyda'r ategyn roedd 3,6 lansiad. Roedd hyn yn addas i ni.

Mae'n werth nodi bod gan yr ategyn hwn anfantais: dim ond unwaith y mae'n ailgychwyn yr adeiladu. Hynny yw, mae yna ffenestr fach o hyd ar gyfer datblygu newidiadau sy'n gwrthdaro. Ond mae'r tebygolrwydd o hyn yn isel, a gwnaethom y cyfaddawd hwn rhwng nifer y dechreuadau a'r tebygolrwydd o fethiant. Mewn dwy flynedd dim ond unwaith y taniodd, felly mae'n debyg nad oedd yn ofer.

Cymerodd bythefnos i ni ysgrifennu'r fersiwn gyntaf o'r ategyn Bitbucket.

Gwiriadau newydd

Yn y cyfamser, parhaodd ein tîm i dyfu. Mae sieciau newydd wedi'u hychwanegu.

Roeddem yn meddwl: pam gwneud camgymeriadau os gellir eu hatal? A dyna pam y maent yn gweithredu dadansoddiad cod statig. Dechreuon ni gyda lint, sydd wedi'i gynnwys yn y SDK Android. Ond bryd hynny nid oedd yn gwybod sut i weithio gyda chod Kotlin o gwbl, ac roedd gennym eisoes 75% o'r cais wedi'i ysgrifennu yn Kotlin. Felly, ychwanegwyd rhai adeiledig at lint Gwiriadau Stiwdio Android.

I wneud hyn, roedd yn rhaid i ni wneud llawer o wyrdroi: cymryd Android Studio, ei becynnu yn Docker a'i redeg ar CI gyda monitor rhithwir, fel ei fod yn meddwl ei fod yn rhedeg ar liniadur go iawn. Ond fe weithiodd.

Yn ystod y cyfnod hwn hefyd y dechreuon ni ysgrifennu llawer profion offeryniaeth a gweithredu profi sgrinluniau. Dyma pan fydd sgrinlun cyfeirio yn cael ei gynhyrchu ar gyfer golygfa fach ar wahân, ac mae'r prawf yn cynnwys cymryd sgrinlun o'r olygfa a'i gymharu â'r picsel uniongyrchol safonol fesul picsel. Os oes anghysondeb, mae'n golygu bod y gosodiad wedi mynd o'i le yn rhywle neu fod rhywbeth o'i le yn yr arddulliau.

Ond mae angen cynnal profion offeryniaeth a phrofion sgrinluniau ar ddyfeisiau: ar efelychwyr neu ar ddyfeisiau go iawn. O ystyried bod llawer o brofion a'u bod yn cael eu rhedeg yn aml, mae angen fferm gyfan. Mae cychwyn eich fferm eich hun yn rhy llafurddwys, felly daethom o hyd i opsiwn parod - Firebase Test Lab.

Lab Prawf Firebase

Fe'i dewiswyd oherwydd bod Firebase yn gynnyrch Google, sy'n golygu y dylai fod yn ddibynadwy ac yn annhebygol o farw byth. Mae'r prisiau'n rhesymol: $5 yr awr o weithredu dyfais go iawn, 1 $ yr awr o weithredu efelychydd.

Cymerodd tua thair wythnos i weithredu Firebase Test Lab yn ein CI.

Ond parhaodd y tîm i dyfu, a dechreuodd Firebase, yn anffodus, ein siomi. Bryd hynny, nid oedd ganddo unrhyw CLG. Weithiau gwnaeth Firebase inni aros nes bod y nifer gofynnol o ddyfeisiau yn rhad ac am ddim ar gyfer profion, ac ni ddechreuodd eu gweithredu ar unwaith, fel yr oeddem yn dymuno. Roedd aros yn y llinell yn cymryd hyd at hanner awr, sy'n amser hir iawn. Cynhaliwyd profion offeryniaeth ar bob PR, arafodd oedi'r datblygiad, ac yna daeth swm crwn i'r bil misol. Yn gyffredinol, penderfynwyd rhoi'r gorau i Firebase a gweithio'n fewnol, gan fod y tîm wedi tyfu digon.

Dociwr + Python + bash

Fe wnaethon ni gymryd Docker, efelychwyr wedi'u stwffio i mewn iddo, ysgrifennu rhaglen syml yn Python, sydd ar hyn o bryd yn dod â'r nifer gofynnol o efelychwyr i fyny yn y fersiwn ofynnol ac yn eu hatal pan fo angen. Ac, wrth gwrs, cwpl o sgriptiau bash - ble fydden ni hebddyn nhw?

Cymerodd bum wythnos i greu ein hamgylchedd prawf ein hunain.

O ganlyniad, ar gyfer pob cais tynnu roedd rhestr gynhwysfawr o wiriadau blocio uno:

• cynulliad ARCH;
• Profion Junit;
• Lint;
• Gwiriadau Stiwdio Android;
• Profion offeryniaeth;
• Profion sgrinlun.

Roedd hyn yn atal llawer o doriadau posibl. Yn dechnegol, gweithiodd popeth, ond cwynodd y datblygwyr fod yr aros am ganlyniadau yn rhy hir.

Pa mor hir yw rhy hir? Fe wnaethom uwchlwytho data o Bitbucket a TeamCity i'r system ddadansoddi a sylweddoli hynny amser aros cyfartalog o 45 munud. Hynny yw, mae datblygwr, wrth agor cais tynnu, yn aros 45 munud ar gyfartaledd am y canlyniadau adeiladu. Yn fy marn i, mae hyn yn llawer, ac ni allwch weithio felly.

Wrth gwrs, fe benderfynon ni gyflymu ein holl adeiladu.

Gadewch i ni gyflymu

Gweld bod adeiladau yn aml yn sefyll mewn ciw, y peth cyntaf rydyn ni'n ei wneud yw prynu mwy o galedwedd — datblygiad helaeth yw'r symlaf. Adeiladu rhoi'r gorau i giwio, ond mae'r amser aros yn gostwng ychydig yn unig, gan fod rhai gwiriadau eu hunain yn cymryd amser hir iawn.

Dileu sieciau sy'n cymryd gormod o amser

Gallai ein Integreiddio Parhaus ddal y mathau hyn o wallau a phroblemau.

• Ddim yn mynd i. Gall CI ddal gwall crynhoi pan nad yw rhywbeth yn adeiladu oherwydd newidiadau sy'n gwrthdaro. Fel y dywedais eisoes, yna ni all unrhyw un ymgynnull unrhyw beth, mae datblygiad yn stopio, ac mae pawb yn mynd yn nerfus.
• Bug mewn ymddygiad. Er enghraifft, pan fydd y cais yn cael ei adeiladu, ond damweiniau pan fyddwch yn pwyso botwm, neu nid yw'r botwm yn cael ei wasgu o gwbl. Mae hyn yn ddrwg oherwydd gall byg o'r fath gyrraedd y defnyddiwr.
• Bug yn y gosodiad. Er enghraifft, mae botwm yn cael ei glicio, ond mae wedi symud 10 picsel i'r chwith.
• Cynnydd mewn dyled dechnegol.

Ar ôl edrych ar y rhestr hon, sylweddolom mai dim ond y ddau bwynt cyntaf sy'n hollbwysig. Rydym am ddal problemau o'r fath yn gyntaf. Mae bygiau yn y cynllun yn cael eu darganfod yn ystod y cam adolygu dylunio a gellir eu cywiro'n hawdd bryd hynny. Mae delio â dyled dechnegol yn gofyn am broses a chynllunio ar wahân, felly penderfynasom beidio â'i phrofi ar gais tynnu.

Yn seiliedig ar y dosbarthiad hwn, fe wnaethom ysgwyd y rhestr gyfan o wiriadau. Croesi allan Lint a gohirio ei lansiad dros nos: dim ond fel y byddai'n cynhyrchu adroddiad ar faint o broblemau oedd yn y prosiect. Cytunwyd i weithio ar wahân gyda'r ddyled dechnegol, a Rhoddwyd y gorau i wiriadau Android Studio yn llwyr. Mae Android Studio yn Docker ar gyfer cynnal arolygiadau yn swnio'n ddiddorol, ond yn achosi llawer o drafferth yn y gefnogaeth. Mae unrhyw ddiweddariad i fersiynau Android Studio yn golygu brwydr gyda chwilod annealladwy. Roedd hefyd yn anodd cefnogi profion sgrin, oherwydd nid oedd y llyfrgell yn sefydlog iawn ac roedd yna bethau positif ffug. Mae profion sgrinlun wedi'u tynnu o'r rhestr wirio.

O ganlyniad, cawsom ein gadael gyda:

• cynulliad ARCH;
• Profion Junit;
• Profion offeryniaeth.

cache pell Gradle

Heb wiriadau trwm, daeth popeth yn well. Ond nid oes terfyn ar berffeithrwydd!

Rhannwyd ein cais eisoes yn tua 150 o fodiwlau gradle. Mae cache pell Gradle fel arfer yn gweithio'n dda yn yr achos hwn, felly fe benderfynon ni roi cynnig arni.

Mae celc o bell Gradle yn wasanaeth sy'n gallu storio arteffactau adeiladu ar gyfer tasgau unigol mewn modiwlau unigol. Mae Gradle, yn lle llunio'r cod mewn gwirionedd, yn defnyddio HTTP i guro ar y storfa bell a gofyn a yw rhywun eisoes wedi cyflawni'r dasg hon. Os ydyw, yn syml, mae'n lawrlwytho'r canlyniad.

Mae rhedeg celc o bell Gradle yn hawdd oherwydd mae Gradle yn darparu delwedd Docker. Llwyddom i wneud hyn mewn tair awr.

Y cyfan oedd yn rhaid i chi ei wneud oedd lansio Docker ac ysgrifennu un llinell yn y prosiect. Ond er y gellir ei lansio'n gyflym, bydd yn cymryd cryn dipyn o amser i bopeth weithio'n dda.

Isod mae'r graff methiannau cache.

Ar y cychwyn cyntaf, roedd canran y methiannau cache tua 65. Ar ôl tair wythnos, fe wnaethom lwyddo i gynyddu'r gwerth hwn i 20%. Daeth i'r amlwg bod gan y tasgau y mae'r cymhwysiad Android yn eu casglu ddibyniaethau trosiannol rhyfedd, ac oherwydd hynny fe fethodd Gradle y storfa.

Trwy gysylltu'r storfa, fe wnaethom gyflymu'r adeiladu yn fawr. Ond yn ogystal â chynulliad, mae yna hefyd brofion offeryniaeth, ac maen nhw'n cymryd amser hir. Efallai nad oes angen cynnal pob prawf ar gyfer pob cais tynnu. I ddarganfod, rydym yn defnyddio dadansoddiad effaith.

Dadansoddiad effaith

Ar gais tynnu, rydym yn casglu git diff ac yn dod o hyd i'r modiwlau Gradle wedi'u haddasu.

Mae'n gwneud synnwyr i redeg profion offeryniaeth yn unig sy'n gwirio'r modiwlau sydd wedi'u newid a'r holl fodiwlau sy'n dibynnu arnynt. Nid oes unrhyw bwynt rhedeg profion ar gyfer modiwlau cyfagos: nid yw'r cod yno wedi newid ac ni all unrhyw beth dorri.

Nid yw profion offeryniaeth mor syml, oherwydd rhaid eu lleoli yn y modiwl Cymhwysiad lefel uchaf. Fe wnaethom ddefnyddio heuristics gyda dadansoddiad bytecode i ddeall i ba fodiwl y mae pob prawf yn perthyn.

Cymerodd tua wyth wythnos i uwchraddio gweithrediad y profion offeryniaeth fel eu bod yn profi'r modiwlau dan sylw yn unig.

Mae mesurau i gyflymu arolygiadau wedi gweithio'n llwyddiannus. O 45 munud fe aethon ni i fyny i tua 15. Eisoes mae'n arferol aros chwarter awr am adeiladu.

Ond nawr mae datblygwyr wedi dechrau cwyno nad ydyn nhw'n deall pa adeiladau sy'n cael eu lansio, ble i weld y log, pam mae'r adeilad yn goch, pa brawf a fethodd, ac ati.

Mae problemau gydag adborth yn arafu datblygiad, felly fe wnaethom geisio darparu gwybodaeth mor glir a manwl â phosibl am bob cysylltiadau cyhoeddus ac adeiladwaith. Dechreuon ni gyda sylwadau yn Bitbucket i'r PR, yn nodi pa adeiladwaith oedd wedi methu a pham, ac fe wnaethom ysgrifennu negeseuon wedi'u targedu yn Slack. Yn y diwedd, fe wnaethon ni greu dangosfwrdd cysylltiadau cyhoeddus ar gyfer y dudalen gyda rhestr o'r holl adeiladau sy'n rhedeg ar hyn o bryd a'u statws: ciwio, rhedeg, damwain neu orffen. Gallwch glicio ar yr adeilad a chyrraedd ei log.

Treuliwyd chwe wythnos ar adborth manwl.

Cynlluniau

Symudwn ymlaen at hanes diweddar. Ar ôl datrys y mater adborth, fe gyrhaeddon ni lefel newydd - fe benderfynon ni adeiladu ein fferm efelychwyr ein hunain. Pan fydd llawer o brofion ac efelychwyr, maent yn anodd eu rheoli. O ganlyniad, symudodd ein holl efelychwyr i'r clwstwr k8s gyda rheolaeth adnoddau hyblyg.

Yn ogystal, mae yna gynlluniau eraill.

• Dychwelyd Lint (a dadansoddiad statig arall). Rydym eisoes yn gweithio i'r cyfeiriad hwn.
• Rhedeg popeth ar atalydd cysylltiadau cyhoeddus profion diwedd-i-ddiwedd ar bob fersiwn SDK.

Felly, rydym wedi olrhain hanes datblygiad Integreiddio Parhaus yn Avito. Nawr rwyf am roi rhywfaint o gyngor o safbwynt profiadol.

Советы

Pe gallwn roi un darn o gyngor yn unig, dyma fyddai:

Byddwch yn ofalus gyda sgriptiau cregyn!

Mae Bash yn offeryn hyblyg a phwerus iawn, mae'n gyfleus ac yn gyflym iawn i ysgrifennu sgriptiau. Ond gallwch chi syrthio i fagl ag ef, ac, yn anffodus, rydym yn syrthio i mewn iddo.

Dechreuodd y cyfan gyda sgriptiau syml a oedd yn rhedeg ar ein peiriannau adeiladu:

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

Ond, fel y gwyddoch, mae popeth yn datblygu ac yn dod yn fwy cymhleth dros amser - gadewch i ni redeg un sgript o'r llall, gadewch i ni basio rhai paramedrau yno - yn y diwedd roedd yn rhaid i ni ysgrifennu swyddogaeth sy'n pennu ar ba lefel o nythu bash yr ydym mewn trefn nawr. i fewnosod y dyfyniadau angenrheidiol, i gychwyn y cyfan.

Gallwch ddychmygu'r costau llafur ar gyfer datblygu sgriptiau o'r fath. Rwy'n eich cynghori i beidio â syrthio i'r trap hwn.

Beth ellir ei ddisodli?

• Unrhyw iaith sgriptio. Ysgrifennwch at Sgript Python neu Kotlin yn fwy cyfleus oherwydd ei fod yn rhaglennu, nid sgriptiau.
• Neu disgrifiwch yr holl resymeg adeiladu yn y ffurf Tasgau gradle personol ar gyfer eich prosiect.

Fe benderfynon ni ddewis yr ail opsiwn, a nawr rydyn ni'n dileu'r holl sgriptiau bash yn systematig ac yn ysgrifennu llawer o dasgau gradle personol.

Awgrym #2: Storio seilwaith yn y cod.

Mae'n gyfleus pan fydd y gosodiad Integreiddio Parhaus yn cael ei storio nid yn rhyngwyneb UI Jenkins neu TeamCity, ac ati, ond ar ffurf ffeiliau testun yn uniongyrchol yn ystorfa'r prosiect. Mae hyn yn rhoi fersiwnadwyedd. Ni fydd yn anodd dychwelyd neu adeiladu'r cod ar gangen arall.

Gellir storio sgriptiau mewn prosiect. Beth i'w wneud â'r amgylchedd?

Awgrym #3: Gall Docker helpu gyda'r amgylchedd.

Bydd yn bendant yn helpu datblygwyr Android; nid oes gan iOS un eto, yn anffodus.

Dyma enghraifft o ffeil docwr syml sy'n cynnwys jdk ac 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

Ar ôl ysgrifennu'r ffeil Docker hon (byddaf yn dweud cyfrinach wrthych, nid oes rhaid i chi ei hysgrifennu, ond dim ond ei thynnu'n barod o GitHub) a chydosod y ddelwedd, rydych chi'n cael peiriant rhithwir y gallwch chi adeiladu'r cymhwysiad arno a rhedeg profion Junit.

Y ddau brif reswm pam mae hyn yn gwneud synnwyr yw graddadwyedd ac ailadroddadwyedd. Gan ddefnyddio docwr, gallwch godi dwsin o asiantau adeiladu yn gyflym a fydd â'r un amgylchedd yn union â'r un blaenorol. Mae hyn yn gwneud bywyd peirianwyr CI yn llawer haws. Mae'n eithaf hawdd gwthio'r android-sdk i mewn i docwr, ond gydag efelychwyr mae ychydig yn anoddach: bydd yn rhaid i chi weithio ychydig yn galetach (neu lawrlwytho'r un gorffenedig o GitHub eto).

Awgrym Rhif 4: peidiwch ag anghofio nad yw arolygiadau yn cael eu gwneud er mwyn arolygiadau, ond i bobl.

Mae adborth cyflym ac, yn bwysicaf oll, yn glir yn bwysig iawn i ddatblygwyr: beth dorrodd, pa brawf a fethodd, ble alla i weld y log adeiladu.

Awgrym #5: Byddwch yn bragmatig wrth ddatblygu Integreiddio Parhaus.

Deall yn glir pa fathau o wallau rydych chi am eu hatal, faint o adnoddau, amser ac amser cyfrifiadurol rydych chi'n fodlon ei wario. Gall sieciau sy'n cymryd gormod o amser, er enghraifft, gael eu gohirio dros nos. A dylid rhoi'r gorau i'r rhai sy'n dal gwallau pwysig iawn.

Awgrym #6: Defnyddiwch offer parod.

Mae yna lawer o gwmnïau nawr sy'n darparu cwmwl CI.

Mae hwn yn ateb da ar gyfer timau bach. Nid oes angen i chi gefnogi unrhyw beth, dim ond talu ychydig o arian, adeiladu eich cais a hyd yn oed rhedeg profion offeryniaeth.

Awgrym #7: Mewn tîm mawr, mae datrysiadau mewnol yn fwy proffidiol.

Ond yn hwyr neu'n hwyrach, wrth i'r tîm dyfu, bydd atebion mewnol yn dod yn fwy proffidiol. Mae un broblem gyda’r penderfyniadau hyn. Mae yna gyfraith o enillion sy'n lleihau mewn economeg: mewn unrhyw brosiect, mae pob gwelliant dilynol yn fwyfwy anodd ac yn gofyn am fwy a mwy o fuddsoddiad.

Mae economeg yn disgrifio ein bywyd cyfan, gan gynnwys Integreiddio Parhaus. Adeiladais restr o gostau llafur ar gyfer pob cam o ddatblygiad ein Integreiddiad Parhaus.

Mae’n amlwg bod unrhyw welliant yn dod yn fwyfwy anodd. Wrth edrych ar y graff hwn, gallwch ddeall bod angen datblygu Integreiddio Parhaus yn unol â thwf maint y tîm. I dîm o ddau berson, mae treulio 50 diwrnod yn datblygu fferm efelychwyr mewnol yn syniad cyffredin. Ond ar yr un pryd, i dîm mawr, mae peidio â gwneud Integreiddio Parhaus o gwbl hefyd yn syniad drwg, oherwydd problemau integreiddio, trwsio cyfathrebu, ac ati. bydd yn cymryd hyd yn oed mwy o amser.

Dechreuon ni gyda'r syniad bod angen awtomeiddio oherwydd bod pobl yn ddrud, maen nhw'n gwneud camgymeriadau ac yn ddiog. Ond mae pobl hefyd yn awtomeiddio. Felly, mae'r un problemau i gyd yn berthnasol i awtomeiddio.

• Mae awtomeiddio yn ddrud. Cofiwch yr amserlen lafur.
• O ran awtomeiddio, mae pobl yn gwneud camgymeriadau.
• Weithiau mae'n ddiog iawn i awtomeiddio, oherwydd mae popeth yn gweithio felly. Pam gwella unrhyw beth arall, pam yr holl Integreiddio Parhaus hwn?

Ond mae gen i ystadegau: mae gwallau'n cael eu dal mewn 20% o gynulliadau. Ac nid yw hyn oherwydd bod ein datblygwyr yn ysgrifennu cod yn wael. Mae hyn oherwydd bod datblygwyr yn hyderus, os byddant yn gwneud rhywfaint o gamgymeriad, na fydd yn datblygu yn y pen draw, y bydd yn cael ei ddal gan wiriadau awtomataidd. Yn unol â hynny, gall datblygwyr dreulio mwy o amser yn ysgrifennu cod a phethau diddorol, yn hytrach na rhedeg a phrofi rhywbeth yn lleol.

Ymarfer Integreiddio Parhaus. Ond yn gymedrol.

Gyda llaw, mae Nikolai Nesterov nid yn unig yn rhoi adroddiadau gwych ei hun, ond mae hefyd yn aelod o bwyllgor y rhaglen AppsConf ac yn helpu eraill i baratoi areithiau ystyrlon i chi. Gellir asesu cyflawnrwydd a defnyddioldeb rhaglen y gynhadledd nesaf yn ôl pynciau yn amserlen. Ac am fanylion, dewch i Infospace ar Ebrill 22-23.

Ffynhonnell: hab.com