Hat das Team oder die App-Größe Einfluss auf den Veröffentlichungsprozess? Es hängt davon ab. Stellen wir uns ein Startup mit einem kleinen Team vor. In diesem Fall erstellt das Team normalerweise ein Feature und veröffentlicht es dann einfach. Stellen wir uns nun ein großes Projekt vor, zum Beispiel eine Banking-App, an dem viele Teams arbeiten.

In diesem Fall sollte es wahrscheinlich einen Prozess, Veröffentlichungszyklen und möglicherweise etwas Bürokratie geben. Ohne das wird es Chaos geben.

Wann wird also klar, dass es an der Zeit ist, einen solchen Prozess für Ihre App einzurichten?

In diesem Artikel teile ich meine Erfahrungen mit der Implementierung von Release Train für die Dodo Pizza-App (Android und iOS) und die Probleme, mit denen wir konfrontiert waren und die unser Team dazu veranlassten, Release Train zu implementieren.

Wenn Sie Teamleiter/Technischer Leiter eines schnell wachsenden Android- oder iOS-Projekts sind und den Veröffentlichungsprozess noch nicht verwaltet haben, hoffe ich, dass Ihnen unsere Erfahrung weiterhilft.

Wie es einmal war

Im Jahr 2021 nutzten wir in unseren Teams bereits einen Trunk-based Development (TBD)-Ansatz. Wir haben den Code mit Funktionsumschaltungen abgedeckt, Aufgaben zerlegt und Unit- und UI-Tests durchgeführt. Unsere Feature-Zweige lebten nicht lange und wir hatten CI am Laufen.

Der Veröffentlichungsprozess war sehr einfach: Wer bereit war, sein Feature einzuführen, hat es auch eingeführt.

Ideales Szenario

So sah ungefähr unser Filial-Workflow aus. Mehrere Teams (grau, blau, orange und grün) arbeiteten an verschiedenen Funktionen. Da wir nach TBD arbeiteten, konnte jedes Feature mehrere aufeinanderfolgende Zweige durchlaufen.

Zum Beispiel hat das graue Team sein Feature in 4 Schritten erstellt, die blauen und orangen Teams haben sein Feature in einem Schritt erstellt und das grüne Team hat sein Feature in 2 Schritten erstellt.

Wenn ein Team ein Feature fertiggestellt hat, kann es eine Veröffentlichung herausbringen. Wenn das blaue Team beispielsweise ein Feature fertiggestellt hat, könnte es eine Veröffentlichung veröffentlichen. Dann würde das orangefarbene Team ein Feature fertigstellen und eine weitere Veröffentlichung veröffentlichen.

Wir hatten den perfekten Flow, wie es damals schien. Bis zu einem gewissen Punkt hat es großartig funktioniert, aber alle guten Dinge haben ein Ende.

Etwas ist schiefgelaufen: hart, überfüllt und unvorhersehbar

Mammut

Das erste Problem, auf das wir stießen, war, dass Releases anfingen, viele Funktionen anzuhäufen und zu groß wurden.

Die Teams wollten ihre Features nicht immer sofort veröffentlichen. Der Freigabe- und Regressionsprozess war zeitaufwändig und dauerte drei bis vier Tage. Wenn Ihre Funktion also klein und nicht dringend war, hatten Sie nicht immer die Möglichkeit, sie selbst zu veröffentlichen, da wahrscheinlich bald ein anderes Team eine Veröffentlichung herausbringen würde und sie in dieser Veröffentlichung enthalten wäre. In etwa sah es so aus:

Dies war eine ziemlich fragile Vereinbarung, insbesondere als die Anzahl der Teams zu wachsen begann. Viele Teams entwickelten viele kleine Funktionen und die Gesamtmenge an neuem Code in jeder neuen Version wurde riesig. Wenn jemand sein großes Feature veröffentlichen durfte, musste er gleichzeitig ein ganzes Mammut herausbringen.

Die Mammut-Releases führten zu:

• verzögerte Regression;

• höheres Risiko von Regressionsfehlern;

• höheres Risiko eines Fehlers in der Produktion.

Wir mussten es so gestalten, dass die Veröffentlichung irgendwie zustande kam, selbst wenn das blaue und orangefarbene Team aus dem Beispiel nicht veröffentlichen wollte.

