Zug loslassen. Yandex-Bericht

Release-Prozesse in verschiedenen Yandex-Teams (und in großen IT-Unternehmen) sind ähnlich angeordnet, unterscheiden sich jedoch in vielen Details. Mobile Entwickler haben ihre eigenen Besonderheiten: Ihre Releases werden von der Layoutreihenfolge im App Store und bei Google Play beeinflusst. Android-Entwickler Dmitry PolyakovDmpolyakov Er sprach über die Prozesse um ihn herum - wie sein Team einen Release-Zug nach einem Zeitplan sendet, wie außerplanmäßige Releases gestartet werden, Autos zu einem bereits linken Release hinzugefügt werden und was zu tun ist, um auf dem richtigen Weg zu bleiben.


- Hallo allerseits, ich bin Dmitry Polyakov, Android-Entwickler der von mir verwendeten mobilen Anwendung.



Jetzt nehme ich in zwei Teams - Android- und iOS-Entwicklung - jeweils 13 Personen. Dies ermöglicht es uns, viele coole Aufgaben parallel zu erledigen und sie schnell an Benutzer weiterzugeben. In dem Bericht werde ich erzählen, wie wir gelernt haben, mit Git zu arbeiten und in einem Repository zu leben.

Als nächstes werde ich Ihnen erklären, wie unser Veröffentlichungszyklus funktioniert. Manager kommen zu uns und sagen, dass wir diese Funktion so schnell wie möglich einführen möchten. Wahrscheinlich möchte jeder Manager dies. Deshalb haben wir den Veröffentlichungsprozess so eingerichtet, dass wir jede Woche zum App Store und zu Google Play gehen. Ich werde auch über die Tools sprechen, die wir haben und die ich Ihnen empfehlen würde, sie sind cool.

Git Flow

Beginnen wir mit Git Flow. Als Basis haben wir den klassischen Git Flow genommen, der sich jedoch unter unseren Bedingungen und in unserem Team stark verändert hat. Du siehst auch so aus und vielleicht passt etwas davon zu dir, aber etwas nicht. Jedes Team hat seinen eigenen Ansatz für die Arbeit mit Git.

Wie funktioniert es bei uns? Epic ist der Stammzweig für Ihre Funktion, für einige großartige Funktionen. Schauen wir uns zur Verdeutlichung sofort das Produktbeispiel an.



Der Manager kommt und sagt - der Entwickler, machen Sie uns die Funktionalität der Wunschliste mit ausgewählten Produkten in der Anwendung. Der Entwickler startet ein neues Branchenepos und nennt es Wunschliste.



Außerdem zerlegt er es in kleinere Aufgaben, die im Tracker beginnen. Vielleicht funktioniert dies mit dem Netzwerk, dem Rendern der Benutzeroberfläche und dem Schreiben von Tests. Für jede dieser Funktionen startet er eine Aufgabe im Tracker. Und sobald er die Aufgabe erledigt hat, startet er den entsprechenden Feature-Zweig. Brunches sie aus dem gleichen Epos.

Sobald er die Arbeit an einem solchen Feature beendet hat, schüttet er es über die Pool-Anfrage in das Epos. Poolanforderung ist ein solcher Mechanismus, wenn andere Entwickler aus Ihrem Team Ihren Code überprüfen. Wenn sie etwas nicht mögen, erreicht Ihr Code möglicherweise nicht Ihr Epos, was bedeutet, dass Sie erst veröffentlicht werden, wenn Sie eine Übereinstimmung mit ihnen gefunden haben.

Es gibt zwei dieser Gutachter in unserem Team. Sie werden zufällig vergeben. Dies ist ein automatisierter Prozess, bei dem aus den Entwicklern ausgewählt wird, die kürzlich mit denselben Dateien gearbeitet haben, die Sie in Ihrer Poolanforderung geändert haben.



Es stellt sich also heraus, dass mehrere Epen mit eigenen Features parallel im Projekt leben. Ein Epos kann nur eine Funktion haben. Dies kann passieren, wenn wir diese Funktion über die Poolanforderung auf episch hochladen möchten.



