ProHoster > Blogs > Administrācija > CI evolūcija mobilo ierīču izstrādes komandā

CI evolūcija mobilo ierīču izstrādes komandā

MÅ«sdienās lielākā daļa programmatÅ«ras produktu tiek izstrādāti komandās. VeiksmÄ«gas komandas attÄ«stÄ«bas nosacÄ«jumus var attēlot vienkārÅ”as diagrammas veidā.

CI evolūcija mobilo ierīču izstrādes komandā

Kad esat uzrakstījis kodu, jums tas ir jāpārliecinās:

  1. Tas darbojas.
  2. Tas neko nesabojā, ieskaitot kodu, ko uzrakstīja jūsu kolēģi.

Ja abi nosacÄ«jumi ir izpildÄ«ti, tad jÅ«s esat ceļā uz panākumiem. Lai viegli pārbaudÄ«tu Å”os nosacÄ«jumus un nenovirzÄ«tos no ienesÄ«gā ceļa, mēs izdomājām nepārtrauktu integrāciju.

CI ir darbplūsma, kurā jūs pēc iespējas biežāk integrējat savu kodu kopējā produkta kodā. Un jūs ne tikai integrējat, bet arī pastāvīgi pārbaudiet, vai viss darbojas. Tā kā jums ir jāpārbauda daudz un bieži, ir vērts padomāt par automatizāciju. Jūs varat pārbaudīt visu manuāli, bet jums nevajadzētu, un lūk, kāpēc.

  • Mīļie cilvēki. Jebkura programmētāja darba stunda ir dārgāka nekā jebkura servera stunda.
  • Cilvēki pieļauj kļūdas. Tāpēc var rasties situācijas, kad testi tika palaisti nepareizā zarā vai testētājiem tika apkopota nepareiza apņemÅ”anās.
  • Cilvēki ir slinki. Ik pa laikam, kad pabeidzu kādu uzdevumu, rodas doma: ā€œKo tur pārbaudÄ«t? Es uzrakstÄ«ju divas rindiņas - viss darbojas! Domāju, ka dažiem no jums arÄ« reizēm rodas tādas domas. Bet jums vienmēr ir jāpārbauda.

Kā nepārtrauktā integrācija tika ieviesta un izstrādāta Avito mobilo ierīču izstrādes komandā, kā viņi veica no 0 lÄ«dz 450 bÅ«vēm dienā un ka bÅ«vētās maŔīnas tiek komplektētas 200 stundas dienā, saka Nikolajs Ņesterovs (nnesterovs) ir visu CI/CD Android lietojumprogrammas evolÅ«cijas izmaiņu dalÄ«bnieks.

Stāsts ir balstīts uz Android komandas piemēru, taču lielākā daļa pieeju ir piemērojamas arī iOS.


Kādreiz Avito Android komandā strādāja viens cilvēks. Pēc definīcijas viņam nekas nebija vajadzīgs no nepārtrauktās integrācijas: nebija neviena, ar ko integrēties.

Taču pieteikums auga, parādījās arvien jauni uzdevumi, un attiecīgi auga komanda. Kādā brīdī ir pienācis laiks formālāk izveidot koda integrācijas procesu. Tika nolemts izmantot Git flow.

CI evolūcija mobilo ierīču izstrādes komandā

Git plÅ«smas jēdziens ir labi zināms: projektam ir viena kopÄ«ga izstrādes filiāle, un katrai jaunai funkcijai izstrādātāji nogriež atseviŔķu zaru, apņemas to Ä«stenot, nospiež un, kad viņi vēlas apvienot savu kodu izstrādes zarā, atver izvilkt pieprasÄ«jumu. Lai dalÄ«tos zināŔanās un apspriestu pieejas, mēs ieviesām koda pārskatÄ«Å”anu, proti, kolēģiem ir jāpārbauda un jāapstiprina vienam otra kods.

Pārbaudes

Redzēt kodu ar acÄ«m ir forÅ”i, bet ar to nepietiek. Tāpēc tiek ieviestas automātiskās pārbaudes.

  • Pirmkārt, mēs pārbaudām ARK montāža.
  • Daudz Junita testi.
  • Mēs apsveram koda pārklājumu, jo mēs veicam testus.

Lai saprastu, kā Ŕīs pārbaudes jāveic, apskatīsim izstrādes procesu Avito.

Shematiski to var attēlot Ŕādi:

  • Izstrādātājs raksta kodu savā klēpjdatorā. JÅ«s varat palaist integrācijas pārbaudes tieÅ”i Å”eit ā€” vai nu ar fiksācijas āķi, vai vienkārÅ”i palaist pārbaudes fonā.
  • Kad izstrādātājs ir nospiedis kodu, viņŔ atver izvilkÅ”anas pieprasÄ«jumu. Lai tā kods tiktu iekļauts izstrādes nozarē, ir jāiziet koda pārskatÄ«Å”ana un jāsavāc nepiecieÅ”amais apstiprinājumu skaits. Å eit varat iespējot pārbaudes un bÅ«vējumus: kamēr visas bÅ«ves nav veiksmÄ«gas, vilkÅ”anas pieprasÄ«jumu nevar sapludināt.
  • Pēc tam, kad izvilkÅ”anas pieprasÄ«jums ir apvienots un kods ir iekļauts izstrādē, varat izvēlēties ērtu laiku: piemēram, naktÄ«, kad visi serveri ir brÄ«vi, un veikt tik daudz pārbaužu, cik vēlaties.