Engpässe

Jedes Team ist einzigartig und jede Funktion ist anders. Manchmal passierte es so, dass mehrere Teams ihre Features etwa gleichzeitig fertigstellten. In diesem Fall gab es eine Menge „Warte auf mich, ich füge es morgen früh zusammen, versprochen!“ herumgehen.

Letztendlich führten solche Engpässe zu:

• Freisetzungen, die sich in Mammuts verwandeln;

• Verspätete Veröffentlichungen wirken sich negativ auf die Pläne des Release-Teams aus, insbesondere wenn die Bedürfnisse aller anderen erfüllt wurden.

Wir mussten zwei entscheidende Änderungen vornehmen:

1. Das Release-Team sollte auf niemanden warten müssen;

   
   

2. Jedes andere Team sollte wissen, wann die nächste Veröffentlichung erwartet wird.

Mangelnde Vorhersehbarkeit

Stellen Sie sich vor, das blaue Team hat ein kleines Feature erstellt und erwartet, dass das orange Team es bald veröffentlicht. Aber etwas ist schiefgegangen, und auch das orange Team hat die Veröffentlichung aufgrund einiger eigener Probleme nicht veröffentlicht.

Daraufhin teilte das blaue Team dem Unternehmen mit, dass die Funktion bald in Produktion gehen würde, was sich jedoch als nicht früh genug herausstellte. Daher ist es unmöglich vorherzusagen, wann das Feature in Produktion gehen wird.

Das bedeutet nicht, dass das blaue Team unverantwortlich ist. Wenn sie eine besonders wichtige oder dringende Funktion haben, werden sie diese natürlich selbst veröffentlichen. In anderen Fällen lässt sich jedoch nicht genau sagen, wann die Funktion den Benutzern zur Verfügung stehen wird.

Wie Sie sich vorstellen können, hatten wir solche Probleme ziemlich oft. Wir mussten in der Lage sein, genau zu sagen, wann Kunden ein Feature in Produktion bringen würden, unabhängig von seiner Größe oder Dringlichkeit. Alle drei Probleme (Mammut-Releases, Engpässe und mangelnde Vorhersehbarkeit) hängen eng zusammen und ergänzen sich gegenseitig.

Der wohl grundlegendste und wichtigste von allen ist jedoch der Mangel an Vorhersehbarkeit. Es erzeugt andere Probleme.

Release-Zug

Wir haben genug; Es war Zeit, etwas zu ändern. Der Release Train sollte uns dabei helfen.

Der Begriff „Release Train“ bedeutet verschiedene Dinge: ein geplanter Release-Prozess oder ein spezielles Team , das den Release-Prozess verwaltet. Hier werden wir über den geplanten Veröffentlichungsprozess sprechen.

Mir gefällt die Art und Weise, wie Martin Fowler Release Train im Artikel „ Patterns for Managing Source Code Branches “ beschreibt, und die Definition von Thoughtworks in ihrem Tech-Radar (vielleicht gehört sie auch Martin).

So haben wir Release Train für uns definiert:

Release Train ist der Prozess der Koordinierung von Releases zwischen Teams. Alle Veröffentlichungen erfolgen nach einem festen Zeitplan, unabhängig davon, ob die Funktionen bereit sind oder nicht. Der Zug wartet auf niemanden. Wer zu spät kommt, muss auf den nächsten warten.

Lassen Sie es uns anhand einiger Beispiele anhand unserer farbcodierten Teams aufschlüsseln.

Das Mammutproblem lösen

Release Train erfolgt planmäßig und ist unabhängig davon, wer was in den Hauptzweig eingebunden hat. Im folgenden Beispiel werden die Funktionen der blauen und orangen Teams veröffentlicht. Der Rest wartet auf den nächsten Zug. Wir könnten noch etwas warten, aber dann bekämen wir ein Mammut.

Engpässe beheben

Gleichzeitig hilft uns der Release Train, unsere Arbeit effizienter zu planen. Nehmen wir an, das blaue Team hatte ursprünglich geplant, ein Feature später fertigzustellen. Aber da jeder das Veröffentlichungsdatum kennt, kann er seine Pläne leicht ändern, um das Feature früher fertigzustellen.