Sobald die Arbeit an allen Funktionen innerhalb eines Epos abgeschlossen ist, überlässt die Aufgabe zunächst dem Testteam, dem QA-Team, und sie testen den Zweig funktional. Sobald sie Fehler gefunden haben, bearbeiten Sie sie als Teil dieses Epos. Sobald alle Fehler behoben sind, füllen Sie dieses Epos aus, um es zu entwickeln. Hier führt Ihr Team bereits keine zusätzliche Codeüberprüfung durch, da der gesamte Code bereits in der Phase des Einfrierens von Features in Epic überprüft wurde.

Unsere Entwicklung ist ein solcher Zweig, in den der bereits getestete Code gelangt, weil er in der epischen Phase getestet wird und der Code die Poolanforderung durchlaufen hat.



Auf diese Weise können wir zu Beginn des Release-Zyklus sicher einen neuen Release-Zweig erstellen. Ohne Angst, dass es viele Fehler geben wird, die noch nicht getestet wurden. Aus diesem Grund erstellen wir einen neuen Release-Zweig aus Develop, der derzeit getestet wird. Sobald die Version getestet wurde und wir bereit sind, weiter zum Gate zu gehen, verschmilzt dieser Zweig mit dem Master.

Manchmal haben wir einen Hotfix und es gibt einen separaten Verzweigungstyp dafür. Dies ist eine sehr kurze Version, die schnell eingeführt werden muss. Wir haben keine Zeit, drei oder vier Tage auf den Beginn des nächsten Veröffentlichungszyklus zu warten. Normalerweise ist das etwas Kleines.

Wenn zum Beispiel ein Fehler in die Produktion kam und sehr kritisch ist, müssen wir ihn dringend beheben. Daher stoppen wir die aktuelle Version, führen einen Hotfix für diesen Fehler aus und aktualisieren unsere Version. Aber Hotfix ist nicht immer eine Geschichte über Fehler. Manchmal haben wir einen Produktbedarf.



Sobald beispielsweise der Selbstisolationsmodus in Moskau eingeführt wurde, hatten wir einen Produktbedarf, damit Benutzer Produkte ohne Kontakt bestellen konnten. Wenn Sie jetzt eine Bestellung in unserer Anwendung aufgeben, kann der Benutzer die Funktion „An der Tür lassen“ auswählen. Der Kurier kommt an, lässt das Paket unter der Tür und gibt es Ihnen berührungslos.

Mit dieser Aufgabe in Hotfix haben wir auch solche verschiedenen Widgets aufgenommen, die Sie dazu drängen, zu Hause zu bleiben und Waren per Kurier zu bestellen. Gehen Sie jetzt nicht zu Abholpunkten. Wir haben diese Aufgaben über Hotfix eingeführt, damit wir sie dem Benutzer so schnell wie möglich übermitteln können, da wir sie für wichtig halten.

Wenn wir einen Hotfix haben, brunchen wir ihn vom Master. Von der Entwicklung kann es nicht gebremst werden, weil in diesem Moment neue Epos entwickeln könnten, die noch nicht veröffentlicht worden waren. Aber wir wollen dieses Epos nicht zum Hotfix mitnehmen, damit sie uns nicht zufällig beeinflussen und unseren Hotfix blockieren. Nachdem der Hotfix abgeschlossen ist, fügen wir ihn in den Master ein und fügen ihn zur Entwicklung hinzu, da dieser Code in der Entwicklung noch nicht vorhanden war.



Master ist eine Codebasis, die der neuesten Version der Anwendung entspricht, die sich jetzt im Speicher des Benutzers befindet. Es ist sauber, ohne Fehler, da dort bereits Funktions- und Regressionstests bestanden wurden. Dies ist ein Backup-Zweig.

Wenn unsere Veröffentlichung abgeschlossen ist, gießen wir sie auch wieder in die Entwicklung ein. Denn im Rahmen der Veröffentlichung können Fehler gefunden werden, die bei Funktionstests nicht gefunden wurden, und verschiedene Epen können miteinander in Konflikt stehen. Daher injizieren wir die Version auch in die Entwicklung, sodass wir diese Korrekturen auch in der Entwicklung haben.



