Was ist ein releasebasierter Workflow?
In dieser Einheit erfahren Sie, wie Sie mit GitHub einen releasebasierten Workflow erstellen.
Was ist ein releasebasierter Workflow?
Bei einem releasebasierten Workflow handelt es sich um eine Reihe von Mustern und Richtlinien zur Veröffentlichung von Software. Auch wenn dieses Ziel für ein Entwicklungsteam offensichtlich erscheint, so gibt es dabei doch verschiedene Aspekte zu berücksichtigen. In dieser Einheit werden drei verschiedene Komponenten des Releasezyklus erläutert: die Verwaltung des Projekts, die Auswahl der Branchstrategie und die Veröffentlichung für Kunden.
Planen der Arbeitsschritte mit den GitHub-Projektboards
Aus der Planungsperspektive führt die Fokussierung auf Releases zu einer Aufteilung der Probleme in unterschiedliche Iterationen, die zu einer neuen Version führen. Diese Iterationen werden oft als Sprints bezeichnet, die in ungefähr gleich lange Zeitspannen aufgeteilt werden, um inkrementelle Änderungen zu ermöglichen. In eine einzelne Iteration können auch ganze Releaseversionen gepackt werden, die dann eine Zeitspanne von mehreren Monaten umfassen kann. In GitHub werden Iterationen als Projekte verwaltet.
Ein Projekt wird hauptsächlich durch sein Board geprägt. Das Board ist eine Art Schaltzentrale für die Iteration und enthält alle Karten, die noch aufgelöst werden müssen. Eine Karte kann ein Problem, einen Pull Request oder eine generische Notiz darstellen.
Standardmäßig werden auf jeder Karte die Spalten Aufgaben, In Bearbeitung und Fertig angezeigt. Sie können diese Spalten den Anforderungen Ihres Teams entsprechend anpassen, weitere Spalten hinzufügen oder die Verschiebung der Karten und deren Eigenschaften automatisieren.
Weitere Informationen zur Verwaltung von Projektboards finden Sie hier.
Der Projektstatus der Karte ist im gesamten Repository integriert. Wenn Sie beispielsweise eine Karte von Aufgaben in In Bearbeitung ziehen, wird ihr Status geändert und gleichzeitig der visuelle Indikator neben dem Projekttitel aktualisiert. Der grüne Abschnitt des Balkens entspricht dem Anteil der als Fertig gekennzeichneten Karten, der violette Abschnitt dem Anteil der Karten In Bearbeitung. Die verbleibende Länge stellt den Anteil der Karten dar, mit deren Bearbeitung noch nicht begonnen wurde. Neben der Möglichkeit, Karten durch Ziehen auf dem Board zu aktualisieren, ist dies auch über die Hauptansicht möglich.
Wenn Sie ein Projektboard verwenden, können alle Projektbeteiligten den Status und Fortschritt eines Projekts schnell erkennen. Sie können auch Boards für einzelne Benutzer oder eine Sammlung von Repositorys im Besitz einer Organisation erstellen.
Weitere Informationen zur Nachverfolgung des Arbeitsfortschritts mithilfe von Projektboards finden Sie hier.
Nachverfolgen bestimmter Meilensteine
GitHub bietet Teams, oder auch Untergruppen von Teams, die Möglichkeit, Meilensteine nachzuverfolgen.
Meilensteine ähneln der Projektnachverfolgung insofern, als dass es dabei um den priorisierten Abschluss von Problemen und Pull Requests geht. Ein Unterschied besteht jedoch darin, dass der Schwerpunkt eines Projekts auf dem Fortschritt des Teams liegt, während sich ein Meilenstein auf das Produkt bezieht.
Weitere Informationen zur Nachverfolgung des Arbeitsfortschritts mithilfe von Meilensteinen finden Sie hier.
Auswählen einer Branchenstrategie
Arbeiten mehrere Entwickler gleichzeitig an einem Repository, ist eine detaillierte Branchenstrategie erforderlich. Wird bereits zu Beginn eines Projekts ein einheitliches Konzept festgelegt, kann bei zunehmender Teamgröße und wachsender Codebasis die Übersicht beibehalten und Ärger vermieden werden.
Der GitHub-Flow
GitHub bietet neben einer Plattform zur Zusammenarbeit bei der Softwareentwicklung einen vorgeschriebenen Workflow für eine optimale Nutzung der verschiedenen Funktionen. GitHub ist mit nahezu allen Softwareentwicklungsprozessen kompatibel. Doch wenn Ihr Team noch keinen festgelegten Prozess verwendet, empfehlen wir die Verwendung des GitHub-Flows.
Arbeiten mit langlebigen Branches
Bei einem langlebigen Branch handelt es sich um einen Git-Branch, der nicht gelöscht werden kann. Einige Teams verwenden anstelle von langlebigen Branches lieber kurzlebige Fehlerbehebungs- und Featurebranches. In diesen Fällen soll ausschließlich ein Pull Request erstellt werden, um die Änderungen anschließend mit main zusammenzuführen. Diese Vorgehensweise kann bei Projekten sinnvoll sein, die ohne die Pflege älterer Versionen auskommen, wie z. B. Erstanbieterwebanwendungen, die keine früheren Versionen unterstützen müssen.
In anderen Szenarios ist ein langlebiger Branch jedoch besser geeignet. Das gängigste Beispiel hierfür ist ein Produkt mit mehreren Versionen, die für einen längeren Zeitraum unterstützt werden müssen. Beim Ausführen dieser Art von Commits sollte das Repository eine Standardkonvention befolgen, wie beispielsweise release-v1.0, release-v2.0 usw. Diese Branches sollten in GitHub als geschützt markiert werden, um den Schreibzugriff darauf zu kontrollieren und ein versehentliches Löschen zu verhindern.
Dabei sollte main als Stammbranch beibehalten werden und Änderungen aus Releasebranches als Upstream zusammengeführt werden, sofern diese der geplanten Ausrichtung des Projekts entsprechen. Zu gegebener Zeit sollte release-v3.0 dann auf main basieren, damit bei Wartungsarbeiten an release-v2.0 keine Probleme im Repository auftreten.
Warten von langlebigen Branches
Angenommen, eine Fehlerbehebung wurde mit dem Branch release-v2.0 und anschließend als Upstream mit main zusammengeführt. Später wurde festgestellt, dass der Fehler auch schon in Branch release-v1.0 vorhanden war, was eine Rückportierung des Fixes für Kunden erforderlich machte, die diese Version weiterhin verwenden. Was ist die beste Möglichkeit, diesen Fix zu portieren?
Das Zusammenführen von Branch main mit release-v1.0 ist nicht möglich, da dann eine erhebliche Anzahl von Commits enthalten wäre, die für diese Version nicht konzipiert wurden. Aus demselben Grund ist auch ein Rebase von release-v1.0 auf den aktuellen main-Commit keine Option.
Eine Möglichkeit bestünde darin, die Fehlerbehebung manuell im Branch release-v1.0 neu zu implementieren, was jedoch einen großen Arbeitsaufwand bedeuten und Probleme bei der Skalierung mehrerer Versionen verursachen würde. Mit dem Befehl cherry-pick stellt Git hierfür jedoch eine automatisierte Lösung bereit.
Was ist der Git-Befehl „Cherry-Pick“?
Mit dem Befehl git cherry-pick können Sie bestimmte Commits eines Branches für einen anderen Branch übernehmen. Die ausgewählten Commits werden durchlaufen und als neue Commits für den Zielbranch übernommen. Bei Bedarf können Entwickler vor der Rückportierung alle Konflikte zusammenführen.
Weitere Informationen zum Git-Befehl „Cherry-Pick“ finden Sie hier.
Veröffentlichen für Kunden
Wenn eine Produktversion für die Veröffentlichung bereitsteht, vereinfacht GitHub den Prozess der Paketerstellung und der Benachrichtigung von Kunden.
Zum Erstellen einer Version müssen Sie nur das Formular ausfüllen:
- Geben Sie ein Git-Tag gemäß der semantischen Versionierung ein (z. B.
v1.0.2), das übernommen werden soll. GitHub verwaltet anschließend den Erstellungsprozess des von Ihnen angegebenen Git-Tags. - Geben Sie einen Namen für das Release ein. Dabei haben sich folgende Methoden bewährt:
- Verwenden Sie einen aussagekräftigen Namen.
- Geben Sie die Git-Version an.
- Verwenden einer kurzen Zusammenfassung der Änderungen im Vergleich zur vorherigen Version
- Verwenden Sie einen Codenamen oder zufälligen Ausdruck.
- Stellen Sie Anmerkungen zu dieser Version bereit. Diese Aufgabe können Sie auch mithilfe der Release Drafter-App automatisieren. Dabei werden die Änderungen seit der vorherigen Version analysiert und die entsprechenden Pull Request-Titel angegeben.
- Wenn Sie als Teil des Releases Dateien bereitstellen möchten, z. B. vorgefertigte Installationsprogramme, können Sie diese per Drag & Drop in das Formular einfügen. Sie müssen die Quelle nicht packen, da GitHub dies automatisch erledigt.
- Geben Sie an, ob die Version eine Vorabversion ist, indem Sie dieses Kontrollkästchen aktivieren. Durch diese Angabe können Kunden selbst entscheiden, ob sie eine Vorabversion installieren möchten.
Nach der Veröffentlichung eines Releases erhalten alle, die das Repository anzeigen, eine Benachrichtigung.
Weitere Informationen zu GitHub-Releases finden Sie hier.