Oder im Gegenteil, sie können erkennen, dass sie den nächsten Zug definitiv nicht pünktlich erreichen werden, und können den Beitrag daher sicher beenden, weil sie den gesamten Fahrplan kennen.

Im folgenden Beispiel wollte das blaue Team zum Release gelangen und alle seine Änderungen vor dem Release zusammenführen. Andernfalls könnte es zu einem Engpass gekommen sein.

Am wichtigsten ist, dass uns Release Train von Natur aus Vorhersehbarkeit verschaffte .

Für einige mögen diese Beispiele offensichtlich erscheinen, aber wir haben Probleme sofort gelöst, als sie auftraten. Als es keine Probleme mit Releases gab, haben wir uns nicht die Mühe gemacht, Release Train zu verwenden. Als sich die Probleme häuften, wurde uns klar, dass die Zeit gekommen war.

So implementieren Sie den Release Train in Ihrem Team

Als erstes haben wir einen RFC geschrieben. Ein RFC bezieht sich sowohl auf den Prozess selbst als auch auf das Designdokument, das viele Unternehmen verwenden, bevor sie mit der Arbeit an einem Projekt beginnen. Einige verwenden speziell RFCs, andere ADRs und wieder andere nennen sie einfach mit dem allgemeineren Begriff Design Doc.

Bei Dodo Engineering verwenden wir sowohl RFCs als auch ADRs.

Unser RFC-Prozess sah so aus:

1. Wir haben ein RFC-Dokument erstellt;

   
   

2. wir haben es in einer kleinen Gruppe besprochen, Kommentare gesammelt und Anpassungen vorgenommen;

   
   

3. dann wurde der RFC einer größeren Gruppe mitgeteilt;

   
   

4. dann haben wir es umgesetzt;

   
   

5. Danach sammelten wir Feedback, verfolgten Kennzahlen und bewerteten die Ergebnisse.

Der Aufbau des RFC-Dokuments für unseren Release Train war wie folgt:

• Beschreibung des Release Train-Prozesses;

• welche Teams beteiligt sind, was sie tun;

• wie der Zeitplan aussehen wird;

• Metriken.

Bei der Erstellung des RFC haben wir auf die Erfahrungen anderer Unternehmen zurückgegriffen:

• SkyScanner
• Soundcloud
• Monzo
• Facebook

Erste Implementierung

Zuerst haben wir diesen Prozess entwickelt:

• Veröffentlichung jede Woche;

• Erstellen Sie am Mittwochmorgen einen Release-Zweig.

• Schließen Sie die Regression ab und senden Sie die App am Freitag zur Überprüfung.

• Beginnen Sie am Montag mit der Einführung der Veröffentlichung.

• Release-Team:

  • 1 iOS- und 1 Android-Entwickler aus einem der Feature-Teams;

  • 2 QS-Ingenieure.

    
    

• Erstellen Sie am Mittwoch einen neuen Release-Zweig.

• Machen Sie ein Viertel im Voraus einen Zeitplan und geben Sie an, wann jedes Team mit der Veröffentlichung an der Reihe ist. Nach einem Vierteljahr kommen Sie zusammen und erweitern den Zeitplan.

Schematisch sah unser Release Train so aus:

Es lief nicht alles reibungslos

Nach einem Monat wurde klar, dass sich die erste Erfahrung zwar großartig anfühlte,

• Es war wirklich schwer, jede Woche eine Regression durchzuführen und bis Freitag fertig zu sein;

• Es war keine Zeit für Hotfixes, und manchmal passierten sie.

Im Jahr 2021 dauerte unser Regressionstest durchschnittlich 3–4 Tage. Im Jahr 2022 ist es uns gelungen, die Dauer auf 2–3 Tage zu verkürzen, aber manchmal wurde dieser Zeitrahmen überschritten. Wir deckten weiterhin Regressionsfälle mit e2e-Tests ab, hatten jedoch noch keine 100-prozentige Abdeckung. Wir hatten auf jeder Plattform eine Abdeckung von etwa 70 % bzw. 60 % der Regressionsfälle.

Die Schlussfolgerung daraus ist, dass es wahrscheinlich unbequem sein wird, jede Woche einen Release-Zyklus durchzuführen, solange Regressionstests einige Tage dauern .