Es kann viel Arbeit an Epos geleistet werden, und um mit dem Code in der Entwicklung Schritt zu halten, fügt der Entwickler ihn manchmal seinem Epos hinzu, damit es weniger Einfrierkonflikte gibt.



Da wir "Entwickeln zu Epic" hinzugefügt haben, muss "Epic" aus den gleichen Gründen zu Ihrer Funktion hinzugefügt werden.



In den Namen von Epic- und Feature-Zweigen haben wir eine Ticketnummer im Task-Tracker. Das ist cool, denn genau anhand der Ticketnummer können wir in jedem Teil unserer Anwendung vollständig herausfinden, in welchen Tickets es sich geändert hat, wer diesen Code geschrieben hat und zu welchem ​​Zweck er geschrieben wurde.



Der Release- und Hotfix-Zweig hat in seinem Namen die aktuelle Versionsnummer der Anwendung. Einige Teams kombinieren die Hotfix-Nummer mit der Versionsnummer, was dies mit der Tatsache rechtfertigt, dass Hotfix etwas Kleines und für den Benutzer möglicherweise nicht sehr wichtig ist. Daher erhöhen sie die Version der Anwendung nicht. Wir verwenden diesen Ansatz nicht, da verschiedene Absturzberichte von Herstellern zu uns kommen und wir genau verstehen möchten, ob dieser Bericht im Hotfix oder in der Version enthalten war, um zu wissen, wo nach dem Problem gesucht werden muss.



Master and Develop sind Zweige, die ständig in unserem Repository leben. Einmal erstellt und leben. Deshalb werden sie so prägnant benannt.

So leben wir. Jetzt fühlen wir uns wohl und bequem.

Zug loslassen

Wir gehen zu unseren Release-Prozessen über. Bevor wir jedoch über Releases sprechen und wie wir sie erstellen, werde ich über die Rollen sprechen, die wir zur Unterstützung des Releases benötigen.

Wir haben einen Bereitschaftsentwickler, der sich innerhalb einer Arbeitswoche nicht mehr mit Produktaufgaben befasst und Fehler aus der aktuellen Version behebt. Wenn er für die aktuelle Version keine Aufgaben hat, wird er einige technische Schulden beheben, die wir angehäuft haben, Aufgaben aus dem Rückstand übernehmen und korrigieren.

Es gibt auch einen Tester im Dienst. Er beendet auch das Testen von Produktaufgaben innerhalb einer Arbeitswoche und überprüft die aktuelle Version. Wenn er für die aktuelle Version keine Aufgaben hat, testet er, was im Rahmen der technischen Schulden korrigiert wurde.



Die Veröffentlichung beginnt am Freitag. An diesem Tag haben wir eine harte Frist. Um 18 Uhr abends klickt der diensthabende Tester auf die Schaltfläche "Release starten". Nach diesem Moment fällt nicht mehr alles, was in die Entwicklung eingegossen wird, nicht mehr in die aktuelle Version, da nach dem Klicken auf die Schaltfläche ein Veröffentlichungszweig erstellt wurde, die Entwicklung zusammengeführt wurde und dort keine weiteren eingegossen werden.

Ein weiterer wichtiger Prozess findet am Freitag statt, ein weiterer Punkt in der aktuellen Version, auf den ich später noch eingehen werde.



Wir machen am Wochenende eine Pause, also ist der zweite Veröffentlichungstag Montag. Der diensthabende Entwickler beginnt den Tag mit einer Analyse. Er untersucht, was in der aktuellen Version in Bezug auf Code geändert wurde. Nimmt Git-Unterschied zwischen dem aktuellen Release-Zweig und dem Master. Und durch diesen Unterschied untersucht er, welche Komponenten betroffen sind. Dies kann sich auf den Bestellvorgang oder den Warenkorb auswirken, und die Arbeit mit Sockeln ist nicht betroffen.

