Leitfaden: Software-Release-Management für kleine Teams

Formalisierung des Release-Management-Prozesses (falls vorhanden)

In einigen Teamkonfigurationen, insbesondere solchen, die in Start-ups zu finden sind, gibt es weder DevOps noch Infrastrukturingenieure, die bei der Veröffentlichung einer neuen Version des Produkts Unterstützung leisten könnten.

Darüber hinaus ist sich der CTO oder Leiter des Softwareentwicklungsteams in einem Startup im Gegensatz zu großen bürokratischen Unternehmen mit definierten formalen Prozessen oft nicht der Komplexität des Software-Release-Management-Prozesses bewusst; Einige Entwickler im Unternehmen sind sich möglicherweise der komplexen Details des Prozesses bewusst, aber nicht alle. Wenn dieses Wissen nicht gründlich dokumentiert wird, könnte dies meines Erachtens zu Verwirrung führen.

In diesem Artikel werde ich versuchen, einige Tipps zur Formalisierung des Veröffentlichungsprozesses zu geben, insbesondere aus der Sicht des Entwicklers.

Geben Sie die Software-Release-Checkliste ein

Sie kennen vielleicht die Idee einer Checkliste für einige Operationen, wie sie im Checklistenmanifest , einem Buch von Atul Gawande, beschrieben sind. Ich glaube, dass ein formaler Freigabeprozess (wie viele andere Aufgaben in der Welt der Softwareentwicklung) Entwicklern die Möglichkeit bietet, dieses Protokoll zu implementieren. Eine Checkliste für den Freigabeprozess sollte in einem gemeinsam genutzten Dokument aufbewahrt werden, vorzugsweise in Form eines kollaborativen Wikis oder einer Tabelle auf Google Drive.

Durch die gemeinsame Nutzung dieses wichtigen Dokuments mit dem Team und die Erteilung von Bearbeitungsrechten hat jedes Mitglied Zugriff auf den formal definierten Freigabeprozess. Dadurch können sie verstehen, wie der Prozess funktioniert. Darüber hinaus befähigt es das Team nach Diskussionen mit anderen Teammitgliedern, es von Zeit zu Zeit zu verbessern. Dies sollte Transparenz schaffen und es dem gesamten Team ermöglichen, in Echtzeit darauf zuzugreifen, was während der Veröffentlichung vor sich geht, welche Schritte von wem abgeschlossen wurden.

Durch Betrachten dieser Tabelle können die Beteiligten auf der Grundlage des Ergebnisses der Schritte zwischen „GO“ und „NO GO“ entscheiden. Wenn beispielsweise ein Belastungstest in einer Testumgebung schief geht, kann der Projektmanager je nach Ereignis entscheiden, die Produktionsfreigabe abzubrechen.

Vorgeschlagene Schritte zur Verwendung als Grundlage

In diesem Abschnitt schlage ich einige Schritte vor, die Sie verwenden können, um Ihre eigene Checkliste für Ihren Freigabeprozess zu erstellen. Einige dieser Schritte sind keineswegs obligatorisch . Jede App ist anders und jede Organisation arbeitet anders. Sie können sich also gerne anpassen und Änderungen vornehmen, die besser in Ihren Arbeitsablauf passen.

1. Erstellen Sie einen Release-Branch

Wahrscheinlich sind Sie mit dem Konzept des Git-Workflows oder mit der Idee von Release-Zweigen vertraut, ein Thema, das in einem früheren Blogbeitrag erläutert wurde.

Idealerweise sollten Sie mindestens drei Zweige haben:

• master : Dies sollte den aktuellen Stand dessen widerspiegeln, was sich in der Produktionsumgebung befindet. Jeder neue Commit auf dem Master sollte nur ein neues Release umfassen.
• development : Dieser Zweig sollte die fertiggestellten (und getesteten) kommenden Funktionen enthalten. Es ist üblich, für jedes Feature einen separaten Zweig zu erstellen und ihn dann zusammenzuführen, um es zu entwickeln, wenn das Feature fertig ist.
• release : Release -Zweige sind eine Sammlung von Commits, die bereit sind, an die Produktion gesendet zu werden, sowie einige zusätzliche kleinere Fehlerkorrekturen im Zusammenhang mit dem Release.