Die endgültige Antwort

Am Ende sind wir auf zweiwöchige Release-Zyklen umgestiegen, und Release Train sieht jetzt so aus:

• Veröffentlichung alle 2 Wochen;
• Erstellen Sie am Mittwochmorgen einen Release-Zweig.
• regressieren und die App am Freitag zur Überprüfung senden;
• Beginnen Sie am Montag mit der Einführung der Veröffentlichung.

• Release-Team:

  • 1 iOS- und 1 Android-Entwickler aus einem der Feature-Teams;

  • 2 QS-Ingenieure.

    
    

• Erstellen Sie ein Viertel im Voraus einen Zeitplan und geben Sie an, wann jedes Team mit der Veröffentlichung an der Reihe ist. Treffen Sie sich nach einem Quartal und erweitern Sie den Zeitplan.
• Rollen Sie die Freisetzung schrittweise aus.
• Führen Sie die Hotfixes bei Bedarf durch, wenn wir Zeit dafür haben.
• Erstellen Sie eine Woche später, am Mittwoch, einen neuen Release-Zweig.

So sieht der Ablauf aus, wenn alles nach Plan verläuft:

Es sieht alles wie ein wöchentlicher Zyklus aus, außer dass noch genügend Zeit für mögliche Hotfixes bleibt. So sieht es bei erweiterten Regressionstests aus:

Auch keine große Sache; Selbst für Hotfixes ist noch Zeit.

Wie wirkte sich der neue Prozess auf die Vorhersehbarkeit aus?

Das Hauptziel für uns war die Erhöhung der Vorhersehbarkeit . Es lässt sich in zwei Teile gliedern:

1. Wann wird die Anwendung freigegeben?
2. In welchem Release wird mein Feature verfügbar sein?

Wir haben die Frage „Wann wird es eine Veröffentlichung geben?“ beantwortet. durch die Implementierung des Release Train-Prozesses. Jetzt kann jedes Team die Frage beantworten: „In welcher Version wird mein Feature landen?“ unabhängig in dem Moment, in dem sie das Feature planen und bewerten.

Vorher konnte man das nicht mit Sicherheit sagen, da die Veröffentlichung möglicherweise von einem anderen Team durchgeführt wurde oder nicht. Jetzt hängt alles nur noch von der eigenen Planung des Teams ab.

Um dies weiter zu bestätigen, führten wir Umfragen unter Mobilentwicklern, Qualitätssicherungskräften und Produktmanagern durch, in denen wir neben anderen Fragen auch Folgendes fragten:

• Wann ist die nächste Veröffentlichung? (100 % haben diese Frage beantwortet).

• Hat Ihnen Release Train bei der Planung Ihrer Teamarbeit geholfen? (75 % antworteten positiv, aber einige haben ihre Arbeit auch ohne Release Train perfekt vorhergesagt).

Release Train hat uns auch bei Code-Freezes und Release-Freezes geholfen. Wir hatten mehrere davon, zusätzlich zu Silvester (z. B. den 1. September und einige Feiertage). Mit Release Train müssen wir uns nun nicht mehr an diese Termine anpassen, indem wir Release-Zweige erstellen, Regress-Tests durchführen und so weiter. Veröffentlichungen verlaufen planmäßig; Wir öffnen sie einfach später in den Läden.

Auswirkungen auf Metriken

Wir haben nicht nur Probleme gelöst, sondern auch Kennzahlen gemessen. Werfen wir einen Blick auf die wichtigsten.

Vorlaufzeit

Die erste wichtige Kennzahl, die wir gemessen haben, war die Vorlaufzeit bis zur Veröffentlichung .

So sieht die Grafik aus. Ich habe den Punkt, an dem wir den Release Train-Prozess gestartet haben, mit einem Pfeil markiert.

Die Grafik zeigt, dass die Vorlaufzeit auf etwa sechs Tage gesunken ist. Sind sechs Tage eine lange oder eine kurze Zeit?

Google-Benchmarks

Es gibt Benchmarks von Google für diese Metrik , aber es ist hauptsächlich für das Backend. Auf ihrer Skala unterscheiden sie folgende Gruppen:

• Elite: weniger als eine Stunde
• Hoch: 1 Stunde bis 1 Woche
• Mittel: 1 Woche bis 6 Monate
• Niedrig: 6 Monate oder länger