So bildet er eine Liste verschiedener Fälle, die während des Tests getestet werden. Dies hilft uns, unsere Regression zu beschleunigen und nicht die gesamte Anwendung zu überprüfen. Wenn die Liste erstellt ist, überprüft das Testteam die Anwendung und der diensthabende Entwickler korrigiert die Fehler. Wenn er viele Fehler hat, kann er einen Teil an andere Entwickler delegieren, die kürzlich mit diesen Codeteilen gearbeitet haben.



Am Dienstag testen wir weiterhin unsere Version und beheben Release-Fehler. Gegen Nachmittag endet unser Regressionstest und wir sind bereit, zum Tor zu gehen. Wir starten unseren Release-Zug - sogar mehrere Release-Züge, weil wir kürzlich einen neuen Marktplatz für uns betreten haben. Ich empfehle außerdem, dass Sie versuchen, nicht nur auf Google Play, sondern auch in einigen anderen zu veröffentlichen. Das Plus ist nicht nur, dass Sie ein neues treues Publikum bekommen.

Irgendwie haben wir unsere Version veröffentlicht und nach einigen Stunden festgestellt, dass die Anzahl der Fehler unter den Benutzern erheblich gestiegen ist. Wir haben uns diese Fehler angesehen, sie analysiert und festgestellt, dass sie nur auf Huawei-Geräten auftreten. Wir haben nicht sofort verstanden, was passiert ist, aber wir hatten Huawei, wir haben sie getestet, einen Fehler gefunden, ihn behoben und sind zum Update gegangen.

Sobald wir mit dem Update auf Google Play ankamen, sahen wir ein großes Banner, auf dem stand, dass Google Play aufgrund der aktuellen Situation in der Welt sehr stark ausgelastet ist und keine Zeit hat, Anwendungen so schnell wie üblich zu überprüfen. Es stellte sich heraus, dass wir noch keine Zeit hatten, unsere Anwendung zu überprüfen. Wir erreichten keine Google Play-Nutzer, sondern wurden nur in der Huawei AppGallery veröffentlicht. Und das war der Grund, warum wir nur auf Huawei Fehler hatten. So war es möglich, einen kritischen Fehler bereits vor der Veröffentlichung auf Google Play zu erkennen und zu beheben.

Als Nächstes werde ich Ihnen erläutern, wie Veröffentlichungen über Google Play angeordnet werden, da wir dort einen sehr großen Anteil an Nutzern haben. Und bei Huawei AppGallery sind wir kürzlich gegangen und versuchen immer noch zu verstehen, wie alles dort angeordnet ist.

Wir veröffentlichen nicht sofort für alle Nutzer bei Google Play, sodass ein zufälliger Fehler nicht unser gesamtes Publikum betrifft. Wir veröffentlichen nur für alle Tester, die sich der Tatsache anschließen, dass sie möglicherweise einen Fehler haben, aber sie werden die ersten sein, die unsere Änderungen und Veröffentlichungen erhalten. Darüber hinaus veröffentlichen wir nur fünf Prozent des Publikums.



Am Mittwoch sieht sich der diensthabende Entwickler eine absturzfreie Neuerscheinung an. Für uns ist es wichtig, dass es keinen neuen Absturz gibt und dass es nicht sehr viele alte gibt. Wenn alles normal ist, überprüft er immer noch die Produktmetriken. Zum Beispiel, damit die Anzahl der Bestellungen im Vergleich zum gleichen Zeitraum nicht sinkt. Wenn unsere Produktmetriken und die Absturzfreiheit gut sind, führen wir weitere 5% ein, insgesamt 10%.



Am Donnerstag überprüft der diensthabende Entwickler die Bewertungen im Geschäft. Tatsächlich beobachtet er sie am Mittwoch. Zwar haben wir am Mittwoch noch ein kleines Publikum, ein oder zwei Kritiken. Aber am Donnerstag gibt es weitere Bewertungen, um die Veröffentlichung zu beurteilen. Es können 10-15 Stück sein.

