Release-Management in QA / Sudo Null IT News

Das Release-Management umfasst alle Phasen eines Produkts – von der Entwicklung über das Testen bis hin zur Produktion. Das ist die verantwortungsvollste Rolle, die ein IT-Spezialist übernehmen kann. Gemeinsam mit Kollegen aus der QA-Leitung erläuterte SimbirSoft, worauf ein IT-Spezialist achten sollte, der als Release-Manager beginnt oder sich entscheidet, den Release-Prozess in einem Projekt zu analysieren.

Die Kompetenzen des Release Managers lassen sich hinsichtlich der Tools in zwei Teile gliedern: Technisches und Dokumentenmanagement.

Technischer Bereich

Dies ist die Zusammenstellung des Release-Zweigs, der Bereitstellung, der Konfiguration, der Aktualisierung von Servern und Datenbanken.

Darüber hinaus hängen Release-Ansätze sehr oft von der Architektur der Anwendung, der Größe der Projekte und dem gewählten GitFlow ab. Betrachten wir verschiedene technische Aspekte, die sich direkt auf die Release-Strategie auswirken.

Monolith vs. Microservices. Eine der Besonderheiten eines Monolithen ist, dass bei einem großen, langfristigen Projekt die Teams irgendwann stärker voneinander isoliert werden, was zu Fehlern führen kann. Einige Spezialisten haben etwas korrigiert, während andere etwas „heruntergefallen“ sind (unterschiedliche Versionen von Hilfslinien auf der Vorderseite führen beispielsweise zum Absturz von Widgets).

Die Aufteilung in Microservices löst das Problem teilweise. Aber während dieser Übergangszeit müssen Sie Releases so sorgfältig wie möglich veröffentlichen, in denen Funktionen nicht nur Ihren Dienst, sondern den Monolithen als Ganzes betreffen. Alle Änderungen im Code können sich in einem anderen Abschnitt widerspiegeln, der nicht geändert wurde. Daher lohnt es sich, bis zum Zeitpunkt einer vollständigen Änderung der Architektur beim Testen eines Releases besonders auf solche Änderungen zu achten.

CI/CD. Bei großen, komplexen Projekten gibt es ein einfaches Muster: Viele parallele Dienste nehmen viele Änderungen vor, um sie zu entwickeln. Damit Veröffentlichungen nicht zu „fett“ werden, ist es besser, ihre Frequenz zu erhöhen. Beispielsweise sind tägliche Berechnungen in dieser Situation eine gute Praxis. Möge CI/CD mit dir sein.

gitflow. Einige interessante Fakten über das Git-Branching-Modell.

Es kommt vor, dass Aufgabenstatus das Zusammenführen eines Zweigs nicht zulassen, wo sie sollten, und wo sie das Zusammenführen NICHT zulassen sollten, erlauben sie es.

Situation eins: Der Entwickler hat vergessen, den Status der Aufgabe im Task-Tracker zu ändern und hat sie nach dem Testen in den Entwicklungszweig gemergt – das sollte nicht passieren. Alle in Entwicklung befindlichen Probleme haben den Status „gelöst+“.

Situation zwei: Eine Aufgabe im Freigabezweig hat einen falschen Status (siehe erste Situation). Es lässt nicht zu, dass die Freigabe in den Master gemergt wird – der „Narrenschutz“ wird ausgelöst, damit ungetestete Aufgaben oder Aufgaben mit dem Status „in Überprüfung“ usw. nicht in den Master gelangen.

Außerdem gibt es manchmal Projekte, in denen GitFlow als seltsam bezeichnet werden kann. Zum Beispiel, wenn der Release-Zweig nicht von Develop, sondern von Master erstellt wird und Änderungen von Develop dorthin übertragen werden. Es stellt sich heraus, dass der Code zuerst destabilisiert und dann stabilisiert wird. Die Frage nach der Korrektheit solcher Arbeiten bleibt offen.

Zusammenfassend ist es für einen Release-Manager sehr wichtig, GitFlow zu kennen, zu verstehen und zu befolgen, um Hotfixes, Bugfixes und Releases zu vermeiden. Es ist elementar: Wenn beim Testen eines Releases ein dringender Hotfix auftaucht, kommt es beim Mergen im Master zu Änderungen im Branch, die nicht im Release-Branch sind, und beim Rollout des Releases auf denselben Master zu einem Revisionskonflikt wird passieren. Daher ist es wichtig, den Code auf dem neuesten Stand zu halten und daran zu denken, Änderungen aus dem Hotfix nicht nur in die Entwicklung, sondern auch in den Release-Zweig zu pushen.