Beachten Sie, dass die Release -Zweige entfernt werden sollten, sobald die Veröffentlichung abgeschlossen ist, daher werden diese Zweige ständig erstellt und zerstört, im Gegensatz zu master oder developer , die immer gleich sind.

Um einen neuen Release -Zweig zu erstellen, geben Sie im Entwicklungszweig in Ihrem Git-Terminal Folgendes ein:

$ git checkout -b release/xyz

Es ist praktisch, eine Namenskonvention wie die oben definierte zu verwenden und xyz entsprechend Ihren Anforderungen durch die Versionsnummer major.minor.patch zu ersetzen (dies ist eine Richtlinie, die Sie in Ihrem Team definieren und sich daran halten sollten).

Es ist auch wichtig zu sagen, dass Sie, wenn Sie einige Fehlerkorrekturen in den Release-Zweig codieren, nicht vergessen sollten, sie zurück in den development -Zweig zu führen. Der Hauptzweck des Release-Zweigs besteht darin, einen Vorschau-Snapshot darüber zu erhalten, wie sich die App verhalten soll, nachdem sie in Produktion geht.

2. Bump-Version

Der nächste Schritt wäre, die Versionsnummer im Release- Zweig anzuheben (zu ändern oder zu erhöhen).

Sie sollten die AndroidManifest.xml / package.json / pom.xml / oder wo auch immer die App-Version in Ihrem Projekt gespeichert ist (YMMV) öffnen, die Versionsnummer aktualisieren und dann die Änderungen in den aktuellen Release -Zweig übernehmen.

Es ist aus zwei Gründen wichtig, die Versionsnummer zu aktualisieren.

Erstens können Sie die in jeder Version eingeführten Funktionen nachverfolgen und zuordnen, und zweitens wissen Sie, welche Version sie verwenden, falls sie eine Fehlerbehebung durchführen oder Sie um Unterstützung bitten müssen. Wenn Sie eine mobile App erstellen, wird die Versionsnummer, die Sie in diesem Schritt aktualisieren, normalerweise auf der Benutzerseite, im Abschnitt „ Info “ oder im Google Play- oder Apple App Store angezeigt. Dieser Schritt ist auch eine gute Gelegenheit, umgebungsabhängig zu aktualisieren -Konfigurationsdateien (obwohl ich vorschlagen würde, diese in einem separaten Repository aufzubewahren), wie z.

Schließlich wird empfohlen, dass Sie den Release- Zweig auf den Ursprungspfad verschieben, damit er für Ihre anderen Entwickler verfügbar ist:

$ git push -u origin release/xyz

3a. Release-Zweig mit Master zusammenführen und taggen

Nur der Master- Branch sollte für die Produktion bereitgestellt werden, daher müssen wir in diesem Schritt den Release -Branch mit master zusammenführen.

 $ git checkout master $ git merge --no-ff release/xyz $ git push

Das Flag --no-ff ist optional, seine Verwendung wird jedoch empfohlen, um die Erstellung eines neuen Commit-Objekts zu erzwingen, auch wenn die Zusammenführung mit der Fast-Forward-Technik abgeschlossen werden kann.

Als nächstes ist es an der Zeit, das Release im Master- Branch zu taggen:

$ git tag -a xyz -m 'description of new version, features or fixes included'

Tags sind nützlich, da Sie diesen bestimmten Punkt im Verlauf im Git-Repository beibehalten und später zurückkehren können, um einen separaten Zweig von einem bestimmten Tag neu zu erstellen.

3b. Verwenden Sie eine Pull-Anfrage, um den Release-Branch zusammenzuführen

Eine weitere häufig verwendete Alternative ist die Verwendung einer Pull-Anfrage , um den Release -Zweig mit master zusammenzuführen.