Warum schaut er sich überhaupt Bewertungen an, wenn wir viele Metriken und Grafiken haben? Die Anwendung stürzt möglicherweise nicht ab, auch Metriken sind möglicherweise in Ordnung. Es ist jedoch möglich, dass der Benutzer über Schriftarten verfügt oder ein Filter für ihn nicht funktioniert. Wir versuchen, die Verwendung der Anwendung für den Benutzer so bequem wie möglich zu gestalten und solche Überprüfungen zu analysieren, Fehler oder Probleme zu beheben, auf die der Benutzer stößt.

Wenn die Bewertungen in Ordnung sind, ist auch Absturzfreiheit normal und die Produktmetriken sind nicht gesunken. Wir rollen bereits um 20% aus.



Und so beginnt es am Freitag, dem Starttag unserer Veröffentlichung. Der dritte Punkt, über den ich sprechen wollte, ist, dass wir am Freitag die aktuelle Version fertigstellen werden. Wir rollen es sofort von 20% auf 100%. Es scheint ein sehr großer Sprung und sehr riskant zu sein. Aber es kommt auf das Team und Ihr Publikum an.

20% unseres Publikums erlauben es uns mit hoher Wahrscheinlichkeit, die Stabilität der Veröffentlichung zu beurteilen. Und wenn alles um 20% gut ist und wir am Freitag keine Probleme gesehen haben, gehen wir direkt zum Hundertsten.

Ich kenne die Teams, die Life Hack bei Google Play verwenden - vielleicht hilft er Ihnen auch. Sie können nicht zu 100%, sondern zu 99,9% ausrollen. Dadurch erhalten Sie eine Schaltfläche in Google Play, mit der Sie die Veröffentlichung dringend beenden können. Und wenn Sie 100% ausrollen, verschwindet diese Schaltfläche. Aber wie gesagt, von zwanzig Prozent unseres Publikums können wir die Stabilität der Veröffentlichung genau beurteilen. Daher rollen wir ruhig zu 100% aus, was uns zusätzliche Schritte erspart. Und dann müssen Sie weitere 0,01% würfeln.

Dies ist unser Prozess, also fahren wir jede Woche und versuchen, uns nicht zu verlaufen.


Welche anderen Werkzeuge müssen wir verwenden, um das gute Leben des Benutzers auf seiner Seite zu unterstützen? Dies sind Force Update, Soft Update und Feature Toggle.



Update erzwingen - Ein Mechanismus, der die Verwendung der Anwendung blockiert, wenn ihre Version sehr veraltet ist. Die Version, die als veraltet gilt, wird im Admin-Bereich auf dem Server festgelegt. Und sobald die Nummer dort geändert wurde, haben einige Anwendungen eine solche Box, die Sie nicht mehr loslässt. Es wird nur eine Schaltfläche Aktualisieren angezeigt, der Benutzer muss ein Upgrade durchführen.

Wir versuchen, diesen Mechanismus so wenig wie möglich zu nutzen, aber manchmal ist er sehr wichtig. Wenn wir beispielsweise die Abwärtskompatibilität unterbrochen haben, haben wir eine neue Funktion eingeführt, die im alten Code nicht unterstützt wird. Dann kann der Benutzer der veralteten Version der Anwendung in einen nicht konsistenten Zustand geraten. Er wird in den Korb gehen und zum Beispiel keine Bestellung haben. Er wird nicht verstehen warum, obwohl in der neuen Version alle Fehler registriert sind und es klar sein wird, warum es nicht möglich ist, eine Bestellung aufzugeben.



Um Force Update zu unterstützen, gibt es ein Soft Update. Dies ist eine native Sache von Google, die einfach in Ihre Anwendung eingebettet ist und die Verwendung nicht blockiert. Aber sie sagt - es gibt ein Update bei Google Play, installiere es und du wirst neue coole Sachen haben.

Zunächst wird es durch einen solchen Dialog umgesetzt. Dies ist ein natives Design von Android. Und dann kann es in Ihre Anwendung eingebettet werden. Zum Beispiel haben wir es in unserem Widget "Update the application" in unserem Farbschema implementiert.

Mit Soft Update konnten wir den Versionsschwanz erheblich reduzieren und es wird einfach gemäß der Dokumentation implementiert. Probieren Sie es aus, wenn Sie viele Releases haben.