Nevienam nepatika veikt skenÄ“Å”anu savā klēpjdatorā. Kad izstrādātājs ir pabeidzis funkciju, viņŔ vēlas to ātri nospiest un atvērt vilkÅ”anas pieprasÄ«jumu. Ja Å”ajā brÄ«dÄ« tiek palaistas dažas ilgas pārbaudes, tas ne tikai nav Ä«paÅ”i patÄ«kami, bet arÄ« palēnina attÄ«stÄ«bu: kamēr klēpjdators kaut ko pārbauda, ā€‹ā€‹ar to nav iespējams normāli strādāt.

Mums ļoti patika palaist čekus naktÄ«, jo laika un serveru ir daudz, var klÄ«st apkārt. Taču diemžēl, kad funkcijas kods tiek izstrādāts, izstrādātājam ir daudz mazāka motivācija labot CI atrastās kļūdas. Periodiski pieķēru sevi pie domas, kad skatÄ«jos uz visām rÄ«ta atskaitē atrastajām kļūdām, ka kādreiz vēlāk tās izlaboÅ”u, jo tagad Jirā ir jauns forÅ”s uzdevums, ko tikai gribu sākt darÄ«t.

Ja pārbaudes bloķē pull pieprasījumu, tad ir pietiekami daudz motivācijas, jo, kamēr būvdarbi nav zaļi, kods neiekļūs izstrādes procesā, kas nozīmē, ka uzdevums netiks pabeigts.

Rezultātā mēs izvēlējāmies Ŕādu stratēģiju: mēs veicam maksimāli iespējamo pārbaužu komplektu naktÄ« un palaižam kritiskākās no tām un, pats galvenais, ātrākās pēc pieprasÄ«juma. Taču mēs neapstājamies pie tā ā€” paralēli mēs optimizējam pārbaužu ātrumu, lai tās pārsÅ«tÄ«tu no nakts režīma uz pieprasÄ«jumu pārbaudes.

Tajā laikā visas mÅ«su bÅ«ves tika pabeigtas diezgan ātri, tāpēc mēs vienkārÅ”i iekļāvām ARK bÅ«vējumu, Junit testus un koda pārklājuma aprēķinus kā pull pieprasÄ«juma bloķētāju. Mēs to ieslēdzām, domājām par to un atteicāmies no koda pārklājuma, jo uzskatÄ«jām, ka mums tas nav vajadzÄ«gs.

Mums bija nepiecieÅ”amas divas dienas, lai pilnÄ«bā iestatÄ«tu pamata CI (turpmāk laika aprēķins ir aptuvens, nepiecieÅ”ams mērogam).

Pēc tam sākām domāt tālāk ā€“ vai vispār pārbaudām pareizi? Vai mēs pareizi izpildām bÅ«ves, pamatojoties uz izvilkÅ”anas pieprasÄ«jumiem?

Mēs sākām veidoÅ”anu, izmantojot pēdējo filiāles apņemÅ”anos, no kuras tika atvērts izvilkÅ”anas pieprasÄ«jums. Taču Ŕīs saistÄ«bas testi var tikai parādÄ«t, ka izstrādātāja ierakstÄ«tais kods darbojas. Bet tie nepierāda, ka viņŔ neko nav salauzis. PatiesÄ«bā jums ir jāpārbauda izstrādes filiāles stāvoklis pēc tam, kad lÄ«dzeklis ir apvienots tajā.

CI evolūcija mobilo ierīču izstrādes komandā

Lai to izdarÄ«tu, mēs uzrakstÄ«jām vienkārÅ”u bash skriptu premerge.sh:

#!/usr/bin/env bash

set -e

git fetch origin develop

git merge origin/develop

Å eit visas jaunākās izmaiņas no izstrādes tiek vienkārÅ”i uzvilktas un apvienotas paÅ”reizējā filiālē. Mēs pievienojām premerge.sh skriptu kā pirmo soli visās versijās un sākām pārbaudÄ«t tieÅ”i to, ko mēs vēlamies, tas ir, integrācija.

Pagāja trÄ«s dienas, lai lokalizētu problēmu, atrastu risinājumu un uzrakstÄ«tu Å”o skriptu.

Lietojumprogramma attīstījās, parādījās arvien vairāk uzdevumu, komanda auga, un premerge.sh dažkārt sāka mūs pievilt. Develop bija pretrunīgas izmaiņas, kas pārtrauca būvniecību.