Dieser Ansatz hat zahlreiche Vorteile. Es wird ein neuer Raum für die Zusammenarbeit geschaffen, den das Team nutzen kann, um verschiedene Release-bezogene Themen zu diskutieren. Dieser Punkt ist ein guter Zeitpunkt, um ein zusätzliches Gate für die Integration eines Code-Review-Prozesses hinzuzufügen, während Sie mehr Augäpfel haben, um den eingeführten Code zu überwachen und mögliche Änderungen zu diskutieren.

Einige Tools, mit denen Sie Pull-Requests in Ihre Workflows implementieren können, sind GitHub, Bitbucket und GitLab (Merge Request, wie sie es bei letzterem nennen). Bei diesen Tools geben Sie die Git-Befehle nicht manuell ein, sondern verwenden eine Webschnittstelle, um den Quell-Branch ( Release ) und den Ziel-Branch ( Master ) festzulegen, und fügen dann einen oder mehrere Reviewer hinzu, die es alle tun werden in der Lage sein, Inline-Kommentare zu diesen neuen Änderungen zu schreiben, Verbesserungen vorzuschlagen und so weiter.

Nachdem alle Prüfer die Pull-Anforderung genehmigt haben, können Sie die Änderungen automatisch mit dem Master zusammenführen, indem Sie eine Schaltfläche auf der Benutzeroberfläche drücken.

4. Stellen Sie den Master in der Produktionsumgebung bereit

In dieser Phase empfiehlt es sich, einen Tester in Ihrem Team einen Rauchtest durchführen zu lassen (dies könnte auf einer separaten Checkliste definiert werden), bevor die App bereitgestellt wird. Ein guter Vorschlag ist, den Master- Branch in einer separaten Testumgebung bereitzustellen. Der Tester kann dann einige grundlegende Aktionen ausführen, um sicherzustellen, dass nach der Zusammenführung mit dem neuesten Build nichts schief gelaufen ist. Wie man einen Rauchtest durchführt, würde den Rahmen dieses Artikels sprengen, aber Sie können im Internet viel Material darüber finden. Das Ergebnis des Rauchtests kann in die Freigabe-Checkliste/Tabelle integriert werden, um alle Fehler zu dokumentieren.

An diesem Punkt sind Sie bereit, die Änderungen bereitzustellen und live zu schalten. Fahren Sie fort und stellen Sie den Master- Branch bereit. Dieser Schritt hängt von dem von Ihnen verwendeten Infrastruktur-Stack ab. Es kann eine Verbindung zu Ihrer Amazon EC2-Instance zum Hochladen Ihrer App oder ein Pushen auf eine Heroku-Fernbedienung oder eine Verbindung über ssh zu Ihrem VPS zum Kopieren der neuen Version oder einen anderen Prozess beinhalten.

Stellen Sie nach dem Hochladen der App sicher, dass sie erfolgreich bereitgestellt wurde und wie erwartet funktioniert.

5. Merge zurück in den Develop- and-Delete- Release -Branch

Jetzt, da die Veröffentlichung fast abgeschlossen ist, möchten Sie den Release -Zweig in den development -Zweig einführen, die Versionsnummer auf letzterem aktualisieren und alle vorgenommenen Fehlerkorrekturen in den Hauptentwicklungszweig übertragen:

 $ git checkout develop $ git merge release/xyz

Jetzt ist es an der Zeit, den Release- Zweig zu entfernen:

$ git branch -d release/xyz

6. Generierung von Änderungsprotokollen

Es sollte eine Datei im Stammverzeichnis Ihres Projekts namens CHANGELOG.md (oder ein Äquivalent) geben, in der Sie bei jeder neuen Version einen neuen Eintrag hinzufügen sollten, um alles zu dokumentieren, was darin enthalten ist, wie Fehlerbehebungen, neue Funktionen, Bekannte Probleme und andere relevante Informationen in Form von Versionshinweisen. Dies ist wirklich nützlich für Benutzer und Mitwirkende , um zu sehen, welche Änderungen zwischen den einzelnen Releases (oder Versionen) des Projekts vorgenommen wurden.

