Nachdem der Pull Request gemerged wurde und der Code in develop ist, kann ein passender Zeitpunkt gew\u00e4hlt werden: zum Beispiel nachts, wenn alle Server frei sind, und so viele Pr\u00fcfungen wie m\u00f6glich durchgef\u00fchrt werden.<\/li>\n<\/ul>\n\nEs gefiel uns nicht, Pr\u00fcfungen auf dem eigenen Laptop durchzuf\u00fchren. Wenn ein Entwickler ein Feature abgeschlossen hat, m\u00f6chte er es so schnell wie m\u00f6glich pushen und einen Pull Request \u00f6ffnen. Wenn in diesem Moment einige langwierige \u00dcberpr\u00fcfungen gestartet werden, ist das nicht nur unangenehm, sondern verlangsamt auch die Entwicklung: W\u00e4hrend der Laptop etwas \u00fcberpr\u00fcft, kann man nicht normal arbeiten.<\/p>\n
Es gefiel uns sehr, die Pr\u00fcfungen nachts auszuf\u00fchren, da viel Zeit und Serverkapazit\u00e4t zur Verf\u00fcgung stehen. Leider hat der Entwickler, wenn der Feature-Code in develop ist, viel weniger Motivation, die Fehler zu beheben, die CI gefunden hat. Ich ertappte mich manchmal dabei, als ich im morgendlichen Bericht auf alle festgestellten Fehler schaute, dass ich sie irgendwann sp\u00e4ter beheben w\u00fcrde, weil jetzt in Jira eine coole neue Aufgabe liegt, die ich unbedingt anfangen m\u00f6chte.<\/p>\n
Wenn Pr\u00fcfungen den Pull Request blockieren, ist die Motivation ausreichend, denn solange die Builds nicht erfolgreich sind, gelangt der Code nicht in den develop-Branch, und somit wird die Aufgabe nicht abgeschlossen.<\/p>\n
Letztendlich haben wir eine Strategie gew\u00e4hlt: Nachts f\u00fchren wir so viele Pr\u00fcfungen wie m\u00f6glich durch, und die kritischsten und am wichtigsten schnellen Pr\u00fcfungen starten wir bei Pull-Requests. Aber dabei bleibt es nicht \u2013 parallel optimieren wir die Geschwindigkeit der Pr\u00fcfungen, um sie vom Nachtmodus in Pr\u00fcfungen bei Pull-Requests zu \u00fcberf\u00fchren.<\/p>\n
Zu diesem Zeitpunkt liefen alle unsere Builds schnell genug, daher haben wir einfach den ARK-Build, Junit-Tests und die Berechnung der Codeabdeckung als Blockierer f\u00fcr Pull-Requests aktiviert. Wir haben das aktiviert, dar\u00fcber nachgedacht \u2013 und uns von der Codeabdeckung verabschiedet, weil wir dachten, dass wir sie nicht brauchen.<\/p>\n
F\u00fcr die gesamte Einrichtung der Basis-CI ben\u00f6tigten wir zwei Tage (hier und im Folgenden ist die Zeitabsch\u00e4tzung ungef\u00e4hren, dient zur Ma\u00dfstabserh\u00f6hung). <\/em><\/strong><\/p>\nNachdem wir dies abgeschlossen hatten, begannen wir weiter zu denken \u2013 \u00fcberpr\u00fcfen wir \u00fcberhaupt richtig? Starten wir die Builds bei Pull-Requests korrekt?<\/p>\n
Wir f\u00fchrten die Build-Tests mit dem letzten Commit des Branches durch, von dem der Pull-Request er\u00f6ffnet wurde. Aber die Pr\u00fcfungen dieses Commits k\u00f6nnen nur zeigen, dass der Code, den der Entwickler geschrieben hat, funktioniert. Sie beweisen jedoch nicht, dass er nichts kaputt gemacht hat. Tats\u00e4chlich sollten wir den Zustand des develop-Branches pr\u00fcfen, nachdem das Feature integriert wurde.<\/p>\n
![\"Evolution](\"\/wp-content\/uploads\/2019\/04\/c1a179b68b02c04031177f9bf51a81ed.jpg\")
\n
\nDaf\u00fcr schrieben wir ein einfaches Bash-Skript premerge.sh:<\/strong><\/p>\n#!\/usr\/bin\/env bash\n\nset -e\n\ngit fetch origin develop\n\ngit merge origin\/develop<\/code><\/pre>\n\nHier werden einfach alle neuesten \u00c4nderungen aus develop abgeholt und in den aktuellen Branch gemerged. Wir haben das Skript premerge.sh als ersten Schritt aller Builds hinzugef\u00fcgt und begannen genau das zu \u00fcberpr\u00fcfen, was wir m\u00f6chten, also Integration<\/strong>.<\/p>\nF\u00fcr die Lokalisierung der Probleme, die Suche nach L\u00f6sungen und das Schreiben dieses Skripts ben\u00f6tigten wir drei Tage.<\/em><\/strong><\/p>\nDie Anwendung entwickelte sich weiter, die Aufgaben wurden zahlreicher, das Team wuchs, und manchmal begann premerge.sh uns im Stich zu lassen. In develop drangen konfliktbehaftete \u00c4nderungen ein, die den Build brachen.<\/p>\n
Ein Beispiel daf\u00fcr, wie das passiert:<\/p>\n
![\"Evolution](\"\/wp-content\/uploads\/2019\/04\/6762d9ce4e431549455c49f2317a8f20.jpg\")
\n
\nZwei Entwickler beginnen gleichzeitig, an den Features A und B zu arbeiten. Der Entwickler des Features A entdeckt im Projekt eine nicht verwendete Funktion answer()<\/code> und, wie ein guter Pfadfinder, l\u00f6scht er sie. Gleichzeitig f\u00fcgt der Entwickler des Features B in seinem Branch einen neuen Aufruf dieser Funktion hinzu.<\/p>\nDie Entwickler beenden ihre Arbeit und \u00f6ffnen gleichzeitig einen Pull-Request. Die Builds werden gestartet, premerge.sh \u00fcberpr\u00fcft beide Pull-Requests bez\u00fcglich des aktuellen Zustands von develop \u2013 alle Pr\u00fcfungen sind gr\u00fcn. Danach wird der Pull-Request des Features A gemerged, der Pull-Request des Features B wird gemerged\u2026 Boom! Develop bricht zusammen, weil im Code von develop ein Aufruf einer nicht existierenden Funktion vorhanden ist.<\/p>\n
![\"Evolution](\"\/wp-content\/uploads\/2019\/04\/0261dcc9f7f2e5e018ab136081b4679b.jpg\")
\n
\nWenn develop nicht kompilierbar ist, ist das lokale Katastrophe<\/strong>. Das gesamte Team kann nichts sammeln und zur Pr\u00fcfung \u00fcbergeben.<\/p>\nEs hat sich so ergeben, dass ich mich am h\u00e4ufigsten mit infrastrukturellen Aufgaben besch\u00e4ftigt habe: Analytik, Netzwerk, Datenbanken. Das hei\u00dft, ich habe genau die Funktionen und Klassen geschrieben, die von anderen Entwicklern verwendet werden. Daher bin ich sehr oft in \u00e4hnliche Situationen geraten. Eine Zeit lang hatte ich sogar ein solches Bild.<\/p>\n
![\"Evolution](\"\/wp-content\/uploads\/2019\/04\/0eb1aadd05b33ce995027ab52d5c1e53.jpg\")
\n
\nDa uns das nicht zufriedenstellte, begannen wir, Optionen zu erarbeiten, wie wir das verhindern k\u00f6nnen.<\/p>\n
Wie man develop nicht kaputt macht<\/h2>\n
\nDie erste Option: alle Pull Requests bei der Aktualisierung von develop neu zu erstellen. <\/strong>Wenn in unserem Beispiel der Pull Request mit Feature A zuerst in develop kommt, wird der Pull Request von Feature B neu erstellt, und entsprechend werden die Pr\u00fcfungen aufgrund eines Kompilierungsfehlers nicht bestehen.<\/p>\nUm zu verstehen, wie viel Zeit das in Anspruch nehmen wird, betrachten wir ein Beispiel mit zwei PRs. Wir \u00f6ffnen zwei PRs: zwei Builds, zwei Pr\u00fcfungen. Nachdem der erste PR in develop eingef\u00fcgt wurde, muss der zweite neu erstellt werden. Insgesamt ben\u00f6tigt man f\u00fcr zwei PRs drei Pr\u00fcfungen: 2 + 1 = 3.<\/p>\n
Im Prinzip ist das in Ordnung. Aber wir haben die Statistiken angeschaut, und eine typische Situation in unserem Team war, dass 10 PRs offen waren, und dann ergibt sich die Anzahl der Pr\u00fcfungen als Summe der Progression: 10 + 9 +\u2026 + 1 = 55. Das bedeutet, um 10 PRs anzunehmen, muss man 55 Mal neu erstellen. Und das in einer idealen Situation, in der alle Pr\u00fcfungen beim ersten Mal bestehen, und in der niemand einen zus\u00e4tzlichen Pull Request \u00f6ffnet, w\u00e4hrend wir diese zehn bearbeiten.<\/p>\n
Stellen Sie sich einen Entwickler vor, der es eilig hat, als erster auf die Schaltfl\u00e4che \u201eMerge\u201c zu dr\u00fccken, denn wenn das der Nachbar macht, muss man warten, bis alle Builds von neuem durchlaufen werden\u2026 Nein, das geht nicht, das w\u00fcrde die Entwicklung ernsthaft verlangsamen.<\/p>\n
Die zweite m\u00f6gliche M\u00f6glichkeit: Pull Requests nach dem Code-Review zu erstellen. <\/strong>Das hei\u00dft, Sie \u00f6ffnen einen Pull Request, sammeln die erforderliche Anzahl von Genehmigungen von Kollegen, beheben, was n\u00f6tig ist, und starten dann die Builds. Wenn sie erfolgreich sind, wird der Pull Request mit develop zusammengef\u00fchrt. In diesem Fall gibt es keine zus\u00e4tzlichen Neustarts, aber das Feedback verlangsamt sich erheblich. Ich m\u00f6chte als Entwickler, der einen Pull Request er\u00f6ffnet, sofort sehen, ob er erfolgreich kompiliert. Wenn ein Test fehlschl\u00e4gt, muss er schnell behoben werden. Bei einem verz\u00f6gerten Build verlangsamt sich das Feedback, was auch die gesamte Entwicklung verlangsamt. Das war uns auch nicht recht.<\/p>\nAm Ende blieb nur die dritte Option \u2014 alles selbst zu machen<\/strong>. Unser gesamter Code, alle unsere Quellcodes werden in einem Repository auf dem Bitbucket-Server gespeichert. Daher mussten wir ein Plugin f\u00fcr Bitbucket entwickeln.<\/p>\n![\"Evolution](\"\/wp-content\/uploads\/2019\/04\/5e4b1f770ea1a3449b616c3101640294.jpg\")
\n
\nDieses Plugin \u00fcberschreibt den Mechanismus zum Mergen von Pull Requests. Der Standardablauf beginnt damit, dass ein PR ge\u00f6ffnet wird, alle Builds gestartet werden und eine Code-\u00dcberpr\u00fcfung stattfindet. Sobald die Code-\u00dcberpr\u00fcfung abgeschlossen ist und der Entwickler auf \u201emerge\u201c klickt, \u00fcberpr\u00fcft das Plugin, auf welchen Zustand der develop-Branch die Tests durchgef\u00fchrt wurden. Wenn der develop-Branch nach den Builds aktualisiert wurde, erlaubt das Plugin nicht, dass dieser Pull Request in den Hauptbranch gemergt wird. Es wird einfach die Builds basierend auf dem aktuellen develop-Branch neu gestartet.<\/p>\n
![\"Evolution](\"\/wp-content\/uploads\/2019\/04\/0edee880e1f2d286a0c64033103ac136.jpg\")
\n
\nIn unserem Beispiel mit konfliktierten \u00c4nderungen werden solche Builds aufgrund eines Kompilierungsfehlers nicht bestehen. Somit muss der Entwickler der Funktion B den Code anpassen, die \u00dcberpr\u00fcfungen erneut starten, dann wird das Plugin den Pull-Request automatisch anwenden.<\/p>\n
Vor der Einf\u00fchrung dieses Plugins hatten wir im Durchschnitt 2,7 Pr\u00fcfungen pro Pull-Request. Mit dem Plugin sind es nun 3,6 Pr\u00fcfungen. Damit sind wir zufrieden.<\/p>\n
Es ist anzumerken, dass dieses Plugin einen Nachteil hat: Es startet den Build nur einmal neu. Das bedeutet, dass immer noch ein kleines Zeitfenster bleibt, in dem konflikttierte \u00c4nderungen in develop gelangen k\u00f6nnen. Die Wahrscheinlichkeit daf\u00fcr ist jedoch gering, und wir haben diesen Kompromiss zwischen der Anzahl der Starts und der Wahrscheinlichkeit eines Fehlers in Kauf genommen. In zwei Jahren ist es nur einmal aufgetreten, also war es wahrscheinlich nicht umsonst.<\/p>\n
F\u00fcr die Erstellung der ersten Version des Plugins f\u00fcr Bitbucket haben wir zwei Wochen ben\u00f6tigt. <\/em><\/strong><\/p>\nNeue \u00dcberpr\u00fcfungen<\/h3>\n
\nInzwischen wuchs unser Team weiter. Es wurden neue \u00dcberpr\u00fcfungen hinzugef\u00fcgt.<\/p>\n
Wir haben uns gefragt: Warum Fehler beheben, wenn man sie verhindern kann? Deshalb haben wir eingef\u00fchrt statische Codeanalyse<\/strong>. Wir haben mit lint begonnen, der im Android SDK enthalten ist. Aber zu der Zeit konnte er \u00fcberhaupt nicht mit Kotlin-Code arbeiten, w\u00e4hrend schon 75 % der Anwendung in Kotlin geschrieben waren. Daher wurden dem lint die eingebauten Android Studio-\u00dcberpr\u00fcfungen hinzugef\u00fcgt.<\/strong><\/p>\nDaf\u00fcr mussten wir ziemlich kreativ sein: Wir haben Android Studio in Docker verpackt und sie auf CI mit einem virtuellen Monitor gestartet, damit sie denkt, dass sie auf einem echten Laptop l\u00e4uft. Aber es hat funktioniert.<\/p>\n
Auch in dieser Zeit begannen wir, viele Instrumentierungstests<\/strong> zu schreiben und f\u00fchrten ein Screenshot-Testing ein.<\/strong>. Es handelt sich um die Generierung eines Referenz-Screenshot f\u00fcr eine separate kleine Ansicht, und der Test besteht darin, dass ein Screenshot von dieser Ansicht aufgenommen und pixelgenau mit dem Referenzbild verglichen wird. Wenn es Abweichungen gibt, deutet das darauf hin, dass das Layout irgendwo nicht stimmt oder es Probleme mit den Styles gibt.<\/p>\nAber Instrumentierungstests und Screenshot-Tests m\u00fcssen auf Ger\u00e4ten durchgef\u00fchrt werden: auf Emulatoren oder echten Ger\u00e4ten. Da es viele Tests gibt und diese h\u00e4ufig ausgef\u00fchrt werden, ist eine komplette Farm erforderlich. Eine eigene Farm einzurichten, ist jedoch sehr aufwendig, daher haben wir eine fertige L\u00f6sung gefunden \u2013 Firebase Test Lab.<\/p>\n
Firebase Test Lab<\/h3>\n
\nEs wurde ausgew\u00e4hlt, weil Firebase ein Produkt von Google ist, was bedeutet, dass es zuverl\u00e4ssig sein sollte und kaum jemals eingestellt wird. Die Preise sind vern\u00fcnftig: 5 $ pro Stunde f\u00fcr die Arbeit mit einem echten Ger\u00e4t, 1 $ pro Stunde f\u00fcr die Arbeit mit einem Emulator.<\/p>\n
Die Implementierung von Firebase Test Lab in unser CI hat etwa drei Wochen gedauert.<\/em><\/strong><\/p>\nAber das Team wuchs weiter, und Firebase hat uns leider angefangen im Stich zu lassen. Zu diesem Zeitpunkt gab es keinen SLA. Manchmal lie\u00df Firebase uns warten, bis gen\u00fcgend Ger\u00e4te f\u00fcr die Tests verf\u00fcgbar waren, anstatt diese sofort auszuf\u00fchren, wie wir es gew\u00fcnscht h\u00e4tten. Das Warten in der Warteschlange dauerte bis zu einer halben Stunde, was sehr lange ist. Instrumentierungstests wurden bei jedem PR ausgef\u00fchrt, die Verz\u00f6gerungen haben die Entwicklung stark verlangsamt, und dann kam auch noch die Rechnung f\u00fcr den Monat mit einem gro\u00dfen Betrag. Insgesamt wurde entschieden, auf Firebase zu verzichten und eine interne L\u00f6sung zu entwickeln, da das Team ausreichend gewachsen war.<\/p>\n
Docker + Python + bash<\/h3>\n
\nWir haben Docker genommen, die Emulatoren hinein gepackt und ein einfaches Programm in Python geschrieben, das zum richtigen Zeitpunkt die ben\u00f6tigte Anzahl an Emulatoren in der richtigen Version hochf\u00e4hrt und sie bei Bedarf anh\u00e4lt. Und nat\u00fcrlich ein paar bash-Skripte \u2013 wo k\u00e4men wir ohne die hin?<\/p>\n
F\u00fcr den Aufbau einer eigenen Testumgebung ben\u00f6tigten wir f\u00fcnf Wochen.<\/em><\/strong><\/p>\nIn der Folge gab es f\u00fcr jeden Pull Request eine umfangreiche, die Zusammenf\u00fchrung blockierende Liste von Pr\u00fcfungen:<\/p>\n
\n- Build-ARK;<\/li>\n
- Junit-Tests;<\/li>\n
- Lint;<\/li>\n
- \u00dcberpr\u00fcfungen in Android Studio;<\/li>\n
- Instrumentierungstests;<\/li>\n
- Screenshot-Tests.<\/li>\n<\/ul>\n
\nDies verhinderte viele m\u00f6gliche Fehler. Technisch hat alles funktioniert, aber die Entwickler klagten dar\u00fcber, dass das Warten auf die Ergebnisse zu lange dauert.<\/p>\n
Wie lange ist \"zu lange\"? Wir haben die Daten aus Bitbucket und TeamCity in ein Analysesystem exportiert und festgestellt, dass die durchschnittliche Wartezeit 45 Minuten betr\u00e4gt<\/strong>. Das hei\u00dft, ein Entwickler wartet im Durchschnitt 45 Minuten auf die Ergebnisse der Builds, wenn er einen Pull Request \u00f6ffnet. Meiner Meinung nach ist das sehr viel, und so kann man nicht arbeiten.<\/p>\nNat\u00fcrlich haben wir beschlossen, all unsere Builds zu beschleunigen.<\/p>\n
Wir beschleunigen uns<\/h2>\n
\nAls wir sahen, dass oft Builds in der Warteschlange standen, haben wir zuerst zus\u00e4tzliches Material gekauft<\/strong> \u2014 eine extensive Entwicklung ist am einfachsten. Die Builds stehen nicht mehr in der Warteschlange, aber die Wartezeit hat sich nur minimal verringert, da einige Pr\u00fcfungen von sich aus sehr lange dauerten.<\/p>\nWir entfernen zu lange Pr\u00fcfungen<\/h3>\n
\nUnsere Continuous Integration konnte solche Arten von Fehlern und Problemen erfassen.<\/p>\n
\n- Wird nicht gebaut<\/strong>. CI kann einen Kompilierungsfehler erfassen, wenn aufgrund von Konflikten etwas nicht gebaut werden kann. Wie ich bereits sagte, kann dann niemand etwas bauen, die Entwicklung kommt zum Stillstand und alle sind nerv\u00f6s.<\/li>\n
- Fehler im Verhalten<\/strong>. Zum Beispiel, wenn die Anwendung gebaut wird, aber beim Klicken auf die Schaltfl\u00e4che abst\u00fcrzt, oder die Schaltfl\u00e4che \u00fcberhaupt nicht reagiert. Das ist schlecht, denn ein solcher Fehler kann den Benutzer erreichen.<\/li>\n
- Fehler im Layout<\/strong>. Zum Beispiel, wenn die Schaltfl\u00e4che gedr\u00fcckt wird, aber um 10 Pixel nach links verschoben ist.<\/li>\n
- Zunahme der technischen Schulden<\/strong>.<\/li>\n<\/ul>\n
\nNachdem wir uns diese Liste angesehen hatten, stellte sich heraus, dass nur die ersten beiden Punkte kritisch sind. Solche Probleme wollen wir zuerst erfassen. Layout-Fehler werden in der Design-\u00dcberpr\u00fcfung entdeckt und k\u00f6nnen dort leicht behoben werden. Die Arbeit mit technischen Schulden erfordert einen eigenen Prozess und Planung, deshalb haben wir beschlossen, sie nicht im Pull Request zu \u00fcberpr\u00fcfen.<\/p>\n
Basierend auf dieser Klassifizierung haben wir die gesamte Liste der Pr\u00fcfungen durchgesehen. Wir haben Lint gestrichen<\/strong> und seine Ausf\u00fchrung auf die Nacht verschoben: einfach um einen Bericht dar\u00fcber zu erstellen, wie viele Probleme im Projekt bestehen. Mit den technischen Schulden haben wir beschlossen, getrennt zu arbeiten, und auf die Android Studio Checks ganz verzichtet<\/strong>. Android Studio in Docker f\u00fcr die Ausf\u00fchrung von Inspektionen klingt interessant, bringt jedoch viele Probleme in der Wartung mit sich. Jedes Update der Android Studio-Versionen stellt einen Kampf gegen unverst\u00e4ndliche Bugs dar. Es war auch schwierig, Screenshot-Tests aufrechtzuerhalten, weil die Bibliothek nicht sehr stabil arbeitete und es manchmal zu Fehlalarmen kam. Screenshot-Tests haben wir aus der Liste der Pr\u00fcfungen entfernt<\/strong>.<\/p>\nAm Ende hatten wir:<\/p>\n
![\"Evolution](\"\/wp-content\/uploads\/2019\/04\/b283cfd7772d8f479be0754ebbe51b19.jpg\")