Piemērs, kā tas notiek:

CI evolūcija mobilo ierīču izstrādes komandā

Divi izstrādātāji vienlaikus sāk strādāt pie lÄ«dzekļiem A un B. LÄ«dzekļa A izstrādātājs atklāj projektā neizmantotu lÄ«dzekli answer() un kā labs skauts to noņem. Tajā paŔā laikā funkcijas B izstrādātājs savā filiālē pievieno jaunu Ŕīs funkcijas izsaukumu.

Izstrādātāji pabeidz darbu un vienlaikus atver izvilkÅ”anas pieprasÄ«jumu. BÅ«vējums tiek palaists, premerge.sh pārbauda abus izvilkÅ”anas pieprasÄ«jumus attiecÄ«bā uz jaunāko izstrādes stāvokli ā€” visas pārbaudes ir zaļas. Pēc tam objekta A piesaistes pieprasÄ«jums tiek apvienots, objekta B piesaistes pieprasÄ«jums tiek apvienots... Boom! Izstrādes pārtraukumi, jo izstrādes kodā ir izsaukums uz neesoÅ”u funkciju.

CI evolūcija mobilo ierīču izstrādes komandā

Kad tas neattīstās, tas ir vietējā katastrofa. Visa komanda nevar savākt neko un iesniegt to pārbaudei.

Tā sagadÄ«jās, ka es visbiežāk strādāju pie infrastruktÅ«ras uzdevumiem: analÄ«tika, tÄ«kls, datu bāzes. Tas ir, es uzrakstÄ«ju tās funkcijas un klases, kuras izmanto citi izstrādātāji. Å Ä« iemesla dēļ es ļoti bieži nokļuvu lÄ«dzÄ«gās situācijās. Man pat kādu laiku Ŕī bilde bija karājusies.

CI evolūcija mobilo ierīču izstrādes komandā

Tā kā tas mums nebija piemērots, mēs sākām pētīt iespējas, kā to novērst.

Kā nepārkāpt attīstīties

Pirmais variants: Atjauninot izstrādāt, pārbÅ«vēt visus izvilkÅ”anas pieprasÄ«jumus. Ja mÅ«su piemērā izvilkÅ”anas pieprasÄ«jums ar lÄ«dzekli A ir pirmais, kas tiek iekļauts izstrādes procesā, objekta B izvilkÅ”anas pieprasÄ«jums tiks pārbÅ«vēts, un attiecÄ«gi pārbaudes neizdosies kompilācijas kļūdas dēļ.

Lai saprastu, cik ilgi tas prasīs, apsveriet piemēru ar diviem PR. Mēs atveram divus PR: divas versijas, divas pārbaudes. Pēc tam, kad pirmais PR ir apvienots attīstībā, otrais ir jāpārbūvē. Kopumā diviem PR ir jāveic trīs pārbaudes: 2 + 1 = 3.

Principā ir labi. Bet mēs paskatÄ«jāmies statistiku, un tipiskā situācija mÅ«su komandā bija 10 atvērti PR, un tad pārbaužu skaits ir progresijas summa: 10 + 9 +... + 1 = 55. Tas ir, pieņemt 10 PR, jums ir jāpārbÅ«vē 55 reizes. Un tas ir ideālā situācijā, kad visas pārbaudes iziet pirmo reizi, kad neviens neatver papildu izvilkÅ”anas pieprasÄ«jumu, kamēr Å”ie desmiti tiek apstrādāti.

Iedomājieties sevi kā izstrādātāju, kuram pirmajam jānoklikŔķina uz pogas ā€œsapludinātā€, jo, ja kaimiņŔ to izdarÄ«s, jums bÅ«s jāgaida, lÄ«dz visas bÅ«ves atkal tiks cauri... Nē, tas nedarbosies. , tas nopietni palēninās attÄ«stÄ«bu.

Otrais iespējamais veids: apkopot izvilkÅ”anas pieprasÄ«jumus pēc koda pārskatÄ«Å”anas. Tas nozÄ«mē, ka jÅ«s atverat izvilkÅ”anas pieprasÄ«jumu, savāc nepiecieÅ”amo apstiprinājumu skaitu no kolēģiem, labojat nepiecieÅ”amo un pēc tam palaižat bÅ«vējumus. Ja tie ir veiksmÄ«gi, izvilkÅ”anas pieprasÄ«jums tiek apvienots izstrādes procesā. Å ajā gadÄ«jumā papildu restartÄ“Å”anas nav, taču atgriezeniskā saite ir ievērojami palēnināta. Kā izstrādātājs, atverot izvilkÅ”anas pieprasÄ«jumu, es uzreiz vēlos redzēt, vai tas darbosies. Piemēram, ja tests neizdodas, jums tas ātri jālabo. Aizkavētas uzbÅ«ves gadÄ«jumā palēninās atgriezeniskā saite un lÄ«dz ar to arÄ« visa izstrāde. ArÄ« Å”is mums nederēja.