Der Changelog-Eintrag enthält das Datum, die Versionsnummer und einige Hinweise zur Veröffentlichung. Die Einträge sollten in umgekehrt chronologischer Reihenfolge erfolgen. Hier ist eine einfache Vorlage, die ich verwendet habe und die Sie an Ihr Projekt anpassen können:

 <app's name or component released> <version xyz> | <date> <developer's name in charge of release> | <developer's email> Features: * <ticket/issue number>: <ticket/issue summary> (<link to issue tracker>) * ... Bugs fixed: * <ticket/issue number>: <ticket/issue summary> (<link to issue tracker>) * ... Enhancements: * <ticket/issue number>: <ticket/issue summary> (<link to issue tracker>) * ... Optional: known issues plus other release notes.

Darüber hinaus kann dieser Schritt vollständig automatisiert werden, indem entweder ein einfaches Skript codiert wird, das das Git-Protokoll durchläuft und automatisch den Änderungsprotokolleintrag generiert, oder indem ein Tool verwendet wird, das dasselbe tut, wie z.

• Github Changelog Generator, von skywinder,
• ReadmeGen von fojuth
• github-Änderungen, von lalitkapoor

Denken Sie jedoch daran, dass der Grad der Automatisierung, den Sie erhalten, direkt proportional zur Strenge Ihres Commit-Nachrichtenformats ist. Ich glaube, es ist immer eine gute Praxis, sich mit dem Team auf ein bestimmtes Format für Commit-Nachrichten zu einigen. Indem Sie die Richtlinien zum Stil der Commit-Meldungen befolgen, sind sie einfacher zu analysieren und daher wahrscheinlicher, dass Sie in der Lage sein werden, die Generierung des Änderungsprotokolls zu automatisieren.

7. Kommunizieren Sie mit Stakeholdern

Hier würden Sie normalerweise einige der folgenden Schritte ausführen:

• Teilen Sie dem Team über ein internes Nachrichtentool (z. B. Slack) mit, dass eine neue Version fertiggestellt wurde. Ich empfehle die Erstellung eines neuen Kanals (z. B. #releases ) ausschließlich zum Zweck der Kommunikation von Release-bezogenen Ereignissen. Es ist einfach, Hooks in einem Slack-Kanal hinzuzufügen, um eine Nachricht zu posten, nachdem eine Aktion durchgeführt wurde.
• Alternativ können Sie eine E-Mail mit einem Link zum Änderungsprotokoll oder der angehängten Änderungsprotokolldatei an die Beteiligten senden.
• Schreiben Sie einen Blogpost (wenn Sie einen Blog für Ihre App oder Ihr Produkt haben) oder einen Tweet.

Je nach Art Ihrer Organisation können weitere Maßnahmen ergriffen werden. Wichtig ist, dass Sie nicht vergessen zu kommunizieren, dass eine neue Version Ihres Produkts verfügbar ist.

8. Den Issue Tracker pflegen

Nachdem eine Veröffentlichung ausgeführt wurde, müssen Sie wahrscheinlich den Status einiger Ihrer Tickets aktualisieren, um die Fehlerkorrekturen oder Funktionen zu verfolgen, die derzeit in Produktion sind. Im Allgemeinen beinhaltet dies das Ändern einiger Tags (für kleine Projekte verwende ich ein Release-Pending- Tag, das ich nach Abschluss der Veröffentlichung entferne).

Wenn Sie Meilensteine ​​für jede neue Version verwenden, müssen Sie wahrscheinlich ihren Status aktualisieren oder sie als abgeschlossen markieren. Mit einigen Issue-Trackern können Sie sogar die Veröffentlichung planen und an Sprints ausrichten, nachverfolgen, ob ein Fehler eine Veröffentlichung blockiert, und andere nützliche Informationen liefern.

Es hängt alles davon ab, wie Sie das Tool verwenden. Ich möchte lediglich darauf hinweisen, dass die Aktualisierung der Informationen im Issue Tracker in Ihrer Release-Checkliste enthalten sein sollte.

Über die Automatisierung des Freigabeprozesses

Dem Leser ist vielleicht aufgefallen, dass neben dem oben beschriebenen Changelog-Schritt auch viele der oben genannten Schritte automatisiert werden können.

Die Möglichkeit, einige Teile des Freigabeprozesses zu automatisieren, ist ein großer Gewinn und spart viel Zeit. Ich schlage vor, Skripte zu erstellen oder herauszufinden, wie einzelne Schritte automatisiert werden können, und dann auf ein Ziel der kontinuierlichen Bereitstellung hinzuarbeiten. Continuous Delivery kann Risiken reduzieren, Kosten senken und die Zeit reduzieren, die Entwickler für die Verwaltung der Version aufwenden müssen. Folglich können Sie häufiger Releases veröffentlichen und hinsichtlich der für die Entwicklung zugewiesenen Stunden produktiver sein.

Der heilige Gral von DevOps-Unternehmen ist es, eine neue Version per Knopfdruck (oder Ausführen eines Befehls) starten zu können, der den Freigabeprozess automatisch auslöst, oder noch besser, ein System, das eine neue Version Ihrer Software zu einem Zeitpunkt freigibt bezeichnete Zeit. Dies ist natürlich schwierig zu erreichen, da Sie auch einen Großteil des Testprozesses automatisieren müssen, aber es ist nicht unmöglich.

Umfassen von Best Practices

In diesem Abschnitt beschreibe ich ein paar empfohlene Vorgehensweisen, die ich als praktisch empfunden habe, entweder um den Veröffentlichungsprozess reibungsloser zu gestalten oder um Sicherheitsmaßnahmen zu ergreifen, falls etwas schief geht.

Finden Sie den geeignetsten Tag, um die Freigabe durchzuführen

Normalerweise veröffentliche ich Apps, an denen ich arbeite, donnerstags zwischen Mittag und Geschäftsschluss.

Wenn Sie von Montag bis Freitag arbeiten, ist es keine gute Idee, an einem Freitag zu starten. Wenn nach der Veröffentlichung etwas kaputt geht, haben Sie bis Montag keine Zeit, es zu reparieren (es sei denn, Sie möchten am Wochenende arbeiten). Aus diesem Grund ist es bequemer, Releases am Donnerstag durchzuführen, da Sie am Freitag Zeit haben, die neue Version nach der Bereitstellung zu überwachen, Probleme zu beheben oder ein Rollback durchzuführen.

Eine weitere wichtige Sache, die Sie erwähnen sollten, wenn Sie eine Webanwendung verwalten, ist die Zeitzone zu kennen, in der sich die Mehrheit Ihrer Benutzer befindet. Sie sollten die Veröffentlichung während einer Zeit mit geringem Datenverkehr planen, um den potenziellen Schaden zu minimieren, wenn etwas fehlschlägt. Manchmal kann dies schwierig sein, wenn Ihre Benutzerbasis über die ganze Welt verteilt ist, aber Sie sollten trotzdem etwas recherchieren und den besten Zeitpunkt festlegen.

Sichern Sie Ihre Datenbank vor einer neuen Version

Wenn Sie keine regelmäßigen Sicherungen Ihrer Datenbank geplant haben, empfehle ich Ihnen dringend, einen Schritt in Ihren Veröffentlichungsprozess aufzunehmen, um eine Sicherung durchzuführen, bevor Sie mit der Veröffentlichung beginnen.

Gestaffelte Rollouts

Haben Sie sich jemals gefragt, warum es Tage oder sogar Wochen dauert, bis ein Publisher auf Ihrem Telefon verfügbar ist, wenn ein Publisher ankündigt, dass er eine neue Funktion eingeführt hat? Das liegt daran, dass viele Unternehmen gestaffelte Rollouts verwenden.

Facebook macht das schon lange. Es testet ein neues Feature an fünf oder 10 Prozent seiner Benutzer und steigert es schrittweise, bis sie 100 Prozent der Benutzerbasis erreichen. Während der gestaffelten Einführungsphase müssen Sie sich das Benutzerfeedback und die Absturzberichte genau ansehen. Mit diesen Informationen können Sie dann die Veröffentlichung verschieben oder Fehler beheben, bevor sie alle Benutzer betreffen.

Es gibt ein nettes Tool in der Entwicklerkonsole von Android, das gestaffelte Rollouts für Ihre Android-Apps implementiert.

Kontinuierliche Integration

Kontinuierliche Integration ist aus vielen Gründen eine Praxis, die es wert ist, angenommen zu werden. Erstens ermöglicht es Ihnen, Fehler frühzeitig zu erkennen, was die Rate erfolgreicher Releases erhöht. Zweitens ist es der erste logische Schritt vor der Implementierung von Continuous Delivery und der vollständigen Automatisierung, wie zuvor beschrieben.

Martin Fowler ist ein großer Verfechter der kontinuierlichen Integration. Er beschreibt eine Vielzahl von Vorteilen, die Ihrem Freigabeprozess hinzugefügt werden können, wenn Sie diese Praxis anwenden. Dies ist ein großes Thema, und es gibt viele Bücher und Blogbeiträge darüber, und ich erwähne es hier, weil ich glaube, dass es Ihnen viel mehr Vertrauen in Ihren Betrieb geben wird. Unter den vielen Vorteilen der Verwendung von CI finden Sie: reduziertes Risiko, erhöhte Sichtbarkeit, um zu wissen, was funktioniert und was nicht, frühere Erkennung von Fehlern, häufigere Bereitstellungen und vieles mehr.

Der Ausgangspunkt für die Implementierung von CI ist die Einrichtung eines „Continuous Integration Server“; Einige nette Tools zum Ausprobieren sind: CruiseControl, Bamboo, Jenkins und Travis.

Exitlude: Es wird alles klappen

Aggressiv verteidigen wir alle die Rolle, die wir spielen Bedauerlicherweise kommen Zeiten, um dich auf deinen Weg zu schicken Wir haben alles gesehen, Freudenfeuer des Vertrauens, Sturzfluten von Schmerz alles klappt

Exitlude, Die Mörder

Abschließend würde ich sagen, dass es sehr wichtig ist, einen gut definierten Freigabeprozess für Ihre App zu haben, unabhängig von ihrer Komplexität, Benutzerbasis oder wie klein Ihre Organisation ist.

Wenn nicht, schlage ich vor, dass Sie anfangen, über einige grundlegende Schritte nachzudenken, diesen Leitfaden und andere ähnliche zu verwenden und mit Ihrem Team ein Brainstorming durchzuführen, um einen ersten Entwurf zu erstellen. Probieren Sie es bei Ihrer nächsten Version aus und iterieren Sie dann. Schließlich werden Sie am Ende Ihren eigenen Freigabeprozess aufbauen.

Denken Sie danach darüber nach, wie Sie Teile des Prozesses automatisieren können . Überlegen Sie sich Bereiche, die verbessert werden können. Erkunden Sie Möglichkeiten zur Reduzierung der Release-Zeit, indem Sie kleine Optimierungen einbauen. Automatisierung sollte Ihr ultimatives Ziel sein; Planen Sie das jedoch nicht von Anfang an, oder Sie werden scheitern, wenn Sie einen so großen Sprung versuchen. Wie bei jedem Prozess ist es besser, ihn schrittweise zu verbessern.

Haben Sie andere Tricks oder Richtlinien, die Sie zum Starten neuer Versionen Ihrer App verwenden? Wenn ja, lassen Sie es mich wissen. Ich komme nicht aus der DevOps-Welt, ich bin nur ein Entwickler, der zufällig ziemlich organisiert und strukturiert ist, aber im Vergleich zu vielen Veteranen bin ich in dieser Hinsicht noch ein Neuling, also zögern Sie nicht, mich zu kommentieren oder zu kontaktieren, wenn Sie haben etwas hinzuzufügen.