Haut ginn déi meescht Softwareprodukter an Teams entwéckelt. D'Konditioune fir eng erfollegräich Teamentwécklung kënnen a Form vun engem einfachen Diagramm duergestallt ginn.

Wann Dir Äre Code geschriwwen hutt, musst Dir sécher sinn:

Робота.
Et brécht näischt, och de Code déi Är Kollegen geschriwwen hunn.

Wa béid Bedéngungen erfëllt sinn, da sidd Dir um Wee zum Erfolleg. Fir dës Konditiounen einfach z'iwwerpréiwen an net vum rentabele Wee ze deviéieren, si mir mat der kontinuéierlecher Integratioun komm.

CI ass e Workflow wou Dir Äre Code sou dacks wéi méiglech an de Gesamtproduktcode integréiert. An Dir integréiert net nëmmen, awer kontrolléiert och permanent datt alles funktionnéiert. Well Dir musst vill an dacks iwwerpréiwen, ass et derwäert un d'Automatisatioun ze denken. Dir kënnt alles manuell kontrolléieren, awer Dir sollt net, an hei ass firwat.

Léif Leit. Eng Stonn Aarbecht vun all Programméierer ass méi deier wéi eng Stonn Aarbecht vun all Server.
Leit maachen Feeler. Dofir kënne Situatiounen entstoen wann Tester op der falscher Branche ausgeführt goufen oder déi falsch Verpflichtung fir Tester kompiléiert gouf.
D'Leit si faul. Vun Zäit zu Zäit, wann ech eng Aufgab fäerdeg maachen, stellt de Gedanke op: "Wat ass et ze kontrolléieren? Ech hunn zwou Zeilen geschriwwen - alles funktionnéiert! Ech mengen e puer vun iech hunn och heiansdo esou Gedanken. Awer Dir sollt ëmmer kucken.

Wéi kontinuéierlech Integratioun implementéiert an entwéckelt gouf am Avito mobilen Entwécklungsteam, wéi se vun 0 op 450 Builds pro Dag gaange sinn, an datt d'Maschinnen 200 Stonnen den Dag montéieren, seet den Nikolai Nesterov (nnesterov) - e Participant un all evolutiven Ännerungen am CI/CD Android-Applikatiounen.

D'Geschicht baséiert op engem Beispill Android-befeeler, awer déi meescht vun den Approche sinn och op iOS uwendbar.

Eemol war et eng Zäit an AndroidD'Avito-Team bestoung just aus enger Persoun. Per Definitioun huet hien näischt vun der Continuous Integration gebraucht: et gouf keen, mat deem hie konnt integréieren.

Awer d'Applikatioun ass gewuess, ëmmer méi nei Aufgaben erschéngen, an d'Team ass deementspriechend gewuess. Irgendwann ass et Zäit fir méi formell e Code Integratiounsprozess opzebauen. Et gouf decidéiert Git Flow ze benotzen.

D'Konzept vum Git Flow ass bekannt: e Projet huet eng gemeinsam Entwécklungszweig, a fir all nei Feature schneiden d'Entwéckler eng separat Branche, verpflichte se, drécken, a wa se hire Code an d'Entwécklungszweig fusionéiere wëllen, öffnen eng zéien Ufro. Fir Wëssen ze deelen an Approche ze diskutéieren, hu mir Code iwwerpréiwung agefouert, dat ass, Kollegen mussen all aner Code kontrolléieren an confirméieren.

Schecken

Code mat Ären Aen ze gesinn ass cool, awer net genuch. Dofir ginn automatesch Kontrollen agefouert.

Éischt vun all, mir kontrolléieren ARK Assemblée.
Vill Junit Tester.
Mir betruechten Code Cover, well mir Tester lafen.

Fir ze verstoen wéi dës Kontrolle solle lafen, kucke mer den Entwécklungsprozess an Avito.

Et kann schematesch wéi dës duergestallt ginn:

En Entwéckler schreift Code op sengem Laptop. Dir kënnt Integratiounschecken direkt hei ausféieren - entweder mat engem Commit Hook, oder einfach Schecken am Hannergrond lafen.
Nodeems den Entwéckler de Code gedréckt huet, mécht hien eng Pull-Ufro op. Fir datt säi Code an der Entwécklungszweig abegraff ass, ass et néideg duerch e Code review ze goen an déi erfuerderlech Unzuel vun Bestätegungen ze sammelen. Dir kënnt Schecken a Builds hei aktivéieren: bis all Builds erfollegräich sinn, kann d'Pull-Ufro net fusionéiert ginn.
Nodeems d'Pull-Ufro fusionéiert ass an de Code an der Entwécklung abegraff ass, kënnt Dir eng bequem Zäit wielen: zum Beispill an der Nuecht, wann all d'Servere gratis sinn, a lafen esou vill Schecken wéi Dir wëllt.