Rezultātā palika tikai treŔā iespēja - riteņbraukÅ”ana. Viss mÅ«su kods, visi avoti tiek glabāti Bitbucket servera repozitorijā. AttiecÄ«gi mums bija jāizstrādā Bitbucket spraudnis.

CI evolūcija mobilo ierīču izstrādes komandā

Å is spraudnis ignorē vilkÅ”anas pieprasÄ«juma apvienoÅ”anas mehānismu. Sākums ir standarta: tiek atvērts PR, tiek palaisti visi mezgli, koda pārskatÄ«Å”ana ir pabeigta. Bet pēc tam, kad koda pārskatÄ«Å”ana ir pabeigta un izstrādātājs nolemj noklikŔķināt uz ā€œsapludinātā€, spraudnis pārbauda, ā€‹ā€‹pret kuru izstrādes stāvokli tika veiktas pārbaudes. Ja izstrāde ir atjaunināta pēc bÅ«vÄ“Å”anas, spraudnis neļaus sapludināt Ŕādu vilkÅ”anas pieprasÄ«jumu galvenajā filiālē. Tas vienkārÅ”i restartēs salÄ«dzinoÅ”i nesenas izstrādes versijas.

CI evolūcija mobilo ierīču izstrādes komandā

MÅ«su piemērā ar pretrunÄ«gām izmaiņām Ŕādas bÅ«ves neizdosies kompilācijas kļūdas dēļ. AttiecÄ«gi funkcijas B izstrādātājam bÅ«s jālabo kods, jārestartē pārbaudes, tad spraudnis automātiski piemēros vilkÅ”anas pieprasÄ«jumu.

Pirms Ŕī spraudņa ievieÅ”anas mēs veicām vidēji 2,7 pārskatÄ«Å”anas reizes vienam piesaistes pieprasÄ«jumam. Ar spraudni bija 3,6 palaiÅ”anas reizes. Tas mums derēja.

Ir vērts atzÄ«mēt, ka Å”im spraudnim ir trÅ«kums: tas tikai vienu reizi restartē bÅ«vniecÄ«bu. Tas nozÄ«mē, ka joprojām ir neliels logs, caur kuru var attÄ«stÄ«ties pretrunÄ«gas izmaiņas. Taču tā iespējamÄ«ba ir zema, un mēs veicām Å”o kompromisu starp startu skaitu un neveiksmes iespējamÄ«bu. Divu gadu laikā tas izŔāva tikai vienu reizi, tāpēc, iespējams, tas nebija velti.

Bitbucket spraudņa pirmās versijas uzrakstÄ«Å”ana aizņēma divas nedēļas.

Jauni čeki

Tikmēr mūsu komanda turpināja augt. Ir pievienoti jauni čeki.

Mēs domājām: kāpēc kļūdÄ«ties, ja tās var novērst? Un tāpēc viņi to Ä«stenoja statiskā koda analÄ«ze. Mēs sākām ar lint, kas ir iekļauta Android SDK. Bet tajā laikā viņŔ vispār nemācēja strādāt ar Kotlin kodu, un mums jau bija 75% no pieteikuma Kotlinā rakstÄ«ts. Tāpēc savārstÄ«Å”anai tika pievienoti iebÅ«vētie Android Studio pārbauda.

Lai to izdarītu, mums nācās veikt daudz kļūdu: paņemiet Android Studio, iepakojiet to programmā Docker un palaidiet to CI ar virtuālo monitoru, lai tas domātu, ka tas darbojas īstā klēpjdatorā. Bet tas izdevās.

Å ajā laikā arÄ« mēs sākām daudz rakstÄ«t instrumentācijas testi un Ä«stenots ekrānuzņēmumu pārbaude. Tas ir tad, kad atseviŔķam mazam skatam tiek Ä£enerēts atsauces ekrānuzņēmums, un pārbaude sastāv no ekrānuzņēmuma uzņemÅ”anas no skata un salÄ«dzināŔanas ar standarta tieÅ”i pa pikseļiem. Ja ir neatbilstÄ«ba, tas nozÄ«mē, ka izkārtojums kaut kur ir nogājis greizi vai kaut kas nav kārtÄ«bā stilos.

Bet instrumentu pārbaudes un ekrānuzņēmumu testi ir jāpalaiž ierÄ«cēs: emulatoros vai reālās ierÄ«cēs. Ņemot vērā, ka testu ir daudz un tie tiek palaisti bieži, ir vajadzÄ«ga vesela ferma. Savas saimniecÄ«bas dibināŔana ir pārāk darbietilpÄ«ga, tāpēc atradām gatavu variantu ā€“ Firebase Test Lab.

Firebase testa laboratorija

Tas tika izvēlēts, jo Firebase ir Google produkts, kas nozīmē, ka tam ir jābūt uzticamam un, visticamāk, tas nekad nenomirs. Cenas ir saprātīgas: 5 USD par reālas ierīces darbības stundu, 1 USD par emulatora darbības stundu.

Lai ieviestu Firebase Test Lab mÅ«su CI, bija nepiecieÅ”amas aptuveni trÄ«s nedēļas.

Taču komanda turpināja augt, un Firebase diemžēl sāka mÅ«s pievilt. Tajā laikā viņam nebija SLA. Dažkārt Firebase lika mums gaidÄ«t, lÄ«dz vajadzÄ«gais ierīču skaits bÅ«s brÄ«vs testu veikÅ”anai, un nesāka tos izpildÄ«t uzreiz, kā gribējām. GaidÄ«Å”ana rindā aizņēma lÄ«dz pusstundai, kas ir ļoti ilgs laiks. Instrumentācijas testi tika veikti katrā PR, kavÄ“Å”anās patieŔām palēnināja attÄ«stÄ«bu, un tad ikmēneÅ”a rēķins nāca ar apaļu summu. Kopumā tika nolemts pamest Firebase un strādāt iekŔā, jo komanda bija pietiekami augusi.

Docker + Python + bash

Mēs paņēmām Docker, iebāzām tajā emulatorus, uzrakstÄ«jām vienkārÅ”u programmu Python, kas Ä«stajā brÄ«dÄ« palaiž vajadzÄ«go emulatoru skaitu pareizajā versijā un aptur tos, kad nepiecieÅ”ams. Un, protams, pāris bash skripti ā€“ kur gan mēs bÅ«tu bez tiem?

Lai izveidotu mÅ«su paÅ”u testa vidi, bija nepiecieÅ”amas piecas nedēļas.

Rezultātā katram izvilkÅ”anas pieprasÄ«jumam bija plaÅ”s apvienoÅ”anas bloķējoÅ”o pārbaužu saraksts:

  • ARK montāža;
  • Junita testi;
  • PlÅ«ksna;
  • Android Studio pārbaudes;
  • Instrumentu pārbaudes;
  • Ekrānuzņēmumu testi.

Tas novērsa daudzus iespējamos bojājumus. Tehniski viss darbojās, taču izstrādātāji sÅ«dzējās, ka rezultātu gaidÄ«Å”ana bija pārāk ilga.

Cik ilgi ir par ilgu? Mēs augÅ”upielādējām datus no Bitbucket un TeamCity analÄ«zes sistēmā un to sapratām vidējais gaidÄ«Å”anas laiks 45 minÅ«tes. Tas nozÄ«mē, ka izstrādātājs, atverot izvilkÅ”anas pieprasÄ«jumu, vidēji gaida 45 minÅ«tes, lai iegÅ«tu bÅ«vÄ“Å”anas rezultātus. Manuprāt, tas ir daudz, un jÅ«s nevarat tā strādāt.

Protams, mēs nolēmām paātrināt visas mūsu būves.

Paātrināsim

Redzot, ka ēkas bieži vien stāv rindā, vispirms mēs darām iegādājās vairāk aparatÅ«ras ā€” ekstensÄ«va attÄ«stÄ«ba ir visvienkārŔākā. Builds pārtrauca rindas, bet gaidÄ«Å”anas laiks saruka tikai nedaudz, jo dažas pārbaudes paÅ”as aizņēma ļoti ilgu laiku.

Pārāk ilgu laiku čeku noņemÅ”ana

MÅ«su nepārtrauktā integrācija var uztvert Ŕāda veida kļūdas un problēmas.

  • Netaisos. CI var uztvert kompilācijas kļūdu, ja kaut kas netiek izveidots pretrunÄ«gu izmaiņu dēļ. Kā jau teicu, tad neviens neko nevar samontēt, attÄ«stÄ«ba apstājas, un visi kļūst nervozi.
  • Kļūda uzvedÄ«bā. Piemēram, ja lietojumprogramma ir izveidota, bet, nospiežot pogu, tā avarē vai poga netiek nospiesta vispār. Tas ir slikti, jo Ŕāda kļūda var sasniegt lietotāju.
  • Kļūda izkārtojumā. Piemēram, uz pogas ir noklikŔķināts, bet tā ir pārvietota par 10 pikseļiem pa kreisi.
  • Tehniskā parāda pieaugums.

Apskatot Å”o sarakstu, mēs sapratām, ka tikai pirmie divi punkti ir kritiski. Mēs vēlamies vispirms novērst Ŕādas problēmas. Izkārtojuma kļūdas tiek atklātas dizaina pārskatÄ«Å”anas stadijā, un pēc tam tās var viegli izlabot. Tehnisko parādu risināŔanai ir nepiecieÅ”ams atseviŔķs process un plānoÅ”ana, tāpēc mēs nolēmām to nepārbaudÄ«t pēc pieprasÄ«juma.

