Wie sehr sich CI/CD-Prozesse unterscheiden - AWS Präskriptive Leitlinien

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Wie sehr sich CI/CD-Prozesse unterscheiden

CI/CD-Pipelines verwenden eine moderneStammbasierter Arbeitsablauf, bei dem Entwickler kleine, häufige Updates zu einem Hauptzweig zusammenführen (oderKofferraum), der über den CD-Teil der CI/CD-Pipeline erstellt und getestet wurde. Dieser Workflow hat den ersetztGitflow-Workflow, in dem Entwicklungs- und Release-Zweige durch einen Release-Zeitplan getrennt sind. In vielen Organisationen ist Gitflow immer noch eine beliebte Methode zur Versionskontrolle und -bereitstellung. Inzwischen gilt es jedoch als veraltet, und es kann schwierig sein, es in eine CI/CD-Pipeline zu integrieren.

Für viele Unternehmen war der Übergang von einem Gitflow-Workflow zu einem Trunk-basierten Workflow unvollständig. Das Ergebnis ist, dass sie irgendwo auf dem Weg stecken bleiben und nie vollständig auf CI/CD migrieren. Irgendwie klammern sich ihre Pipelines am Ende an bestimmte Überbleibsel des veralteten Workflows, die in einem Übergangszustand zwischen Vergangenheit und Gegenwart feststecken. Sehen Sie sich die Unterschiede in den Git-Workflows an und erfahren Sie dann, wie sich die Verwendung eines Legacy-Workflows auf Folgendes auswirken kann:

Um es einfacher zu machen, die Überreste eines alten Git-Workflows in einer modernen Konfiguration zu identifizieren, vergleichen wirGitflowzur Moderne,auf StammbasisAnsatz.

Gitflow-Ansatz

Das folgende Bild zeigt einen Gitflow-Workflow. Der Gitflow-Ansatz verwendet mehrere Branches, um mehrere verschiedene Versionen des Codes gleichzeitig zu verfolgen. Sie planen die Veröffentlichung von Updates für eine Anwendung für einen bestimmten Zeitpunkt in der Zukunft, während die Entwickler noch an der aktuellen Version des Codes arbeiten. Trunk-basierte Repositorys können Feature-Flags verwenden, um dies zu erreichen, aber sie sind standardmäßig in Gitflow integriert.

Ein Gitflow-Workflow mit Funktionen-, Entwicklungs-, Release- und Hotfix-Branches

Ein Ergebnis des Gitflow-Ansatzes ist, dass die Anwendungsumgebungen normalerweise nicht synchron sind. In einer Gitflow-Standardimplementierung spiegeln die Entwicklungsumgebungen den aktuellen Status des Codes wider, während die Vorproduktions- und Produktionsumgebungen auf dem Stand der Codebasis aus der neuesten Version stehen.

Dies verkompliziert die Situation, wenn ein Fehler in der Produktionsumgebung auftritt, da die Codebasis, in der die Entwickler arbeiten, nicht mit der Produktion zusammengeführt werden kann, ohne unveröffentlichte Funktionen offenzulegen. Gitflow geht mit dieser Situation um, indem es einen Hotfix verwendet. Aus dem Release-Zweig wird ein Hotfix-Branch erstellt und dann direkt in den oberen Umgebungen bereitgestellt. Der Hotfix-Zweig wird dann mit dem Entwicklungszweig zusammengeführt, um den Code auf dem neuesten Stand zu halten.

Trunk-basierter Ansatz

Die folgende Abbildung zeigt einen Trunk-basierten Workflow. In einem Trunk-basierten Workflow erstellen und testen Entwickler Features lokal in einem Feature-Branch und führen diese Änderungen dann im Hauptzweig zusammen. Der Hauptzweig wird dann sequentiell für die Entwicklungs-, Vorproduktions- und Produktionsumgebungen erstellt. Einheiten- und Integrationstests werden zwischen den einzelnen Umgebungen durchgeführt.

Ein stammbasierter Workflow mit Funktionszweigen und einem Hauptzweig.

Bei Verwendung dieses Workflows verwenden alle Umgebungen dieselbe Codebasis. Für die oberen Umgebungen ist kein Hotfix-Zweig erforderlich, da Sie Änderungen im Hauptzweig implementieren können, ohne unveröffentlichte Funktionen verfügbar zu machen. Es wird immer davon ausgegangen, dass der Hauptzweig stabil, fehlerfrei und bereit zur Veröffentlichung ist. Auf diese Weise können Sie ihn als Quelle für eine CI/CD-Pipeline integrieren, mit der Ihre Codebasis automatisch getestet und in allen Umgebungen in Ihrer Pipeline bereitgestellt werden kann.