Ist der GitHub Flow bei einem agilen Entwicklungsteam überhaupt noch notwendig?
GitHub Flow kurz erklärt
Wird eine neue Funktion in einem Softwareprojekt entwickelt, dann erstellt der Entwickler in der Regel einen "neuen Branch". Ist die Entwicklung der neuen Funktion abgeschlossen, wird ein "Pull Request" erstellt und zusammen mit dem Team besprochen. Mit Hilfe von automatischen Tests (siehe auch Unit-Tets - Was ist automatisches Testen?) wird sichergestellt, dass der neue bzw. angepasste Quellcode auch funktioniert. Anschließend kann der zuvor neu erstellte "Branch" in den "Master-Branch" übernommen werden.
Siehe hierzu auch "Following the GitHub flow":
Continuous Integration (CI) / Continuous Delivery (CD)
Mit Hilfe der CI/CD-Pipelines, welche in einem agilen Softwareprojekt zwingend erforderlich sind, welche den Prozess des fortlaufenden Zusammenfügens von Komponenten hin zu einer Anwendung garantieren, müssen Änderungen am Quellcode bzw. neue Funktionen nicht mehr bis zum nächsten großen Release gesammelt werden. Auch das "große" gemeinsame Testen und das "Live setzen" zu einem festgelegten Termin ist nicht mehr erforderlich. Siehe auch Softwaretest bei agiler Entwicklung durch Testautomatisierung .
Kleine Anpassungen sollten immer so schnell wie möglich getestet und abgenommen werden, damit diese sofort veröffentlicht werden können. Die sogenannten "Release Branches" sind damit hinfällig.
Wenn jede kleine neue Funktion oder Korrektur von Fehlern (Bugs) nach erfolgreicher Testautomatisierung und Abnahme durch den Fachbereich im Live System zur Verfügung steht, dann werden auch keine "Hotfixes" mehr benötigt (Hotfixes = Feature). Fehlerbehebungen müssen somit nicht in einer "veralteten Version" erfolgen (Forward Fixing und nicht Rolling Back).
Was bleibt zum Schluss übrig?
Die Entwickler arbeiten nur noch mit dem "Master-" und dem "Feature-Branch".
Keine Kommentare:
Kommentar veröffentlichen