Pamatojoties uz Å”o klasifikāciju, mēs satricinājām visu čeku sarakstu. IzsvÄ«trots Lint un atlika tā palaiÅ”anu uz nakti: tikai tāpēc, lai tas sagatavotu ziņojumu par to, cik daudz problēmu bija projektā. Vienojāmies strādāt atseviŔķi ar tehnisko parādu, un Android Studio pārbaudes tika pilnÄ«bā atmestas. Android Studio programmā Docker pārbaužu veikÅ”anai izklausās interesanti, taču rada daudz problēmu atbalsta jomā. JebkurÅ” Android Studio versiju atjauninājums nozÄ«mē cīņu ar nesaprotamām kļūdām. Bija arÄ« grÅ«ti atbalstÄ«t ekrānuzņēmumu testus, jo bibliotēka nebija ļoti stabila un bija kļūdaini pozitÄ«vi. Ekrānuzņēmumu testi ir izņemti no kontrolsaraksta.

Rezultātā mums palika:

  • ARK montāža;
  • Junita testi;
  • Instrumentācijas testi.

Gradle attālā keÅ”atmiņa

Bez smagām pārbaudēm viss kļuva labāk. Bet pilnībai nav robežu!

MÅ«su lietojumprogramma jau bija sadalÄ«ta aptuveni 150 pakāpes moduļos. Gradle attālā keÅ”atmiņa parasti Å”ajā gadÄ«jumā darbojas labi, tāpēc mēs nolēmām to izmēģināt.

Gradle attālā keÅ”atmiņa ir pakalpojums, kas var keÅ”atmiņā saglabāt artefaktus atseviŔķiem uzdevumiem atseviŔķos moduļos. Gradle tā vietā, lai faktiski apkopotu kodu, izmanto HTTP, lai pieklauvētu pie attālās keÅ”atmiņas un jautātu, vai kāds jau ir veicis Å”o uzdevumu. Ja jā, tas vienkārÅ”i lejupielādē rezultātu.

Gradle attālās keÅ”atmiņas palaiÅ”ana ir vienkārÅ”a, jo Gradle nodroÅ”ina Docker attēlu. Mums tas izdevās trÄ«s stundu laikā.

Viss, kas jums jādara, bija palaist Docker un projektā ierakstīt vienu rindiņu. Bet, lai gan to var ātri palaist, tas prasīs diezgan daudz laika, lai viss darbotos labi.

Zemāk ir keÅ”atmiņas izlaiÅ”anas diagramma.

CI evolūcija mobilo ierīču izstrādes komandā

PaŔā sākumā keÅ”atmiņas izlaidumu procents bija aptuveni 65. Pēc trim nedēļām mums izdevās Å”o vērtÄ«bu palielināt lÄ«dz 20%. IzrādÄ«jās, ka Android lietojumprogrammas apkopotajiem uzdevumiem ir dÄ«vainas pārejoÅ”as atkarÄ«bas, kuru dēļ Gradle palaida garām keÅ”atmiņu.

Savienojot keÅ”atmiņu, mēs ievērojami paātrinājām veidoÅ”anu. Bet papildus montāžai ir arÄ« instrumentu pārbaudes, un tās aizņem ilgu laiku. Iespējams, ne visi testi ir jāveic katram vilkÅ”anas pieprasÄ«jumam. Lai to noskaidrotu, mēs izmantojam ietekmes analÄ«zi.

Ietekmes analīze

Pēc izvilkÅ”anas pieprasÄ«juma mēs apkopojam git diff un atrodam modificētos Gradle moduļus.

CI evolūcija mobilo ierīču izstrādes komandā

Ir lietderÄ«gi palaist tikai instrumentu testus, kas pārbauda mainÄ«tos moduļus un visus no tiem atkarÄ«gos moduļus. Nav jēgas palaist testus blakus esoÅ”ajiem moduļiem: kods tur nav mainÄ«jies un nekas nevar salÅ«zt.

Instrumentācijas testi nav tik vienkārÅ”i, jo tiem jāatrodas augstākā lÄ«meņa lietojumprogrammu modulÄ«. Mēs izmantojām heiristiku ar baitkoda analÄ«zi, lai saprastu, kuram modulim pieder katrs tests.

Instrumentu pārbaužu darbÄ«bas uzlaboÅ”ana, lai tie pārbaudÄ«tu tikai iesaistÄ«tos moduļus, aizņēma apmēram astoņas nedēļas.

Pārbaužu paātrināŔanas pasākumi ir bijuÅ”i veiksmÄ«gi. No 45 minÅ«tēm mēs uzkāpām lÄ«dz apmēram 15. Tas jau ir normāli, ka jāgaida ceturtdaļstundu, lai uzbÅ«vētu.

Bet tagad izstrādātāji ir sākuÅ”i sÅ«dzēties, ka nesaprot, kuras bÅ«ves tiek palaists, kur var redzēt žurnālu, kāpēc bÅ«ve ir sarkana, kurÅ” tests neizdevās utt.