Ein weiteres wichtiges Tool ist Feature Toggle. Sie können einen Teil der Funktionalität auf der Benutzerseite anpassen und im Admin-Bereich ändern. Es gibt eine Reihe von Funktionen, die wir ohne zusätzliche Anwendungsaktualisierungen von unserem Server aus ein- und ausschalten können.

Lassen Sie uns am Beispiel einer Drittanbieteranwendung - einem Fahrzeug - darüber sprechen, wie Feature Toggle funktioniert. Anfangs haben Entwickler genau ein solches Fahrrad, das bereits zwei Feature Toggle hat: einen Motor und eine große Größe. Kunden benutzen das Fahrrad, dann sagt das Testteam: Wir haben den Motor getestet, er funktioniert, fährt, kühlt, wir schalten ihn für den Benutzer ein.



Wir gehen zum Admin-Bereich, schalten Feature Toggle und das Fahrrad ein, ohne den Benutzer zu aktualisieren. Unterwegs verwandelt es sich in ein Moped. Der Benutzer fühlt sich wohl, so kann er sich schneller und bequemer bewegen.

Das Produkt entwickelt sich, das Publikum wächst, es passt nicht mehr auf ein Moped. Benutzer möchten ihre Familie mitnehmen und zusammen fahren. Entwickler und Manager haben einen zusätzlichen Feature Toggle bereitgestellt - eine große Größe. Wir aktivieren es im Admin-Bereich und das Fahrzeug des Benutzers wird unterwegs größer.



Es scheint cool: Feature Toggle hilft uns. Dies ist wahr, aber es gibt Probleme, auf die Sie möglicherweise stoßen. Beispielsweise müssen Sie die Abwärtskompatibilität und die Feature Toggle-Kompatibilität überwachen. Angenommen, die Anwendung bricht irgendwann den Motor, es kommt zu einem Absturz oder Fehler. Oder dieser Motor verbraucht viel von unseren Ressourcen und wir können nicht zu viele Benutzer mit dem Motor unterstützen. Dann müssen wir es ausschalten.

Wir möchten jedoch nicht, dass die Anwendung des Benutzers verschwindet. Wir möchten ihm die Möglichkeit geben, die Anwendung zu verwenden, obwohl er immer noch einen Toggle mit einer großen Größe hat. Wenn wir den Motor abstellen, müssen wir daher einen Fallback-Mechanismus zur Steuerung des Fahrzeugs haben. In diesem Fall ist dies ein solcher Hybrid.



Vielleicht war es erwägenswert, dass sich das Dach zurücklehnt. Vielleicht ist es dem Fahrer unangenehm, auf einem solchen Sitz zu sitzen. Aber er wird weiterhin in der Lage sein, ein Fahrzeug zu fahren, die Anwendung zu verwenden und nicht zu gehen.

Wie verwenden wir Feature Toggle sonst noch? Angenommen, Backends werden noch entwickelt und sind nicht zur Veröffentlichung bereit. Dann können wir einen Teil der Funktionalität entwickeln, den API-Vertrag für die gesamte Kommunikation mit dem Backend unterstützen, die Benutzeroberfläche unterstützen und bei deaktiviertem Feature Toggle den Rollout durchführen. Sobald die Backends fertig sind, werden wir testen, ob alles gut funktioniert, und in diesem Fall Feature Toggle aktivieren. Dann muss der Benutzer nicht aktualisiert werden, um neue Funktionen zu erhalten. Das heißt, wir werden bereits ein Publikum haben, wir werden sofort in diesem Publikum erscheinen. So toll auch.



Wie ich bereits sagte, haben wir jetzt 13 Mitarbeiter in jedem der Android- und iOS-Entwicklungsteams. Wir arbeiten an einem Git Flow in einem Repository, richten unseren geplanten Release-Prozess ein, verkürzen die Markteinführungszeit und fahren jede Woche. Wir haben kürzlich die Huawei AppGallery veröffentlicht und schauen uns andere Geschäfte an. Wir haben gelernt, wie Benutzeranwendungen aufgrund von Feature Toggle ohne Updates geändert werden können. Vielen Dank für Ihre Aufmerksamkeit.