Dokumentation und Planung

Freigabevorschriften. Dies ist zunächst eine detaillierte Beschreibung, wie das Deployment auf dem Server des Kunden erfolgen soll, wann die Veröffentlichung erfolgt, was nach der Veröffentlichung überprüft werden muss, welche Pakete manuell hinzugefügt werden müssen und andere technische Feinheiten. Es ist sehr wichtig, die Verordnung auf dem neuesten Stand zu halten und alle interessierten Parteien über Änderungen zu informieren. Es ist gut, wenn Sie nach jedem Release mit einem DevOps-Ingenieur oder -Entwickler kommunizieren, um sich über alle Details und Änderungen im Klaren zu sein. Es sei daran erinnert, dass der aktuelle Veröffentlichungsplan eine echte Rettung sein sollte, um das Bus-Faktor-Risiko zu reduzieren. Vergessen Sie nicht, dort auch Post-Release-Aktivitäten hinzuzufügen – eine Beschreibung der Regeln für das Testen in der Produktion, Aktionen während Rollbacks, Regeln für die Arbeit mit Hotfixes.

Veröffentlichungshinweis. Ausführliche Versionshinweise (Versionshinweise) helfen Ihnen, schnell durch verschiedene Versionen des Produkts zu navigieren und zu verstehen, was wir den Benutzern bieten. Eine kompetente Versionierung ermöglicht es Ihnen, das Volumen des bevorstehenden Updates abzuschätzen. Es ist sehr wichtig, durch die Versionen zu navigieren, wenn Benutzer längere Zeit nicht aktualisieren oder wenn sie dringend auf die vorherige Version zurücksetzen müssen. Die korrekte Versionierung mit Versionshinweisen ist ein großartiges Werkzeug, um zu untersuchen, aus welcher Version ein Fehler in die Produktion gelangt ist.

Buchungsplanung und Terminierung. Wenn es heute eine Veröffentlichung gibt, aber ein paar weitere Hotfixes erschienen sind, dann sollten Sie besonders auf deren Priorität achten. Kritische und blockierende Aufgaben werden zuerst eingeführt, aber es ist besser, nachdem die Veröffentlichung veröffentlicht wurde. Um Zeit zu haben, alle notwendigen Änderungen für den Verkauf auszurollen, sollten Sie die Bereitstellungsreihenfolge planen, aber das ist eine andere Geschichte, denn jedes Projekt hat seine eigenen.

Es gibt nichts Besseres als einen Zeitplan! Erstens wissen Teams, wann sie eine Version haben, und können Feature-Rollouts planen. Zweitens ist es einfacher, die Implementierung großer Aufgaben zu planen, die den Großteil der Funktionalität betreffen und mit anderen Teams interagieren. Alles ist sehr einfach.

Ein Tag im Leben eines Release Managers

Die Freigabe kann mit einer Lokomotive verglichen werden, die um jeden Preis rast. Seine Verwaltung erfordert Geschick und viele technische und Managementfähigkeiten. Es ist jedoch auch in Etappen unterteilt, an denen das gesamte Team teilnimmt. Um die Rolle des Release-Managers besser zu verstehen, werfen wir einen Blick auf den gesamten Lebenszyklus eines Releases.

1. Wir sammeln eine Liste von Aufgaben, die in der Freigabe enthalten sein sollten. Hier kann es mehrere Ansätze geben:

  • Wir starten eine Freigabeaufgabe im Aufgabentracker, suchen darin nach Aufgaben, die das Attribut „Freigabenummer: {Version}“ haben und fügen diese als Liste der allgemeinen Freigabeaufgabe hinzu.

  • Wir starten eine Aufgabe im Aufgabentracker und Produktteambesitzer hinterlassen Kommentare mit Aufgaben, die in die Version aufgenommen werden sollten. Außerdem werden alle notwendigen zusätzlichen Informationen in den Kommentaren hinterlassen, zum Beispiel: Sie müssen bestimmte Aktionen im Admin-Bereich ausführen, Konfigurationen hinzufügen, Vorlagen aktualisieren usw.

2. Erstellen Sie einen Release-Branch und führen Sie alle Release-Tasks darin zusammen.

3. Wir sammeln einen Freigabekandidaten für die Regression.

4. Ändern Sie den Status aller Aufgaben, die im Release Candidate enthalten sind.