CI evolūcija mobilo ierīču izstrādes komandā

Problēmas ar atgriezenisko saiti palēnina attÄ«stÄ«bu, tāpēc mēs centāmies sniegt pēc iespējas skaidrāku un detalizētāku informāciju par katru PR un bÅ«vniecÄ«bu. Mēs sākām ar komentāriem pakalpojumā Bitbucket PR, norādot, kurÅ” veidojums neizdevās un kāpēc, un rakstÄ«jām mērÄ·tiecÄ«gus ziņojumus Slack. Beigās mēs izveidojām lapai PR informācijas paneli ar visu paÅ”laik darbojoÅ”os bÅ«vējumu sarakstu un to statusu: rindā, darbojas, avarēja vai pabeigta. Varat noklikŔķināt uz bÅ«ves un nokļūt tās žurnālā.

CI evolūcija mobilo ierīču izstrādes komandā

SeÅ”as nedēļas tika veltÄ«tas detalizētām atsauksmēm.

Plāni

Pāriesim pie nesenās vēstures. Atrisinot atgriezeniskās saites problēmu, mēs sasniedzām jaunu līmeni - nolēmām izveidot savu emulatoru fermu. Ja ir daudz testu un emulatoru, tos ir grūti pārvaldīt. Rezultātā visi mūsu emulatori pārcēlās uz k8s klasteru ar elastīgu resursu pārvaldību.

Turklāt ir arī citi plāni.

  • Atgriezties Lint (un cita statiskā analÄ«ze). Mēs jau strādājam Å”ajā virzienā.
  • Palaidiet visu uz PR bloķētāja pilnÄ«gas pārbaudes visās SDK versijās.

Tātad, mēs esam izsekojuÅ”i Avito nepārtrauktās integrācijas attÄ«stÄ«bas vēsturei. Tagad es vēlos sniegt dažus padomus no pieredzējuÅ”a viedokļa.

Š”Š¾Š²ŠµŃ‚Ń‹

Ja es varētu sniegt tikai vienu padomu, tas bÅ«tu Ŕāds:

Lūdzu, esiet uzmanīgi ar čaulas skriptiem!

Bash ir ļoti elastīgs un spēcīgs rīks, ar to ir ļoti ērti un ātri rakstīt skriptus. Bet ar to jūs varat iekrist lamatās, un diemžēl mēs tajā iekritām.

Viss sākās ar vienkārÅ”iem skriptiem, kas darbojās mÅ«su bÅ«vÄ“Å”anas iekārtās:

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

Bet, kā zināms, ar laiku viss attÄ«stās un kļūst sarežģītāks - palaist vienu skriptu no otra, nododam tur dažus parametrus - beigās bija jāuzraksta funkcija, kas nosaka, kādā bash ligzdoÅ”anas lÄ«menÄ« mēs tagad esam kārtÄ«bā lai ievietotu nepiecieÅ”amos citātus, lai viss sāktu.

CI evolūcija mobilo ierīču izstrādes komandā

Varat iedomāties darbaspēka izmaksas Ŕādu skriptu izstrādei. Iesaku neiekrist Å”ajās lamatās.

Ko var aizstāt?

  • Jebkura skriptu valoda. RakstÄ«t Python vai Kotlin skripts ērtāk, jo tā ir programmÄ“Å”ana, nevis skripti.
  • Vai veidlapā aprakstiet visu veidoÅ”anas loÄ£iku Pielāgoti gradle uzdevumi jÅ«su projektam.

Mēs nolēmām izvēlēties otro iespēju, un tagad mēs sistemātiski dzÄ“Å”am visus bash skriptus un rakstām daudz pielāgotu gradle uzdevumu.

2. padoms. Saglabājiet infrastruktÅ«ru kodā.

Tas ir ērti, ja iestatÄ«jums Continuous Integration tiek glabāts nevis Jenkins vai TeamCity u.c. lietotāja interfeisā, bet gan teksta failu veidā tieÅ”i projekta repozitorijā. Tas nodroÅ”ina versijas spēju. NebÅ«s grÅ«ti atjaunot vai izveidot kodu citā filiālē.

Skriptus var saglabāt projektā. Ko darīt ar vidi?

Padoms Nr. 3: Docker var palīdzēt ar vidi.

Tas noteikti palīdzēs Android izstrādātājiem; iOS, diemžēl, tāda vēl nav.

Å is ir vienkārÅ”a docker faila piemērs, kurā ir jdk un 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

Uzrakstot Å”o Docker failu (atklāŔu noslēpumu, tas nav jāraksta, bet vienkārÅ”i jāizvelk gatavu no GitHub) un samontēts attēls, jÅ«s iegÅ«stat virtuālo maŔīnu, uz kuras varat veidot aplikāciju un palaist Junita testus.

