Was ist Release Management?
Das Release-Management deckt alle Phasen des Software-Releases ab, von der Entwicklung über das Testen bis zur Bereitstellung. Das Release-Management ist jedes Mal erforderlich, wenn ein neues Produkt angefordert wird oder sogar Änderungen an einem vorhandenen Produkt vorgenommen werden. In dieser Situation werden fünf grundlegende Schritte zum Release-Management ausgeführt:
- Release-Planung
- Build freigeben
- Akzeptieren von Benutzertests
- Vorbereitung vorbereiten
- Stellen Sie die Version bereit.
Release-Planung
Die Planungsphase ist in den meisten Fällen intensiv, da zu diesem Zeitpunkt unser gesamtes Release von Anfang bis Ende organisiert ist. Ein zuverlässiger Release-Plan hilft Ihnen dabei, auf dem richtigen Weg zu bleiben und sicherzustellen, dass Standards und Anforderungen ordnungsgemäß eingehalten werden.
Bei der Planung von Releases sind wir der Ansicht, dass Anwendungen, die von mehreren Teams entwickelt wurden, einen konsistenten Ansatz benötigen, der im Voraus veröffentlicht werden sollte. Hier kommt das Konzept der "Zugfreigabe" ins Spiel. Durch einen Zugfreigabeansatz können Teams Änderungen basierend auf Veröffentlichungen planen und an den Play Store senden.
Der allererste Schritt, noch bevor wir mit der Implementierung der Zugfreigabe beginnen, besteht darin, die Zeitintervalle für jede Etappe zu definieren. In unserem Fall beträgt die Entwicklungsphase zwei Wochen. Als Nächstes müssen Sie festlegen, wie viel Zeit Sie für Integrationstests und Bereitstellungsschritte aufwenden möchten. Unten sehen Sie unser Beispiel für den Abstand:
- Ausschnitt: beginnt Tag 1.
- Interne Tests von Alpha / UAT-Versionen: Drei Tage.
- Phasenweise Bereitstellung [1%] Einreichung zur Überprüfung.
- Überprüfungsdauer: 3 Tage.
- Ein Tag bei 20% der Nutzer.
- Ein Tag mit 50% der Benutzer am selben Tag, Wachstum auf 100% der Benutzer.
Basierend auf dem obigen Beispiel dauert es insgesamt 10 Tage, bis eine neue Version der Anwendung allgemein verfügbar ist.
Der nächste Schritt in Richtung Releases besteht darin, einen Workflow zu erstellen, auf den sich sowohl unsere Teams als auch die wichtigsten Stakeholder während des gesamten Releases beziehen können.
Der Workflow erklärt sofort, wie die gesamte Version funktioniert und welche Rolle jedes Teammitglied spielt. Wir verwenden das Asana-Tool, um diese Details wie folgt anzuzeigen:
- Zeitliche Koordinierung
- Voraussichtliche Lieferzeit
- Bedarf
- Gesamtumfang des Projekts
Nach der Entwicklung des Plans legen wir ihn allen Stakeholdern (Release-Gruppe, Produktmanager und hochrangigen Führungskräften) zur Prüfung vor. Wir erhalten dann ihr Feedback zu Lücken oder Problemen, die sie in den Anforderungen oder der Anwendung sehen.
Sobald der Plan genehmigt und abgeschlossen ist, beginnt der Spaß!
Wichtige Aspekte der Release-Planung
Das Erstellen und Verwenden einer Zugfreigabe klingt großartig, aber es kann schwierig sein, den Prozess während der Planung einer Zugfreigabe am Laufen zu halten. Hier sind einige Details dieses Prozesses:
- Der Release Manager verwaltet und koordiniert das Release.
- Wir akzeptieren nur geprüften und getesteten Code.
- Es gibt eine Implementierungsphase im Prozess.
- Wir überwachen die veröffentlichte Version der Anwendung.
Gebäude freigeben
Sobald der Release-Plan fertig ist, können Sie das Produkt auf Release testen. Dies ist der eigentliche "Test auf Benutzerebene" des Produkts basierend auf den im Release-Plan festgelegten Anforderungen.
An einem bestimmten Tag und zu einer bestimmten Uhrzeit (z. B. Montag um 15:00 Uhr) wird der Code eingefroren / abgeschnitten. Bis zu diesem Zeitpunkt haben die Teams Zeit, Funktionen zu prüfen, zu testen und in den Entwicklungszweig einzufügen, der Teil der Zugfreigabe sein sollte. Um 15:00 Uhr erstellt der Release-Manager einen Release-Zweig aus dem Entwicklungszweig. Dieser Schritt wird mit Jenkins automatisiert.
Durch die Automatisierung des Zweigübergangs überprüfen wir, ob alle Leistungsschwellen, Benchmarks und Automatisierungen von früheren Versionen auf den Markt als Vergleichsbasis auf die aktuelle gesetzt wurden und die Zugfreigabe für weitere Änderungen gesperrt ist.
Sobald der Code eingefroren ist, beginnt ein neuer Entwicklungszyklus, und alle teilnehmenden Teams beginnen einen neuen Sprint und setzen die Entwicklung fort. Das Tolle an einer Zugfreigabe ist, dass jeder über die nächste geplante Version Bescheid weiß und die Leute dabei unterstützt, ihre Arbeit entsprechend zu planen.
Zweigfreigabe und Versionskontrolle
Die Produktentwicklung hört normalerweise nicht auf, wenn die Entwicklung für eine Version abgeschlossen ist. Daher denken wir zunächst darüber nach, wie der zu testende Build eingefroren und gleichzeitig an neuen Funktionen für die nächste Version gearbeitet werden kann. Was passiert, wenn im Release-Build ein Fehler auftritt? Wie kann ich den Fehler beheben, wenn Sie bereits einige neue Dinge hinzugefügt haben, bevor dieser Fehler gefunden wurde?
Hier kommt die clevere Verzweigungsstrategie ins Spiel, die das Konzept der Verzweigung hat. Wie der Name schon sagt, bedeutet Verzweigungscode, dass der Code der Verzweigungen genau wie die Zweige eines Baums bis zu einem bestimmten Punkt übereinstimmt und dann in zwei Kopien aufgeteilt wird.
Jeder Zweig kann sich unabhängig vom anderen entwickeln. In diesem Fall bleibt eine Kopie - der Release-Zweig - dort eingefroren, wo Sie aufgehört haben. Dies ist, was wir einen abgeschnittenen Zweig nennen. Ein anderer Zweig (Entwicklungszweig) kann mit neuem Code und Fehlerkorrekturen geändert werden, ohne dass dies Auswirkungen auf den Release-Zweig hat. Wenn in einem Release-Kandidaten ein Fehler gefunden wird, kann ein Fix entwickelt und dem Release-Zweig hinzugefügt werden. Daher ist der nächste Build, den Sie erneut aus dem Release-Zweig erstellen, bis auf eine Fehlerbehebung möglicherweise mit dem ersten identisch. Auf diese Weise können Sie das Risiko neuer Fehler in der Version minimieren und Fehler von neuem Code isolieren. Ein Fix wird auch auf den Entwicklungszweig angewendet, um sicherzustellen, dass derselbe Fehler nicht in die nächste Version gelangt.Ein weiterer Vorteil der Release-Verzweigung besteht darin, dass Sie nach der Veröffentlichung Ihres Codes einen "eingefrorenen" Zweig haben, der eine exakte Kopie der veröffentlichten Codebasis ist. Sie können jederzeit als Referenz auf diesen Code zurückgreifen.
User Acceptance Testing
Das Testen der Benutzerakzeptanz ist aufgrund der Menge der gesammelten Daten und der erforderlichen Korrekturen der wichtigste Schritt für das Release-Management. Damit wird der Build genau so erstellt, wie er offiziell gestartet werden muss.
Wie der Name schon sagt, ist bei dieser Art von Tests die Kennzahl der Benutzer. Benutzer sind genau die Personen, die die Anwendung verwenden. Daher ist es unerlässlich, die Benutzer in die gesamte Qualitätssicherungsstrategie des Softwareentwicklungsprozesses einzubeziehen. Hier bietet sich UAT an. Diese Art des Testens stellt wie keine andere die Benutzeranforderungen in den Mittelpunkt der Produktentwicklung. Hier sind einige der Fragen, die solche Tests zu beantworten versuchen:
- Können Benutzer mit der App arbeiten?
- Verhält sich die Anwendung wie erwartet?
- Löst die App das Benutzerproblem?
Ohne effektives UAT (User Acceptance Testing) verringern sich die Erfolgschancen für das zu entwickelnde Projekt erheblich. Aus diesem Grund ist der Zoll ein so wichtiger Bestandteil des Lieferprozesses. Wie bereits erwähnt, ist UAT Teil eines iterativen Prozesses. Sobald Fehler erkannt werden, kommt das Team zurück, um sie zu beheben. Der Fehler wird im Release-Zweig behoben und dann wieder in den Entwicklungszweig übernommen. Der Build muss die UAT-Phase durchlaufen, damit er auf seine endgültige Implementierung und Freigabe überprüft werden kann.
Pro-Tipp: Beziehen Sie interne Tests immer in die UAT-Planung ein!
Eine Möglichkeit für uns, die UAT-Version zu beschleunigen, bestand darin, die von Google bereitgestellten internen Teststrecken zu verwenden. Auf diese Weise können wir Tickets schnell an Kollegen verteilen und deren Feedback erfassen, indem wir automatisch JIRA-Tickets generieren. Das Team stellt außerdem sicher, dass das Feedback berücksichtigt wird, bevor der endgültige Test eingereicht wird.
Vorbereitung und Freigabe
Dieser Schritt besteht darin, dem Produkt den letzten Schliff zu geben und dabei alles zu berücksichtigen, was in UAT verstanden wurde. Die Vorbereitung der Veröffentlichung umfasst auch eine abschließende Qualitätsprüfung durch das QC-Team. Während der Inspektion führt das QS-Team Endprüfungen durch, um sicherzustellen, dass die Baugruppe die Mindestabnahmestandards und Geschäftsanforderungen des Freigabeplans erfüllt.
Nach Abschluss der Überprüfung schließt die Release-Gruppe das Release ab, um mit der Bereitstellung zu beginnen. Bevor eine Baugruppe in einer Live-Umgebung bereitgestellt werden kann, muss sie von den zuständigen Teams wie dem Designteam genehmigt werden. UAT stellt sicher, dass das Ergebnis validiert wird, bevor es an die nächste Stufe übergeben wird.
Bereitstellen einer Version
Schließlich kam der große Tag, an dem sich die harte Arbeit unseres Teams gelohnt hat. Es ist Zeit, unser Produkt für die Produktion in die Natur zu bringen. Neben dem einfachen Senden der Baugruppe an die Produktionsumgebung enthält die Implementierungsphase auch Schulungen zum Umgang mit dem Produkt sowohl für den Endbenutzer als auch für das gesamte Unternehmen. Beispielsweise müssen Benutzer über Änderungen in einer Version informiert werden. Hier wird im Sichtfeld "Was ist neu" angezeigt. Wir haben einen automatisierten Jenkins-Prozess, der die folgenden Schritte enthält:
- Erstellung der Endmontage [Angabe des Zweigs und des Versionsnamens].
- "What's New" wurde in der Version hinzugefügt.
- Hinzufügen eines Bereitstellungsprozentsatzes.
- Jede Stufe verfügt über eine manuelle Eingabe von Signalen (rot / grün) von jedem der Befehle [UAT, Benchmark, Leistung, Automatisierung].
Sobald die Signale den Build zulassen, wird der Build automatisch mit einem definierten Bereitstellungsprozentsatz in den Play Store hochgeladen. Die internen Schritte zum Festschreiben und Kennzeichnen einer Version, Speichern von Assemblys in Dropbox, Veröffentlichen und Aktualisieren auf dem entsprechenden Slack-Kanal werden ebenfalls über dieselbe Pipeline ausgeführt.
In diesem Fall beginnen wir mit der Bereitstellung auf 1%. In jeder Phase müssen die Überprüfung sowie die Tools zur Überwachung von Release-Drops überwacht werden, um mögliche Probleme zu identifizieren.
Wenn der Fehler bei 1% erkennbar wird, hat das Team die Möglichkeit, auf das Problem zu reagieren und zu entscheiden, ob es schnell behoben werden soll. Wenn ja, sollte die Zugfreigabe nicht den nächsten Bereitstellungsschritt von 5% erreichen. Stattdessen ist das Problem für 1% der Benutzer gelöst. Sobald das Problem behoben und die Lösung überprüft wurde, kann die Zugfreigabe die 5% -Stufe erreichen.
Wie in der einfachen Version der Zugfreigabe kümmert sich nur der Freigabetechniker oder das Freigabeteam um den Freigabeprozess, nachdem der Code eingefroren wurde. Alle anderen Teams setzen ihre "normale" Entwicklung fort.
Analyse nach der Veröffentlichung
Die Release-Verwaltungsarbeit endet nicht mit der Veröffentlichung des Codes und wird fortgesetzt, bis Sie bereit sind, die Version erneut freizugeben. Wenn Sie möchten, dass Ihre Anwendung erfolgreich ist, muss sie überprüft werden. Außerdem müssen Sie die Version in der Produktion befolgen, um Fehler zu beheben, die von den Benutzern benötigten Funktionen zu implementieren und Benutzerprobleme zu lösen. Zu diesem Zweck verwenden wir Firebase Crashlytics, mit denen wir alle Abstürze verfolgen, die sofort behoben werden müssen.
Darüber hinaus bieten App-Bewertungen Einblicke in Ihr Produkt, die mit anderen Ansätzen viel schwieriger zu erreichen sind. Sowohl Google Play als auch der App Store bieten App-Entwicklern die Möglichkeit, auf Bewertungen zu antworten. Dies kann ein unglaublich nützliches Tool sein, um mehr über App-Probleme von Nutzern zu erfahren. Testimonials können Probleme identifizieren, die Benutzer mit Ihrer App haben, und über zukünftige Änderungen informieren.
Fassen wir zusammen
Das Release-Management überwacht einen äußerst dynamischen Prozess. Jede Version bietet die Möglichkeit, alles zu verfeinern, von unserem Workflow bis zu unserer Checkliste, während wir damit Verbesserungsmöglichkeiten entdecken. Hier sind einige der Vorteile, die wir haben:
- Steigerung unserer Produktivität durch Verbesserung der Kommunikation und Koordination.
- Unsere Releases werden schneller geliefert, was auch die Risiken reduziert. An diesen Änderungen ist ein Team beteiligt, das regelmäßig Qualitätsversionen mit hoher Geschwindigkeit bereitstellen kann.
- Das Release Management unterstützt auch die Systematisierung und Optimierung der Entwicklungs- und Betriebsmethode.
Wir haben auch festgestellt, dass unser Release-Management-Prozess es allen Mitarbeitern - von Entwicklern und Produktbesitzern bis hin zu Führungskräften - erleichtert hat, den übergeordneten Plan zu überprüfen und einen Überblick über ihre Fortschritte zu erhalten und synchron zu arbeiten.