Ich glaube, dass die Vorlaufzeit für mobile Standard-Apps idealerweise die Hälfte der Länge des Veröffentlichungszyklus anstreben sollte. Dies entspricht dem täglichen Zusammenführen einer Aufgabe im Hauptzweig. Das heißt, wenn der Release-Zyklus 14 Tage beträgt, sollte die Vorlaufzeit auf 7 Tage angestrebt werden .

Fehler pro Regression

Eine weitere Metrik, die wir verfolgen, ist die Anzahl der Fehler pro Regression. Es beschreibt, wie stabil der Release Candidate ist. Wenn die vorherige Version schon lange her ist, haben wir wahrscheinlich viel neuen Code erstellt, der möglicherweise eine große Anzahl von Fehlern enthält, und wir verbringen möglicherweise mehr Zeit mit Regression und Korrekturen.

Zu einem bestimmten Zeitpunkt betrug diese Kennzahl nur noch drei Fehler. Die konkreten Zahlen sind nicht so entscheidend, aber insgesamt lässt sich erkennen, dass der Trend rückläufig ist.

Weitere Kennzahlen

Ich werde kurz darauf eingehen, welche Metriken auch im Rahmen des Release Train überwacht wurden.

• Absturzfrei. Diese Kennzahl haben wir stets im Blick. Es gab die Hypothese, dass es aufgrund unserer Versuche, die Regression in einen engeren Zeitrahmen einzupassen, sinken würde. Nun, es ist kein Tropfen passiert.

• Wir fragten uns, ob häufige (wöchentliche) Veröffentlichungen einen Einfluss auf die Kundenabwanderung und auf die Löschung der App haben würden. Infolgedessen konnten wir keine Auswirkungen feststellen.

Implementieren, verbessern

Uns gefällt der aktuelle Prozess, da wir glauben, dass er seine Ziele erreicht hat. Wir wissen auch, wie wir es noch weiter verbessern können:

• Wir arbeiten weiterhin daran, die Regression zu automatisieren, um sie einfacher und schneller zu machen.

• Bisher haben wir den Teil zur Arbeitsautomatisierung (Skripte für Verzweigungen) weggelassen, aber auch das wäre ein toller Wachstumspunkt in der Zukunft.

• Unsere App funktioniert in 20 Ländern und wir müssen die Anwendung in viele verschiedene Sprachen übersetzen. Dafür gibt es einen internen Service, allerdings müssen Entwickler vor der Veröffentlichung noch manuell an diesem Prozess teilnehmen. Die Automatisierung dieses Prozesses könnte den Release-Zyklus möglicherweise noch weiter verbessern.

Zusammenfassung

Obwohl wir relativ klein waren, brauchten wir keinen Release Train. Als wir mit der Tatsache konfrontiert wurden, dass wir Releases, deren Größe und Anzahl nicht vorhersagen konnten, entschieden wir uns für die Implementierung von Release Train. Zunächst versuchten wir es mit wöchentlichen Release-Zyklen, mussten aber aufgrund zeitaufwändiger Regressionen auf zweiwöchige Release-Zyklen umsteigen. Seitdem leben wir so.

Jetzt sind die Veröffentlichungen vorhersehbar und die Kennzahlen zeigen eine positive Dynamik. Wir planen, die Abdeckung von Regressionsfällen mit e2e-Tests zu erhöhen, den Prozess der Arbeit mit Zweigstellen zu automatisieren und den Übersetzungsprozess zu optimieren.

Ich hoffe, dieser Artikel und unsere Erfahrung werden Ihnen helfen, insbesondere wenn Sie bereits mit ähnlichen Problemen konfrontiert waren und diese Sie zum Nachdenken über den Veröffentlichungsprozess angeregt haben.

Vielen Dank, dass Sie meinen Artikel gelesen haben. Ich hoffe, dass es Ihnen gefallen hat. Wenn Sie Fragen oder Anregungen haben, schreiben Sie mir eine Nachricht in den Kommentaren und ich werde es auf jeden Fall lesen!

Und folge mir auf Twitter . Normalerweise poste ich über Android-Entwicklung und Software-Engineering im Allgemeinen.

Auch hier veröffentlicht