Divi galvenie iemesli, kāpēc tam ir jēga, ir mērogojamÄ«ba un atkārtojamÄ«ba. Izmantojot docker, varat ātri izveidot duci bÅ«vaÄ£entu, kuriem bÅ«s tieÅ”i tāda pati vide kā iepriekŔējai. Tas ievērojami atvieglo CI inženieru dzÄ«vi. Ir diezgan viegli ievietot android-sdk dokerā, taču ar emulatoriem tas ir nedaudz grÅ«tāk: jums bÅ«s jāstrādā nedaudz vairāk (vai vēlreiz lejupielādējiet pabeigto no GitHub).

Padoms Nr.4: neaizmirstiet, ka pārbaudes tiek veiktas nevis pārbaužu, bet gan cilvēku dēļ.

Izstrādātājiem ļoti svarīgas ir ātras un, pats galvenais, skaidras atsauksmes: kas sabojājās, kāds tests neizdevās, kur var redzēt buildlog.

5. padoms: esiet pragmatisks, izstrādājot nepārtrauktu integrāciju.

Skaidri saprotiet, kāda veida kļūdas vēlaties novērst, cik daudz resursu, laika un datora laika esat gatavs tērēt. Pārbaudes, kas aizņem pārāk ilgu laiku, var, piemēram, atlikt uz nakti. Un no tiem, kas uztver ne pārāk svarīgas kļūdas, vajadzētu pilnībā atteikties.

6. padoms: izmantojiet gatavus rīkus.

Tagad ir daudz uzņēmumu, kas nodroÅ”ina mākoņa CI.

CI evolūcija mobilo ierīču izstrādes komandā

Tas ir labs risinājums mazām komandām. Jums nekas nav jāatbalsta, vienkārŔi samaksājiet nedaudz naudas, izveidojiet lietojumprogrammu un pat veiciet instrumentu pārbaudes.

7. padoms: lielā komandā iekŔējie risinājumi ir izdevÄ«gāki.

Taču agri vai vēlu, komandai augot, iekŔējie risinājumi kļūs izdevÄ«gāki. Ar Å”iem lēmumiem ir viena problēma. Ekonomikā pastāv atdeves samazināŔanās likums: jebkurā projektā katrs nākamais uzlabojums ir arvien grÅ«tāks un prasa arvien lielākus ieguldÄ«jumus.

Ekonomika apraksta visu mūsu dzīvi, ieskaitot nepārtrauktu integrāciju. Es izveidoju darbaspēka izmaksu grafiku katram mūsu nepārtrauktās integrācijas attīstības posmam.

CI evolūcija mobilo ierīču izstrādes komandā

Skaidrs, ka jebkurÅ” uzlabojums kļūst arvien grÅ«tāks. Skatoties uz Å”o grafiku, var saprast, ka nepārtraukta integrācija ir jāattÄ«sta atbilstoÅ”i komandas lieluma pieaugumam. Divu cilvēku komandai pavadÄ«t 50 dienas iekŔējās emulatoru fermas izstrādei ir viduvēja ideja. Bet tajā paŔā laikā lielai komandai Nepārtrauktās integrācijas nedarÄ«Å”ana vispār ir arÄ« slikta doma, jo integrācijas problēmas, komunikācijas laboÅ”ana utt. tas prasÄ«s vēl vairāk laika.

Mēs sākām ar domu, ka automatizācija ir vajadzÄ«ga, jo cilvēki ir dārgi, viņi kļūdās un ir slinki. Bet cilvēki arÄ« automatizē. Tāpēc visas tās paÅ”as problēmas attiecas uz automatizāciju.

  • Automatizācija ir dārga. Atcerieties darba grafiku.
  • Runājot par automatizāciju, cilvēki pieļauj kļūdas.
  • Dažreiz ir ļoti slinki automatizēt, jo viss darbojas tā. Kāpēc uzlabot kaut ko citu, kāpēc visa Ŕī nepārtrauktā integrācija?

Bet man ir statistika: kļūdas tiek pieÄ·ertas 20% mezglu. Un tas nav tāpēc, ka mÅ«su izstrādātāji slikti raksta kodu. Tas ir tāpēc, ka izstrādātāji ir pārliecināti, ka, ja viņi pieļaus kādu kļūdu, tā nenonāks izstrādes procesā, to pārbaudÄ«s automatizētas pārbaudes. AttiecÄ«gi izstrādātāji var pavadÄ«t vairāk laika koda un interesantu lietu rakstÄ«Å”anai, nevis kaut ko palaist un testēt lokāli.

Praktizējiet nepārtrauktu integrāciju. Bet ar mēru.

Starp citu, Nikolajs Ņesterovs ne tikai pats sniedz lieliskus ziņojumus, bet ir arī programmas komitejas loceklis AppsConf un palīdz citiem sagatavot jēgpilnas runas jums. Nākamās konferences programmas pilnīgumu un lietderību var novērtēt pēc tēmām grafiks. Un sīkākai informācijai nāc uz Infospace 22.-23.aprīlī.

Avots: www.habr.com

Pievieno komentāru