Keen huet gär Scannen op hirem Laptop lafen. Wann en Entwéckler eng Feature fäerdeg ass, wëll hie se séier drécken an eng Pull-Ufro opmaachen. Wann an dësem Moment e puer laang Kontrollen lancéiert ginn, ass dat net nëmmen net ganz agreabel, mä och d'Entwécklung verlangsamt: während de Laptop eppes iwwerpréift, ass et onméiglech normal drun ze schaffen.

Mir hu wierklech gär Schecken an der Nuecht lafen, well et vill Zäit ass a Serveren, Dir kënnt ronderëm roaméieren. Awer, leider, wann de Feature Code an d'Entwécklung kënnt, huet den Entwéckler vill manner Motivatioun fir d'Feeler ze fixéieren déi CI fonnt hunn. Ech hunn mech periodesch gefaangen ze denken, wann ech all d'Fehler am Moienbericht fonnt hunn, datt ech se enges Daags méi spéit fixéieren, well elo gëtt et eng cool nei Aufgab am Jira, déi ech just wëll ufänken ze maachen.

Wann d'Schecken eng Pull-Ufro blockéieren, da gëtt et genuch Motivatioun, well bis d'Builds gréng ginn, gëtt de Code net entwéckelt, wat heescht datt d'Aufgab net ofgeschloss gëtt.

Als Resultat hu mir déi folgend Strategie gewielt: mir lafen de maximal méigleche Set vu Schecken an der Nuecht, a lancéiert déi kritesch vun hinnen an, am wichtegsten, déi schnellsten op engem Pull Ufro. Awer mir stoppen net do - parallel optiméiere mir d'Geschwindegkeet vun de Kontrollen fir se aus dem Nuetsmodus ze transferéieren fir Ufrokontrollen ze zéien.

Zu där Zäit goufen all eis Builds zimlech séier ofgeschloss, also hu mir einfach den ARK Build, Junit Tester a Code Coverage Berechnungen als Blocker fir d'Pull Ufro abegraff. Mir hunn et ugeschalt, doriwwer geduecht, an hunn de Codeofdeckung opginn well mir geduecht hunn datt mir et net brauchen.

Et huet eis zwee Deeg gedauert fir de Basis-CI komplett opzestellen (nodréiglech ass d'Zäitschätzung ongeféier, néideg fir Skala).

Duerno hu mir ugefaang weider ze denken - kontrolléiere mir iwwerhaapt richteg? Lafen mir Builds op Pull Ufroen richteg?

Mir hunn de Bau op de leschte Verpflichtung vun der Branche ugefaang, aus där d'Pull-Ufro opgemaach gouf. Awer Tester vun dësem Engagement kënnen nëmme weisen datt de Code deen den Entwéckler geschriwwen huet funktionnéiert. Awer si beweisen net datt hien näischt gebrach huet. Tatsächlech musst Dir den Zoustand vun der Entwécklungszweig iwwerpréiwen nodeems eng Feature an et fusionéiert ass.

Fir dëst ze maachen, hu mir en einfachen Bash-Skript geschriwwen premerge.sh:

#!/usr/bin/env bash

set -e

git fetch origin develop

git merge origin/develop

Hei ginn all déi lescht Ännerunge vun der Entwécklung einfach eropgezunn an an déi aktuell Branche fusionéiert. Mir hunn de premerge.sh Skript als den éischte Schrëtt an all Build bäigefüügt an ugefaang genau ze kontrolléieren wat mir wëllen, dat ass Integratioun.

Et huet dräi Deeg gedauert fir de Problem ze lokaliséieren, eng Léisung ze fannen an dëst Skript ze schreiwen.

D'Applikatioun huet sech entwéckelt, ëmmer méi Aufgaben erschéngen, d'Equipe ass gewuess, an premerge.sh huet eis heiansdo ugefaangen ze loossen. Entwéckler haten konfliktend Ännerungen déi de Bau gebrach hunn.

E Beispill vu wéi dat geschitt:

Zwee Entwéckler fänken gläichzäiteg un Feature A a B ze schaffen. Den Entwéckler vun der Feature A entdeckt eng onbenotzt Feature am Projet answer() an, wéi e gudde Jong Scout, ewechzehuelen et. Zur selwechter Zäit füügt den Entwéckler vun der Feature B en neien Uruff un dës Funktioun a senger Branche.

Entwéckler fäerdeg hir Aarbecht an oppen eng Pull Ufro zur selwechter Zäit. D'Builds ginn lancéiert, premerge.sh kontrolléiert béid Pull-Ufroe betreffend de leschten Entwécklungsstaat - all Schecken si gréng. Duerno gëtt d'Pull-Ufro vun der Feature A fusionéiert, d'Pull-Ufro vun der Feature B fusionéiert ... Boom! Entwéckelt Pausen well den Entwécklungscode en Opruff un eng net existent Funktioun enthält.

Wann et net wäert entwéckelen, ass et lokal Katastroph. Dat ganzt Team kann näischt sammelen an et fir Test ofginn.

Et ass geschitt, datt ech meeschtens un Infrastrukturaufgaben geschafft hunn: Analyse, Netzwierk, Datenbanken. Dat ass, et war ech deen déi Funktiounen a Klassen geschriwwen hunn déi aner Entwéckler benotzen. Dofir hunn ech mech ganz dacks an ähnleche Situatiounen fonnt. Ech hat dëst Bild souguer eng Zäitchen hänkt.

Well dëst eis net gepasst huet, hu mir ugefaang Optiounen ze entdecken fir dëst ze vermeiden.

Wéi net ze Paus entwéckelen

Déi éischt Optioun: nei opzebauen all Pull Ufroe beim Update entwéckelen. Wann, an eisem Beispill, d'Pull-Ufro mat Feature A déi éischt ass, déi an der Entwécklung abegraff ass, gëtt d'Pull-Ufro vun der Feature B nei opgebaut, an deementspriechend falen d'Schecken wéinst engem Kompiléierungsfehler.

Fir ze verstoen wéi laang dëst dauert, betruecht e Beispill mat zwee PRs. Mir oppen zwee PRs: zwee baut, zwee Lafen vun Schecken. Nodeems den éischte PR an d'Entwécklung fusionéiert ass, muss deen zweeten nei opgebaut ginn. Am Ganzen erfuerderen zwee PRs dräi Kontrollen: 2 + 1 = 3.

Am Prinzip ass et gutt. Awer mir hunn d'Statistike gekuckt, an déi typesch Situatioun an eisem Team war 10 oppe PRs, an dann ass d'Zuel vun de Schecken d'Zomm vum Fortschrëtt: 10 + 9 +... + 1 = 55. Dat ass, 10 ze akzeptéieren. PRs, Dir musst 55 Mol opbauen. An dëst ass an enger idealer Situatioun, wann all Kontrollen déi éischte Kéier passéieren, wann keen eng zousätzlech Pull-Ufro opmaacht, während dës Dose veraarbecht ginn.

Stellt Iech vir als Entwéckler, deen als Éischte muss op de Knäppche "Merge" klicken, well wann en Noper dat mécht, da musst Dir waarden bis all d'Builds erëm duerchgoen ... Nee, dat geet net , et wäert d'Entwécklung eescht verlangsamen.

Zweet méiglech Manéier: sammelen Pull Ufroen no Code review. Dat ass, Dir öffnet eng Pull-Ufro, sammelt déi erfuerderlech Unzuel vun Genehmegunge vu Kollegen, korrigéiert wat néideg ass, a lancéiert dann d'Builds. Wa se erfollegräich sinn, gëtt d'Pull Ufro an d'Entwécklung fusionéiert. An dësem Fall gëtt et keng zousätzlech Restart, awer de Feedback ass staark verlangsamt. Als Entwéckler, wann ech eng Pull-Ufro opmaachen, wëll ech direkt kucken ob et funktionnéiert. Zum Beispill, wann en Test feelt, musst Dir et séier fixéieren. Am Fall vun enger Verspéidung baut de Feedback verlangsamt, an dofir déi ganz Entwécklung. Dat huet eis och net gepasst.

Als Resultat ass nëmmen déi drëtt Optioun bliwwen - Velo. All eise Code, all eis Quelle ginn an engem Repository um Bitbucket Server gespäichert. Deementspriechend hu mir e Plugin fir Bitbucket missen entwéckelen.

Dëse Plugin iwwerschreift de Pull-Ufro-Fusiounsmechanismus. Den Ufank ass Standard: de PR mécht op, all Versammlungen ginn lancéiert, Code Iwwerpréiwung ass ofgeschloss. Awer nodeems d'Code-Iwwerpréiwung ofgeschloss ass an den Entwéckler decidéiert op "Fusioun" ze klicken, kontrolléiert de Plugin géint deen Entwécklungsstaat d'Schecken ausgefouert goufen. Wann d'Entwécklung no de Builds aktualiséiert gouf, erlaabt de Plugin net datt sou eng Pull-Ufro an d'Haaptzweig fusionéiert gëtt. Et wäert einfach d'Builds vun enger relativ rezenter Entwécklung nei starten.

An eisem Beispill mat konfliktende Ännerunge falen esou Builds wéinst engem Kompiléierungsfehler. Deementspriechend muss den Entwéckler vun der Feature B de Code korrigéieren, d'Schecken nei starten, da wäert de Plugin automatesch d'Pull-Ufro applizéieren.

Ier Dir dëse Plugin implementéiert, hu mir am Duerchschnëtt 2,7 Iwwerpréiwung lafen pro Pull Ufro. Mam Plugin gouf et 3,6 Starten. Dëst huet eis gepasst.

Et ass derwäert ze bemierken datt dëse Plugin en Nodeel huet: et fänkt de Bau nëmmen eemol un. Dat heescht, et gëtt nach ëmmer eng kleng Fënster, duerch déi konfliktend Ännerunge kënne entwéckelen. Awer d'Wahrscheinlechkeet vun dësem ass niddereg, a mir hunn dësen Ofwiesselung tëscht der Zuel vun den Starten an der Wahrscheinlechkeet vum Echec gemaach. An zwee Joer huet et nëmmen eemol gebrannt, also war et wahrscheinlech net ëmsoss.

Et huet eis zwou Wochen gedauert fir déi éischt Versioun vum Bitbucket Plugin ze schreiwen.

Nei Schecken

Mëttlerweil ass eis Team weider wuessen. Nei Schecken goufen dobäi.

Mir hu geduecht: Firwat Feeler maachen, wa se kënne verhënnert ginn? An dofir hunn se ëmgesat statesch Code AnalyseMir hunn ugefaange mat Fussel, wat dobäi ass Android SDK. Mee zu där Zäit wousst et guer net, wéi ee mat Kotlin-Code schaffe soll, an 75% vun eiser Applikatioun war schonn a Kotlin geschriwwen. Dofir gouf agebaute Lint zu Lint bäigefüügt. Android Studiokontrollen.

Fir dëst ze erreechen, musse mir vill Ustrengungen maachen: huelen Android Studio, packen et an Docker, a mat engem virtuelle Monitor op CI lafen, sou datt et mengt, et wier op engem richtege Laptop. Mee et huet funktionéiert.

Et war och an dëser Zäit datt mir vill ugefaang hunn ze schreiwen Instrumenter Tester an ëmgesat Screenshot Testen. Dëst ass wann e Referenz Screenshot fir eng separat kleng Vue generéiert gëtt, an den Test besteet aus engem Screenshot aus der Vue ze huelen an et mam Standard direkt Pixel fir Pixel ze vergläichen. Wann et eng Diskrepanz ass, heescht et datt de Layout iergendwou falsch gaang ass oder eppes an de Stiler falsch ass.

Awer Instrumenter Tester a Screenshot Tester mussen op Apparater lafen: op Emulatoren oder op realen Apparater. Bedenkt datt et vill Tester ginn a se dacks lafen, ass e ganze Bauerenhaff gebraucht. Ären eegene Bauerenhaff starten ass ze Aarbechtsintensiv, also hu mir eng fäerdeg Optioun fonnt - Firebase Test Lab.

Firebase Test Lab

Et gouf gewielt well Firebase e Google Produkt ass, dat heescht et soll zouverlässeg sinn an onwahrscheinlech jee stierwen. D'Präisser sinn raisonnabel: $ 5 pro Stonn Operatioun vun engem richtegen Apparat, 1 $ pro Stonn Operatioun vun engem Emulator.

Et huet ongeféier dräi Wochen gedauert fir Firebase Test Lab an eisem CI ëmzesetzen.

Awer d'Team ass weider wuessen, a Firebase huet leider ugefaang eis ze loossen. Zu där Zäit huet hien keng SLA. Heiansdo huet Firebase eis gewaart bis déi erfuerderlech Unzuel vun Apparater gratis waren fir Tester, an huet net direkt ugefaang se auszeféieren, wéi mir wollten. D'Waarden an der Linn huet bis zu eng hallef Stonn gedauert, wat eng ganz laang Zäit ass. Instrumentatiounstester goufen op all PR ausgeführt, Verspéidungen hunn d'Entwécklung wierklech verlangsamt, an dunn ass de monatleche Rechnung mat enger ronner Zomm komm. Am Allgemengen gouf decidéiert Firebase opzeginn an intern ze schaffen, well d'Team genuch gewuess ass.

Docker + Python + bash

Mir hunn Docker geholl, Emulatoren dran gestoppt, en einfache Programm am Python geschriwwen, deen am richtege Moment déi erfuerderlech Unzuel vun Emulatoren an der erfuerderter Versioun bréngt an se stoppt wann néideg. An, natierlech, e puer Bash Scripten - wou wiere mir ouni si?

Et huet fënnef Wochen gedauert fir eisen eegene Testëmfeld ze kreéieren.

Als Resultat gouf et fir all Pull-Ufro eng extensiv Fusiounsblockéierungslëscht vu Kontrollen:

ARK Assemblée;
Junit Tester;
Lint;
Android Studio-Checks;
Instrumenter Tester;
Screenshot Tester.

Dëst huet vill méiglech Decompte verhënnert. Technesch huet alles geschafft, awer d'Entwéckler hunn beschwéiert datt d'Waarde op d'Resultater ze laang war.

Wéi laang ass ze laang? Mir hunn Daten vu Bitbucket an TeamCity an den Analysesystem eropgelueden an dat realiséiert Duerchschnëtt Waardezäit 45 Minutten. Dat ass, en Entwéckler, wann Dir eng Pull-Ufro opmaacht, waart am Duerchschnëtt 45 Minutten op d'Bauresultater. Menger Meenung no ass dat vill, an Dir kënnt net esou schaffen.

Natierlech hu mir beschloss all eis Builds ze beschleunegen.

Loosst eis beschleunegen

Gesinn, datt baut oft an enger Schlaang stinn, déi éischt Saach mir maachen ass kaaft méi Hardware - extensiv Entwécklung ass déi einfachst. Builds gestoppt Schlaangen, mä d'Waardezäit ass nëmme liicht erofgaang, well e puer Schecken selwer ganz laang gedauert hunn.

Ewechzehuelen Schecken déi ze laang daueren

Eis kontinuéierlech Integratioun konnt dës Aarte vu Feeler a Probleemer opfänken.

Gitt net. CI kann e Kompiléierungsfehler opfänken wann eppes net baut wéinst konfliktende Ännerungen. Wéi ech scho gesot hunn, da kann keen eppes zesummestellen, d'Entwécklung stoppt, a jidderee gëtt nervös.
Bug am Verhalen. Zum Beispill, wann d'Applikatioun gebaut ass, ma Crash wann Dir e Knäppchen Press, oder de Knäppchen guer net gedréckt. Dëst ass schlecht well sou e Feeler de Benotzer erreechen kann.
Bug am Layout. Zum Beispill gëtt e Knäppchen geklickt, awer ass 10 Pixel no lénks geréckelt.
Erhéijung vun technesch Schold.

Nodeems mir dës Lëscht gekuckt hunn, hu mir gemierkt datt nëmmen déi éischt zwee Punkte kritesch sinn. Mir wëllen esou Problemer als éischt opfänken. Bugs am Layout ginn an der Design-Iwwerpréiwungsstadium entdeckt a kënnen dann einfach korrigéiert ginn. Ëmgank mat technesch Schold verlaangt eng separat Prozess a Planung, sou decidéiert mir et net op engem Pull Ufro ze Test.

Baséierend op dëser Klassifikatioun hu mir d'ganz Lëscht vun de Schecken opgeriicht. Ausgestrach Lint an huet säi Start iwwer Nuecht ofgesot: just fir datt et e Bericht géif produzéieren wéi vill Problemer et am Projet waren. Mir ausgemaach getrennt mat der technesch Schold ze schaffen, an от Android Studio-Checks goufen komplett opginn.. Android Studio an Docker fir Inspektiounen auszeféieren kléngt interessant, awer et ass e bëssen lästeg ze verwalten. All Versiounsupdate Android Studio ass e Kampf géint obskur Käferen. Screenshottester ze maachen war och schwéier, well d'Bibliothéik net ganz stabil war a heiansdo falsch Positiver generéiert huet. Screenshot Tester goufen aus der Checklëscht geläscht.

Als Resultat ware mir lénks mat:

ARK Assemblée;
Junit Tester;
Instrumenter Tester.

Gradle Remote Cache

Ouni schwéier Schecken ass alles besser ginn. Awer et gëtt keng Limite fir Perfektioun!

Eis Applikatioun war schonn an ongeféier 150 Gradle Moduler opgedeelt. Gradle Remote Cache funktionnéiert normalerweis gutt an dësem Fall, also hu mir beschloss et ze probéieren.

Gradle Remote Cache ass e Service deen Artefakte fir individuell Aufgaben an eenzel Moduler kache bauen. Gradle, anstatt de Code tatsächlech ze kompiléieren, benotzt HTTP fir op de Ferncache ze klappen a froen ob iergendeen dës Aufgab scho gemaach huet. Wann jo, download et einfach d'Resultat.

Gradle Remote Cache lafen ass einfach well Gradle en Docker Bild ubitt. Mir hunn dat an dräi Stonnen fäerdeg bruecht.

Alles wat Dir maache musst war Docker starten an eng Zeil am Projet schreiwen. Awer och wann et séier lancéiert ka ginn, dauert et zimlech vill Zäit bis alles gutt funktionnéiert.

Drënner ass de Cache vermësst Grafik.

Ganz um Ufank louch de Prozentsaz vun de Cache-Feeler bei ongeféier 65%. No dräi Wochen hu mir et fäerdeg bruecht, dëse Wäert op 20% ze erhéijen. Et huet sech erausgestallt, datt d'Aufgaben, déi et sammelt, Android D'Applikatioun hat komesch transitiv Ofhängegkeeten, déi dozou gefouert hunn, datt Gradle de Cache verpasst huet.

Duerch d'Verbindung vum Cache hu mir de Bau staark beschleunegt. Awer nieft der Assemblée gëtt et och Instrumentatiounstester, a si huelen eng laang Zäit. Vläicht net all Tester musse fir all Pull-Ufro lafen. Fir erauszefannen, benotze mir Impaktanalyse.

Impakt Analyse

Op enger Pull Ufro sammele mir Git Diff a fanne déi modifizéiert Gradle Moduler.

Et mécht Sënn nëmmen Instrumentatioun Tester ze lafen déi geännert Moduler an all Moduler kontrolléieren, datt op hinnen hänkt. Et ass kee Sënn fir Tester fir Nopeschmoduler ze lafen: de Code do ass net geännert an näischt kann briechen.

Instrumentatiounstester sinn net sou einfach, well se mussen am Top-Level Applikatiounsmodul lokaliséiert ginn. Mir hunn Heuristik mat Bytecode Analyse benotzt fir ze verstoen zu wéi engem Modul all Test gehéiert.

D'Upgrade vun der Operatioun vun den Instrumentatiounstester sou datt se nëmmen déi involvéiert Moduler testen, huet ongeféier aacht Wochen gedauert.

Moossname fir d'Inspektiounen ze beschleunegen hunn erfollegräich geschafft. Vun 45 Minutte si mir erop op ongeféier 15. Et ass schonn normal eng Véierelstonn op e Bau ze waarden.

Awer elo hunn d'Entwéckler ugefaang ze beschwéieren datt se net verstinn wéi eng Builds lancéiert ginn, wou de Log ze gesinn, firwat de Bau rout ass, wéi en Test gescheitert ass, etc.

Probleemer mat Feedback verlangsamen d'Entwécklung, also hu mir probéiert sou kloer an detailléiert Informatioun iwwer all PR ze bidden a wéi méiglech ze bauen. Mir hunn ugefaang mat Kommentaren am Bitbucket zum PR, beweist wéi ee Bau gescheitert ass a firwat, a gezielt Messagen am Slack geschriwwen. Zum Schluss hu mir e PR-Dashboard fir d'Säit erstallt mat enger Lëscht vun alle Builds déi am Moment lafen an hire Status: Schlaang, Lafen, Crash oder fäerdeg. Dir kënnt op de Build klickt an op säi Logbuch kommen.

Sechs Woche goufen u detailléierte Feedback verbruecht.

Pläng

Loosst eis op déi rezent Geschicht goen. Nodeems mir de Feedbackproblem geléist hunn, hu mir en neien Niveau erreecht - mir hunn decidéiert eisen eegene Emulatorfarm ze bauen. Wann et vill Tester an Emulatoren sinn, si si schwéier ze verwalten. Als Resultat sinn all eis Emulatoren an de k8s Cluster geplënnert mat flexiblen Ressourcemanagement.

Zousätzlech ginn et aner Pläng.

Retour Lint (an aner statesch Analyse). Mir schaffen schonn an dëser Richtung.
Run alles op engem PR Blocker Enn-zu-Enn Tester op all SDK Versiounen.

Also, mir hunn d'Geschicht vun der Entwécklung vun der kontinuéierlecher Integratioun an Avito verfollegt. Elo wëll ech e puer Rotschléi ginn aus engem erfuerene Siicht.

Tipps

Wann ech nëmmen ee Rot kéint ginn, wier et dëst:

Sief virsiichteg mat Shell Scripten!

Bash ass e ganz flexibel a mächtegt Tool, et ass ganz bequem a séier Scripte ze schreiwen. Mee du kanns domat an eng Fal falen, a mir si leider dran gefall.

Et huet alles ugefaang mat einfache Scripten déi op eise Baumaschinne lafen:

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

Awer wéi Dir wësst, alles entwéckelt a gëtt mat der Zäit méi komplizéiert - loosst eis ee Skript vun engem aneren ausféieren, loosst eis e puer Parameteren do passéieren - um Enn hu mir eng Funktioun missen schreiwen déi bestëmmt op wéi engem Niveau vum Bash Nesting mir elo an der Rei sinn déi néideg Zitater asetzen, fir dat Ganzt unzefänken.

Dir kënnt d'Aarbechtskäschte fir d'Entwécklung vun esou Scripten virstellen. Ech roden Iech net an dës Fal ze falen.

Wat kann ersat ginn?

All Scripting Sprooch. Schreiwen un Python oder Kotlin Skript méi praktesch well et programméiere ass, net Scripten.
Oder beschreiwen all Build Logik an der Form Benotzerdefinéiert Grade Aufgaben fir Äre Projet.

Mir hunn decidéiert déi zweet Optioun ze wielen, an elo läschen mir systematesch all Bash Scripten a schreiwen vill personaliséiert Gradle Aufgaben.

Tipp #2: Store Infrastruktur am Code.

Et ass bequem wann d'Kontinuéierlech Integratioun Astellung net an der UI Interface vu Jenkins oder TeamCity, etc., awer a Form vun Textdateien direkt am Projet Repository gespäichert ass. Dëst gëtt Versiounsméiglechkeet. Et wäert net schwéier sinn de Code op enger anerer Branche zréckzerollen oder ze bauen.

Scripte kënnen an engem Projet gespäichert ginn. Wat maache mat der Ëmwelt?

Tipp #3: Docker kann mat der Ëmwelt hëllefen.

Android- Et wäert den Entwéckler definitiv hëllefen, leider nach net fir iOS.

Dëst ass e Beispill vun enger einfacher Docker Datei déi jdk an Android-sdk enthält:

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

Nodeems Dir dës Docker-Datei geschriwwen hutt (ech soen Iech e Geheimnis, Dir musst et net schreiwen, awer se just fäerdeg aus GitHub zéien) an d'Bild zesummegesat hunn, kritt Dir eng virtuell Maschinn op där Dir d'Applikatioun bauen kënnt a lafen Junit Tester.

Déi zwee Haaptgrënn firwat dëst Sënn mécht sinn Skalierbarkeet a Widderhuelbarkeet. Mat Docker kënnt Dir séier eng Dose Bauagenten erhéijen déi genau datselwecht Ëmfeld wéi dee virdrun hunn. Dëst mécht d'Liewen vun CI Ingenieuren vill méi einfach. Et ass zimmlech einfach den Android-sdk an den Docker ze drécken, awer mat Emulatoren ass et e bësse méi schwéier: Dir musst e bësse méi haart schaffen (oder de fäerdege vum GitHub eroflueden).

Tipp Nummer 4: Vergiesst net datt d'Inspektiounen net fir d'Inspektioun gemaach ginn, mee fir d'Leit.

Schnell an, am wichtegsten, kloere Feedback ass ganz wichteg fir Entwéckler: wat gebrach ass, wéi en Test gescheitert ass, wou kann ech de Buildlog gesinn.

Tipp #5: Sidd pragmatesch wann Dir Kontinuéierlech Integratioun entwéckelt.

Verstinn kloer wéi eng Zorte vu Feeler Dir wëllt verhënneren, wéi vill Ressourcen, Zäit a Computerzäit Dir bereet sidd ze verbréngen. Kontrollen, déi ze laang daueren, kënnen zum Beispill iwwer Nuecht ausgestallt ginn. An déi vun hinnen, déi net ganz wichteg Feeler opfänken, solle komplett opginn.

Tipp #6: Benotzt fäerdeg Tools.

Et gi vill Firmen elo déi Cloud CI ubidden.

Dëst ass eng gutt Léisung fir kleng Teams. Dir braucht näischt ze ënnerstëtzen, just e bësse Sue bezuelen, Är Applikatioun bauen a souguer Instrumentatiounstester ausféieren.

Tipp #7: An enger grousser Equipe sinn intern Léisunge méi rentabel.

Awer desto oder spéider, wéi d'Team wiisst, wäerten intern Léisunge méi rentabel ginn. Et gëtt ee Problem mat dësen Entscheedungen. Et gëtt e Gesetz vun der Ofsenkung vun de Rendementer an der Wirtschaft: an all Projet ass all spéider Verbesserung ëmmer méi schwéier a erfuerdert ëmmer méi Investitiounen.

Economie beschreift eist ganzt Liewen, inklusiv Kontinuéierlech Integratioun. Ech hunn en Zäitplang vun Aarbechtskäschte fir all Etapp vun der Entwécklung vun eiser Kontinuéierlecher Integratioun gebaut.

Et ass kloer datt all Verbesserung ëmmer méi schwéier gëtt. Wann Dir dës Grafik kuckt, kënnt Dir verstoen datt Kontinuéierlech Integratioun muss am Aklang mat dem Wuesstum vun der Teamgréisst entwéckelt ginn. Fir e Team vun zwee Leit, 50 Deeg ze verbréngen fir en internen Emulator Bauerenhaff z'entwéckelen ass eng mëttelméisseg Iddi. Awer gläichzäiteg, fir e grousst Team, guer net kontinuéierlech Integratioun ze maachen ass och eng schlecht Iddi, well Integratiounsproblemer, Kommunikatioun fixéieren, asw. et wäert nach méi Zäit huelen.

Mir hunn ugefaang mat der Iddi datt d'Automatisatioun gebraucht gëtt, well d'Leit deier sinn, si maachen Feeler a si faul. Awer d'Leit automatiséieren och. Dofir gëllen all déiselwecht Probleemer fir d'Automatisatioun.

Automatisatioun ass deier. Denkt un den Aarbechtsplang.
Wann et ëm d'Automatiséierung geet, maachen d'Leit Feeler.
Heiansdo ass et ganz faul ze automatiséieren, well alles funktionnéiert esou. Firwat soss eppes verbesseren, firwat all dës Kontinuéierlech Integratioun?

Mee ech hunn Statistiken: Feeler ginn an 20% vun Versammlungen gefaangen. An dëst ass net well eis Entwéckler Code schlecht schreiwen. Dëst ass well d'Entwéckler zouversiichtlech sinn datt wa se e Feeler maachen, et net an der Entwécklung ophalen, et gëtt vun automatiséierte Kontrollen gefaangen. Deementspriechend kënnen d'Entwéckler méi Zäit verbréngen fir Code an interessant Saachen ze schreiwen, anstatt eppes lokal ze lafen an ze testen.

Praxis kontinuéierlech Integratioun. Awer a Moderatioun.

Iwwregens, Nikolai Nesterov gëtt net nëmmen super Rapporten selwer, mä ass och Member vun der Programm Comité AppsConf an hëlleft anerer sënnvoll Rieden fir Iech virbereeden. D'Vollständegkeet an d'Nëtzlechkeet vum nächste Konferenzprogramm kënnen duerch Themen bewäert ginn Zäitplang. A fir Detailer kommt den 22-23 Abrëll op Infospace.

Source: will.com