5. Während der Regression überwachen wir Release-Blocker (Bugs mit hoher Kritikalität, Abstürze). Jeder Fehler muss einen Verantwortlichen haben, und wenn es keinen gibt, dann weisen wir ihn zu, denn bis der Fehler behoben ist, wird es kein Release geben.

6. Bei der Behebung von Regressionsfehlern sammeln wir bei Bedarf neue Release-Kandidaten, aktualisieren die allgemeine Aufgabe, ergänzen sie mit einer Liste von Fehlern, die in den nächsten Release-Kandidaten eingetreten sind, und ändern den Status von Aufgaben.

7. Beim Erstellen von Release-Kandidaten stellen wir sicher, dass nur Fehlerbehebungen hochgeladen werden, die während der Regression gefunden wurden. Zu diesem Zeitpunkt werden keine neuen Funktionen hinzugefügt, auch wenn Sie dies wirklich möchten. Da ein Teil der Funktionalität bereits getestet wurde, ein neues Feature sehr viel beeinflussen kann und Sie wieder regressieren müssen, besteht die Gefahr, dass Sie die Frist nicht einhalten. Es kann Ausnahmen geben – nach Vereinbarung und unter der Verantwortung des Teams.

8. Wenn der letzte Veröffentlichungskandidat das QA-Team zufriedenstellt und es keine Fehler gibt, die die Veröffentlichung blockieren, wird ein Veröffentlichungs-Build erstellt (wie beim letzten Veröffentlichungskandidaten).

9. Wir schreiben Versionshinweise vor, laden die Baugruppe in den Anwendungsspeicher hoch (für Mobiltelefone). Bei Mobiltelefonen kann es Feinheiten geben, beispielsweise ein reibungsloser Rollout der Version für die Benutzer.

10. Wir informieren QA, die Zugang zum „Kampf“ haben, um die Baugruppe aus dem App Store (Mobiltelefone) herunterzuladen, oder gehen zum „Kampf“-Stand und führen die erforderlichen Kontrollen durch.

11. Wir schließen alle Aufgaben, die in der neuen Version angehalten wurden.

12. Wir führen den Release-Zweig in den Master-Zweig ein, der Master in den Entwicklungszweig. Fügen Sie im Assistenten ein Tag mit der Versionsnummer hinzu.

13. Innerhalb weniger Tage nach der Veröffentlichung überwachen wir Abstürze. Darüber hinaus entscheiden wir in Absprache mit dem Teamleiter, ob ein Hotfix erforderlich ist.

Wichtig

Der gesamte Prozess muss dokumentiert werden, alle Feinheiten detailliert beschreiben. Das Projektteam sollte sich mit dem geplanten Release-Zeitplan vertraut machen und Aufgaben entsprechend vorbereiten.

Der Release-Manager sollte in jeder Phase die Fristen einhalten, die nicht verletzt werden sollten. Bei Verzögerungen analysiert und identifiziert er die Gründe für die Verzögerung, wodurch der nächste Sprint dies in jeder Phase vermeiden kann.

Ein guter Release-Manager denkt immer an die Benutzer: wie sie die neue Version wahrnehmen, wie sie verstehen, dass sie neue Funktionen enthält, welche Daten der Benutzer beim Öffnen einer neuen Seite sieht, ob Testdaten auf den Server gelangen. All dies sollte unter Einbeziehung des QA-Teams überprüft werden. Denn wer sonst, wenn nicht wir? 🙂

Fazit

Die Rolle des Release Managers erfordert einen ziemlich starken technischen Hintergrund in Bezug auf Toolkenntnisse, hängt aber auch stark von der Ausbildung des Managements ab. Wenn das Team keine dedizierte Rolle hat, wird die Verantwortung für die Freigabe auf die Teammitglieder verteilt. Aber der Hauptcontroller wird oft zum QA-Spezialisten – genau das passiert in SimbirSoft. Wir glauben, dass es besser ist, diese Rolle zu formalisieren, einen dedizierten Raum für die Speicherung der Release-Dokumentation und Debugging-Release-Prozesse bereitzustellen, dann werden erfolgreiche Bereitstellungen rechtzeitig sowie positives Kundenfeedback zu neuen Versionen nicht lange auf sich warten lassen.

Vielen Dank für Ihre Aufmerksamkeit! Wir veröffentlichen auch nützliche Materialien für QA-Spezialisten in unseren sozialen Netzwerken – VK und Telegramm.

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *