Hallo! Mein Name ist Mikhail Bulgakov (nein, kein Verwandter), ich arbeite als Release Engineer bei Badoo. Vor fünf Jahren begann ich mit der Automatisierung der Veröffentlichung von iOS-Anwendungen, auf die ich in diesem Artikel ausführlich eingegangen bin . Und dann nahm er Android-Anwendungen auf.
Heute werde ich einige Ergebnisse zusammenfassen: Ich werde Ihnen erzählen, wozu wir in dieser Zeit gekommen sind. Kurz gesagt: Jeder an dem Prozess beteiligte Mitarbeiter kann mit wenigen Klicks mindestens alle unsere Anwendungen auf beiden Plattformen freigeben - ohne Kopfschmerzen, Zeitaufwand, Registrierung und SMS. So hat unsere Abteilung für Release-Ingenieure im Jahr 2019 etwa 830 Stunden eingespart.
Für Details - willkommen unter dem Schnitt!
Was steckt hinter der mobilen Version?
Die Veröffentlichung der Anwendung in Badoo besteht aus drei Schritten:
- Entwicklung.
- : , — , App Store Google Play.
- , -.
Wenn die Anwendung vollständig fertig ist und die erste Stufe bestanden wurde, ist es wichtig, sie nicht in der Freigabestufe zu reparieren und das Produkt zum "Zähler" zu bringen. Diese letzte Phase scheint die einfachste zu sein, aber tatsächlich dauert es viel Zeit und ihr Erfolg hängt von einigen wenigen Menschen ab.
Die meiste Zeit wird für die Vorbereitung der Anwendungspräsentation im App Store oder bei Google Play aufgewendet: Sie müssen schöne Screenshots hochladen, eine verlockende Beschreibung erstellen, für eine bessere Indizierung optimiert und Schlüsselwörter für die Suche auswählen. Die Popularität der Anwendung hängt direkt von der Qualität dieser Arbeit ab, dh das Ergebnis der Aktivitäten von Entwicklern, Testern, Designern, Produktmanagern und Vermarktern - allen, die an der Erstellung des Produkts beteiligt sind.
Wenn die Anwendung in mehreren Sprachen vorliegen soll, ist mindestens eine separate Person oder sogar mehrere Mitarbeiter erforderlich, um das Schaufenster vorzubereiten: ein Produktmanager, der die Beschreibungstexte schreibt, die Übersetzung in alle Sprachen organisiert und die technischen Spezifikationen für die Erstellung von Screenshots erstellt, ein Designer, der Screenshots erstellt Überlagerter Text, Gerätekonturen usw. und natürlich Übersetzer, die alle Screenshots und Texte in verschiedene Sprachen übersetzen.
Der letzte Teil der Arbeit ist der Release-Prozess selbst. Ein kleines Release-Engineering-Team benötigt viel Zeit. In dieser entscheidenden, aber eher routinemäßigen Phase haben wir versucht, die Anzahl der Fehler und den Einfluss des menschlichen Faktors zu minimieren. Zu diesem Zweck musste zunächst das Laden von Metadaten (Text- und Grafikdesign des Anwendungsschaufensters) automatisiert werden. Auf diese Weise können Sie die Zeitkosten erheblich senken und Geschäftsversionen schnell implementieren (z. B. die Anwendung für den Valentinstag gestalten).
Da die Entscheidung über die Bereitschaft des Antrags auf Veröffentlichung in Badoo vom QA-Ingenieurteam getroffen wird, haben wir beschlossen, ihnen das Recht zu geben, den "roten Knopf" des Veröffentlichungsstarts zu drücken. Gleichzeitig wollten wir, dass es auch von mobilen Geräten aus zugänglich ist (mit einer visuellen Anzeige des Skriptfortschritts).
Erste Schritte zur Automatisierung: Laden Sie Metadaten herunter
So funktionierte es ganz am Anfang: Für jede Version wurde in Google Sheets eine Tabelle erstellt, in der der Produktmanager den verifizierten Mastertext in Englisch hochlud. Anschließend übersetzten die Übersetzer ihn für ein bestimmtes Land, einen bestimmten Dialekt und eine bestimmte Zielgruppe. Anschließend übertrug der Release-Ingenieur alle Informationen von dieser Tabelle im App Store oder bei Google Play.
Der erste Schritt zur Automatisierung bestand darin, die Übersetzung von Texten in unseren gesamten Übersetzungsprozess zu integrieren. Ich werde nicht weiter darauf eingehen - dies ist ein separates großes System, über das Sie in unserem letzten Artikel lesen können. Der Hauptpunkt ist, dass Übersetzer keine Zeit mit Tablets verschwenden und mit der Benutzeroberfläche arbeiten, um bequem von Hand übersetzte Versionen in Str. (Lesen: Strg + Strg + V) zu übersetzen. Darüber hinaus gibt es die Voraussetzungen für die Versionierung und die Grundlage für Infrastructure-as-Code.
Gleichzeitig haben wir das Entladen von vorgefertigten Übersetzungen aus der Datenbank hinzugefügt und diese in die zusammengestellte IPA-Datei (Dateierweiterung der iOS-Anwendung) eingebettet. Wir erstellen die Anwendung in TeamCity. Somit hatte jede Version der Anwendung immer eine neue Übersetzung ohne manuellen Eingriff in den Erstellungsprozess.
Wir haben einige Zeit so gelebt, und im Allgemeinen passte alles zu uns. Aber die Anzahl der Anwendungen nahm zu und damit die Zeit, jede Version vorzubereiten.
Unsere Realität ab 2015
Im Durchschnitt dauerte die Veröffentlichung einer Anwendung in Gegenwart der aktuellen Version der Screenshots etwa eineinhalb bis zwei Stunden Arbeit des Release-Ingenieurs bei iOS und etwa eine halbe Stunde bei Android. Der Unterschied ist auf die Tatsache zurückzuführen, dass iOS-Anwendungen die sogenannte Verarbeitung durchlaufen müssen, was einige Zeit in Anspruch nimmt (es ist unmöglich, eine Anwendung an Review zu senden, bevor die Verarbeitung erfolgreich abgeschlossen wurde). Darüber hinaus war der App Store selbst für die meisten Vorgänge zu dieser Zeit viel langsamer als Google Play.
Es stellte sich heraus, dass wir ein zusätzliches Tool für die Bereitstellung von Anwendungen für Geschäfte benötigten. Und genau in diesem Moment begann ein Produkt namens Fastlane auf dem Open-Source-Markt an Popularität zu gewinnen. Trotz der Tatsache, dass er damals noch feucht war, konnte er bereits eine große Schicht unserer Probleme lösen ...
Ich werde ein paar Worte über ihn sagen, damit klarer wird, was weiter besprochen wird.
Fastlane auf einen Blick
Heute ist Fastlane ein Produkt, mit dem alle Aktionen vom Moment der Entwicklung bis zur Veröffentlichung der Anwendung im App Store und bei Google Play fast vollständig automatisiert werden können. Und es geht nicht nur darum, Texte, Screenshots und die Anwendung selbst herunterzuladen - hier finden Sie Zertifikatsverwaltung, Betatests, Codesignatur und vieles mehr.
Wir haben Fastlane in seiner „Jugend“ und Instabilität getroffen. Aber jetzt ist es ein sicher arbeitender und integraler Bestandteil vieler Entwicklungsteams für mobile Anwendungen, die mit dem Problem der enormen Zeitkosten für die Lieferung ihrer Produkte an Benutzer konfrontiert sind. Das Interessanteste daran ist die Möglichkeit, eigene Plugins für die Hauptkomponente zu schreiben und von der Community geschriebene Plugins zu verwenden. Für ein solches spezifisches Produkt ist dies eine gute Lösung, die (was wichtig ist) dazu beiträgt, keine „zusätzlichen“ Technologien in DevTools zu produzieren.
Es weckt auch das Vertrauen, dass der Gründer und Hauptentwickler von Fastlane von Google engagiert wurde: Jetzt unterstützt die Komponente nicht nur die Community, sondern auch sich selbst.
Im Laufe der Zeit haben wir die meisten von Fastlane bereitgestellten Funktionen in die Build-, Sign-, Fill- usw. Systeme unserer Anwendungen implementiert. Und unglaublich glücklich darüber. Warum das Rad neu erfinden und sogar seine korrekte Form beibehalten, wenn Sie einmal ein einheitliches Skript schreiben können, das sich in einem CI / CD-System dreht?
IOS Release Automation
Aufgrund der Tatsache, dass Google Play für Entwickler freundlicher ist, dauerte die Veröffentlichung einer Android-Anwendung nur sehr wenig: einige Minuten ohne Aktualisierung von Texten, Videos und Screenshots. Daher der Mangel an Automatisierungsbedarf. Beim App Store war das Problem jedoch sehr greifbar: Das Senden von Anwendungen an Review dauerte zu lange. Daher wurde beschlossen, die Automatisierung mit iOS zu starten.
Wir haben über die Ähnlichkeit unseres Systems zur Automatisierung der Interaktion mit dem App Store nachgedacht (und sogar Prototypen erstellt), aber wir hatten nicht die Ressourcen, um das System fertigzustellen und zu aktualisieren. Es gab auch keine mehr oder weniger adäquate API von Apple. Nun, der letzte Nagel im Sarg unserer benutzerdefinierten Lösung wurde durch regelmäßige Updates des App Store und seiner Mechanismen angetrieben. Also haben wir uns entschlossen, Fastlane auszuprobieren - dann noch die Version 2015.
Der erste Schritt bestand darin, einen Mechanismus zum Hochladen übersetzter Texte für Anwendungen in die gewünschte Struktur als Bestandteil unseres gemeinsamen internen AIDA-Systems (Automated Interactive Deploy Assistant) zu schreiben. Dieses System ist eine Art Hub, eine Verbindung zwischen allen in Badoo verwendeten Systemen, Technologien und Komponenten. Es funktioniert auf einem selbstgeschriebenen Warteschlangensystem, das auf Golang und MySQL implementiert ist. Wartet und verbessert es hauptsächlich Department Release Engineering. Wir haben bereits 2013 in dem Artikel ausführlicher darüber gesprochen , seitdem hat sich viel geändert. Wir versprechen, noch einmal darüber zu sprechen - AIDA ist cool!
Im nächsten Schritt wurden die hochgeladenen Texte an Fastlane weitergeleitet, das sie in den App Store hochlud. Danach musste ich in die App Store-Oberfläche gehen, die gewünschte heruntergeladene Version manuell auswählen und die Anwendung zur Überprüfung senden, wenn die Verarbeitung bis dahin bereits abgeschlossen war.
Dies reduzierte die Vorbereitungszeit der Veröffentlichung von ein paar Stunden auf ungefähr 30 Minuten, von denen nur eineinhalb Minuten etwas mit Ihren Händen zu tun hatten! Der Rest der Zeit ist zu warten. Warten Sie auf das Ende der Verarbeitung. Der Mechanismus war zu dieser Zeit ein Durchbruch, gerade weil er uns bei der Vorbereitung des AppStore für die Veröffentlichung fast vollständig vor manueller Arbeit bewahrt hat. Wir haben ein Repository für das Skript erstellt, auf das wir Zugriff auf Personen gewähren, die in direktem Zusammenhang mit Releases stehen (Projektmanager, Release-Ingenieure).
In diesem Modus haben wir einige Zeit gelebt. Aber irgendwann führte dieses Schema dazu, dass sich viel "heiliges Wissen" ansammelte, dessen Besitzer und infolgedessen das allgemeine Bild der Ereignisse zu einer einzigen Person wurde, und das ist nicht gut. Speziell für diese Person: Ohne Laptop kann man nicht einmal in den Urlaub fahren.
Darüber hinaus gab es viele verstreute Infrastrukturkomponenten um diesen Mechanismus, die praktisch nicht miteinander in Beziehung standen.
- Sie mussten für einen neuen Build zu TeamCity gehen, die IPA-Datei von dort herunterladen und über den Anwendungsmanager in den App Store hochladen.
- Gehen Sie dann zur Benutzeroberfläche mit Übersetzungen in AIDA, prüfen Sie, ob alle Übersetzungen fertig sind, führen Sie das Skript aus und stellen Sie sicher, dass es ordnungsgemäß funktioniert (schließlich war Fastlane zu diesem Zeitpunkt noch feucht).
- App Store , Processing.
- Review.
Und so bei jeder Anwendung. Ich möchte Sie daran erinnern, dass wir damals acht davon hatten.
Der nächste Schritt bestand darin, das Skript auf unsere AIDA zu übertragen und gleichzeitig alle Schritte zu kombinieren und zu automatisieren, bis die Anwendung gesendet wird: Überprüfung der Übersetzungsbereitschaft, Sammeln von Daten aus TeamCity, Benachrichtigung, Protokollierung und alle anderen Vorteile des 21. Jahrhunderts. Parallel dazu haben wir bereits in der Erstellungsphase begonnen, alle erstellten Versionen auf TestFlight hochzuladen.
TestFlight ist eine Drittanbieteranwendung, die von Apple gekauft wurde, um die fertige Anwendung von externen Testern in fast einer Produktionsumgebung zu testen, dh mit Push-Benachrichtigungen und all dem.
AIDA gut gemacht, sei wie AIDA!
All dies führte zu einer Verkürzung der Zeit von einer halben Stunde auf eineinhalb Minuten für alles: Die IPA-Datei hatte Zeit, die Verarbeitung zu durchlaufen, noch bevor das QA-Engineering-Team den Startschuss für die Veröffentlichung gab. Wir mussten jedoch immer noch in den App Store gehen, die gewünschte Version auswählen und sie an Review senden.
Außerdem wurde eine einfache Oberfläche gezeichnet: Wir alle lieben Klats-Klats.
So Tab für Tab, Strg + C Strg + V ...
Android Release Automation
Dann stellte sich die Frage nach der Automatisierung von Releases von Android-Anwendungen. Obwohl dieser Prozess viel schneller war, war es notwendig, ziemlich viel von Hand zu tun:
- Gehen Sie zur Google Play-Konsole, um sicherzustellen, dass die vorherige Version zu 100% ausgerollt oder eingefroren ist.
- Erstellen Sie eine neue Version der Version mit aktualisierten Texten und Screenshots (falls vorhanden).
- Laden Sie die APK-Datei (Android Package) und die Mapping-Datei herunter.
- Gehen Sie zu HockeyApp (das zu diesem Zeitpunkt zum Protokollieren von Abstürzen verwendet wurde) und laden Sie dort die APK-Datei und die Zuordnungsdatei hoch.
- Gehen Sie zum Chat und melden Sie sich über den Veröffentlichungsstatus ab.
Und so bei jeder Anwendung.
Ja, Google Play verfügt über eine eigene API. Aber warum einen Wrapper erstellen, Änderungen im Protokoll überwachen, es warten und Entitäten unnötig erzeugen, wenn wir bereits Fastlane für iOS-Versionen verwenden? Darüber hinaus ist es bequem auf unserem Server vorhanden, kocht in seinem eigenen Saft und wird im Allgemeinen aktualisiert. Zu diesem Zeitpunkt hatte er auch gelernt, wie man Android-Anwendungen angemessen veröffentlicht. Die Sterne kamen zusammen!
Das erste, was wir von überall gesehen haben, war alles, was alt war: separate Skripte, Automatisierungsskizzen, alte Wrapper für die API - dies wurde einmal als Experiment erstellt und war nicht sehr wertvoll. Unmittelbar danach haben wir AIDA ein Team hinzugefügt, das bereits wusste, wie man die benötigten Informationen von TeamCity abruft, die erforderlichen Informationen in HockeyApp hochlädt, Benachrichtigungen sendet, Aktivitäten protokolliert und im Allgemeinen Mitglied des Teams ist.
Fastlane übernahm das Ausfüllen von APK- und Mapping-Dateien bei Google Play. Ich muss sagen, dass es viel einfacher ist, dem ausgetretenen Pfad zu folgen: Es wurde schnell genug mit minimalem Aufwand implementiert.
Zu einem bestimmten Zeitpunkt in der Implementierung der Automatisierung gab es einen Übergang von APK-Archiven zu AAB (Android App Bundle). Wieder hatten wir das Glück, dass es sich bei der Verfolgung ziemlich schnell herausstellte, alles zu reparieren, aber im Zusammenhang mit diesem Übergang wurde „Unterhaltung“ hinzugefügt. Zum Beispiel verwöhnte er HockeyApp, das nicht wusste, wie man AAB-Archive im Zusammenhang mit der Vorbereitung auf das Selbstsägen verwendet. Um es weiterhin bequem verwenden zu können, war es nach dem Zusammenstellen des AAB erforderlich, das zusammengestellte Archiv zu zerlegen, die Zuordnungsdatei von dort abzurufen, die zur HockeyApp fliegt, und vom AAB die APK-Datei separat zusammenzustellen und erst dann in dieselbe HockeyApp hochzuladen. Klingt lustig. Gleichzeitig zerlegt Google Play selbst AAB perfekt, nimmt die Mapping-Datei heraus und fügt sie bei Bedarf ein. Also haben wir einen Schritt losgeworden und ein paar hinzugefügt, aber es gab kein Umgehen.
Es wurde eine Benutzeroberfläche geschrieben (ähnlich wie bei iOS), die es ermöglichte, eine neue Version herunterzuladen, die Version zu überprüfen und die aktuelle aktive Version zu verwalten (z. B. den Rollout-Prozentsatz zu erhöhen). In diesem Formular gaben wir es den Mitgliedern des Android QA-Teams, die für die Veröffentlichungen verantwortlich waren, und begannen, Feedback zu sammeln, Fehler zu beheben, die Logik zu verfeinern (und was passiert nach der Version 1.0 noch?).
Übrigens gab uns die Automatisierung in Zukunft die Möglichkeit, Beta-Versionen von Anwendungen automatisch nach einem Zeitplan auf Google Play hochzuladen, was wiederum den Prozess der automatischen Tests und Regressionstests erheblich beschleunigte.
Vereinheitlichung des Flusses mobiler Releases
Als die Android-Versionen automatisiert wurden, hatte Fastlane endlich gelernt, wie man Versionen von iOS-Apps zur Überprüfung einreicht. Und wir haben das Versionsprüfungssystem in AIDA leicht verbessert.
Es ist Zeit, iOS-Versionen einem Team von QS-Ingenieuren zur Verfügung zu stellen. Zu diesem Zweck haben wir uns entschlossen, ein schönes Formular zu zeichnen, das die Anforderungen, die während der Veröffentlichung von iOS-Anwendungen entstehen, vollständig abdeckt: Es würde es ermöglichen, den gewünschten Build in TeamCity anhand vordefinierter Parameter auszuwählen, die Option für heruntergeladene Texte auszuwählen, ob optionale Felder aktualisiert werden sollen oder nicht (z. B. Werbetext). ...
Gesagt, getan. Die Form erwies sich als sehr schön und erfüllt alle Anforderungen. Darüber hinaus wurde es mit seiner Implementierung möglich, sofort alle erforderlichen Anwendungen mit allen erforderlichen Parametern auszuwählen, so dass die Interaktion mit der Schnittstelle minimiert wurde. Auf Befehl sendet AIDA einen Link zum Build-Protokoll, über den Sie die auftretenden Fehler verfolgen, sicherstellen können, dass alles ordnungsgemäß funktioniert, Debug-Informationen wie die Version der heruntergeladenen IPA-Datei, die Release-Version usw. erhalten. So schön sind iOS-Releases. und wurden an das iOS QA-Team übertragen.
Nun, ist es süß?
Die Idee mit der Form hat uns so gut gefallen, dass wir uns entschlossen haben, dasselbe für Android-Versionen zu tun. Während wir eine App haben, die vollständig in React Native geschrieben ist und das QA-Team dieser App sowohl für iOS- als auch für Android-Versionen verantwortlich ist.
Die bereits vom Android QA-Team verwendete Oberfläche wurde mit Änderungen in eine ähnliche Form integriert, der Prozess wurde an neue Realitäten angepasst - alles war so nah wie möglich an den Prozessen des iOS-Teams. Dies gab einen Anreiz, endlich eine mehr oder weniger endgültige Version der Dokumentation für beide Plattformen zu skizzieren (im Zuge ständiger Änderungen wollten wir dies kategorisch nicht) und den Freigabeprozess von allen künstlichen Einschränkungen zu entkoppeln, die sich historisch entwickelt hatten und in nicht standardmäßigen Situationen zu unnötigen Gesten führten Aktionsteam von Release-Ingenieuren.
Ausgabe
Auf so unterhaltsame Weise haben wir ungefähr fünf Jahre lang (von dem Moment an, als wir mit der Entwicklung des Mobilfunkgeschäfts bis heute begonnen haben) die Montage-, Test- und Freigabeprozesse vollständig automatisiert, sie so effizient wie möglich gestaltet und die Verantwortung für Freigaben auf die QA-Teammitglieder übertragen, die dies akzeptieren Entscheidung über den Grad der Bewerbungsbereitschaft.
Zusätzlich zu den offensichtlichen Vorteilen haben wir verstreute Skripte von allen Arten von "geheimem Wissen", das an eine einzelne Person gebunden ist, vollständig beseitigt und eine neue Komponente in unser Ökosystem integriert, die von einem kleinen Team von Release-Ingenieuren unterstützt wird.
Es ist großartig, dass es jetzt möglich ist, die meisten Routinemaßnahmen zu automatisieren, dass Ingenieure Code schreiben können, wann immer sie wollen, und dass jeder Code von Drittentwicklern unterstützt werden kann, ohne wertvolle Zeit mit dem Durchsuchen komplexer Schnittstellen zu verschwenden. Es kann besonders schwierig sein, Momente wie „Wo soll ich ein Häkchen setzen?“ Zu verstehen. “Wenn die Uhr Mitternacht ist, ist niemand im Büro, und der Hotfix muss hier und jetzt ausgefüllt werden.
5 Jahre. Warum so lange? Erstens sind mobile Releases bei weitem nicht der einzige Verantwortungsbereich für unser kleines Team. Zweitens hat es natürlich einige Zeit gedauert, das neue Open-Source-Projekt Fastlane zu entwickeln. unser Release-System hat sich damit weiterentwickelt.
In diesem Bereich haben wir einen langen Weg zurückgelegt. Vielleicht ist es nicht das effektivste, vielleicht könnte ein Rechen vorausgesehen und umgangen werden. Aber es war so wie es war. Als wir anfingen, gab es keine ähnlichen Artikel - wir haben uns selbst hochgearbeitet. Und wenn Sie jetzt vor einer ähnlichen Aufgabe stehen und dieser Artikel Ihnen bei etwas helfen wird, werde ich unglaublich glücklich sein. Aber auch wenn Sie nicht grundlegend neue Informationen gelernt haben, hoffe ich, dass es zumindest interessant war, in Ihrer Freizeit zu lesen. Und vielleicht mit Ihrer Erfahrung vergleichen. Und wenn Sie etwas zu diesem Thema zu sagen haben, können Sie dies gerne kommentieren!