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 einen modernen, auf *Trunk basierenden Workflow*, bei dem Entwickler kleine, häufige Updates zu einem Hauptzweig (oder *Trunk*) zusammenführen, der über den CD-Teil der Pipeline erstellt und getestet wird. CI/CD Dieser Workflow hat den *Gitflow-Workflow* ersetzt, bei 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. Sieh dir die Unterschiede in den Git-Workflows an und erfahre dann, wie sich die Verwendung eines Legacy-Workflows auf Folgendes auswirken kann:
+ [Integrität der Umwelt](environment-integrity.md)
+ [Versionen](releases.md)
+ [Sicherheit](security.md)
Um es einfacher zu machen, die Überreste eines alten Git-Workflows in einer modernen Konfiguration zu identifizieren, vergleichen wir [Gitflow](#gitflow-approach) mit dem modernen, [Trunk-basierten](#trunk-based-approach) Ansatz.
## 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 future, 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\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/strategy-cicd-litmus/images/gitflow-workflow.png)
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 finden zwischen den einzelnen Umgebungen statt.
![\[Ein stammbasierter Workflow mit Funktionszweigen und einem Hauptzweig.\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/strategy-cicd-litmus/images/trunk-based-workflow.png)
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, die Ihre Codebasis automatisch in allen Umgebungen in Ihrer Pipeline testen und bereitstellen kann.
# Vorteile eines Trunk-basierten Ansatzes für die Integrität der Umgebung
Wie viele Entwickler wissen, kann eine Änderung im Code manchmal einen [Schmetterlingseffekt](https://www.americanscientist.org/article/understanding-the-butterfly-effect) erzeugen (Artikel von American Scientist), bei dem eine kleine Abweichung, die scheinbar nichts miteinander zu tun hat, eine Kettenreaktion auslöst, die zu unerwarteten Ergebnissen führt. Entwickler müssen dann alles untersuchen, um die Ursache zu finden.
Wenn Wissenschaftler ein Experiment durchführen, teilen sie die Testpersonen in zwei Gruppen ein: die Versuchsgruppe und die Kontrollgruppe. Die Absicht besteht darin, die Versuchsgruppe und die Kontrollgruppe bis auf das, was im Experiment getestet wird, völlig identisch zu machen. Wenn in der Versuchsgruppe etwas passiert, was in der Kontrollgruppe nicht passiert, kann die einzige Ursache das getestete Ding sein.
Stellen Sie sich die Änderungen in einer Bereitstellung als Versuchsgruppe vor und stellen Sie sich jede Umgebung als separate Kontrollgruppen vor. Die Ergebnisse von Tests in einer niedrigeren Umgebung sind nur dann zuverlässig, wenn die Kontrollen dieselben sind wie in einer oberen Umgebung. Je mehr die Umgebungen abweichen, desto größer ist die Wahrscheinlichkeit, dass Fehler in den oberen Umgebungen entdeckt werden. Mit anderen Worten, wenn die Codeänderungen in der Produktion fehlschlagen, wäre es uns viel lieber, wenn sie zuerst in der Betaversion fehlschlagen, damit sie nie in Produktion gehen. Aus diesem Grund sollten alle Anstrengungen unternommen werden, um jede Umgebung, von der niedrigsten Testumgebung bis hin zur Produktion selbst, synchron zu halten. Dies wird als *Umgebungsintegrität* bezeichnet.
Das Ziel jedes vollständigen CI/CD Prozesses besteht darin, Probleme so früh wie möglich zu entdecken. Durch die Wahrung der Umgebungsintegrität mithilfe eines Trunk-basierten Ansatzes können Hotfixes praktisch überflüssig werden. In einem Trunk-basierten Workflow kommt es selten vor, dass ein Problem zuerst in der Produktionsumgebung auftritt.
Bei einem Gitflow-Ansatz wird ein Hotfix, nachdem er direkt in höheren Umgebungen bereitgestellt wurde, dem Entwicklungszweig hinzugefügt. Dadurch bleibt das Update für future Versionen erhalten. Der Hotfix wurde jedoch direkt auf der Grundlage des aktuellen Status der Anwendung entwickelt und getestet. Selbst wenn der Hotfix in der Produktionsumgebung einwandfrei funktioniert, besteht die Möglichkeit, dass Probleme auftreten, wenn er mit den neueren Funktionen in der Entwicklungsabteilung interagiert. Da die Bereitstellung eines Hotfixes für einen Hotfix normalerweise nicht wünschenswert ist, bedeutet dies, dass Entwickler zusätzliche Zeit damit verbringen, den Hotfix in die Entwicklungsumgebung nachzurüsten. In vielen Fällen kann dies zu erheblichen technischen Schulden führen und die Gesamtstabilität der Entwicklungsumgebung beeinträchtigen.
Wenn in einer Umgebung ein Fehler auftritt, werden alle Änderungen rückgängig gemacht, sodass die Umgebung in ihren vorherigen Zustand zurückversetzt wird. Bei jeder Änderung an einer Codebasis sollte die Pipeline von der allerersten Phase an erneut gestartet werden. Wenn in der Produktionsumgebung ein Problem auftritt, sollte das Update auch die gesamte Pipeline durchlaufen. Die zusätzliche Zeit, die benötigt wird, um die niedrigeren Umgebungen zu durcharbeiten, ist im Vergleich zu den Problemen, die mit diesem Ansatz vermieden werden, in der Regel vernachlässigbar. Da der gesamte Zweck der unteren Umgebungen darin besteht, Fehler zu catch bevor sie in die Produktion gelangen, ist die Umgehung dieser Umgebungen durch einen Gitflow-Ansatz ein ineffizientes und unnötiges Risiko.
# Nutzen Sie die Vorteile eines Trunk-basierten Ansatzes
Ein Hotfix ist häufig erforderlich, weil in einem älteren Workflow der Status der Anwendung, an der die Entwickler arbeiten, möglicherweise mehrere unveröffentlichte Funktionen enthält, die noch nicht in der Produktion verfügbar sind. Die Produktionsumgebung und die Entwicklungsumgebung werden erst synchronisiert, wenn eine geplante Veröffentlichung veröffentlicht wird, und dann beginnen sie sofort wieder voneinander abzuweichen, bis die nächste geplante Version erscheint.
Das Erstellen von geplanten Veröffentlichungen ist innerhalb eines vollständigen CI/CD Prozesses möglich. Sie können die Freigabe von Code bis zur Produktion verzögern, indem Sie Feature-Flags verwenden. Ein vollständiger CI/CD Prozess ermöglicht jedoch mehr Flexibilität, da geplante Releases überflüssig werden. Schließlich ist *kontinuierlich* ein Schlüsselwort in CI/CD, und das deutet darauf hin, dass Änderungen veröffentlicht werden, sobald sie fertig sind. Vermeiden Sie die Beibehaltung einer separaten Release-Umgebung, die fast immer nicht mit den Testumgebungen auf niedrigerem Niveau synchron ist.
Wenn eine Pipeline nicht vollständig CI/CD ist, tritt die Divergenz zwischen den oberen und unteren Umgebungen normalerweise auf Zweigstellenebene auf. Entwickler arbeiten in einem Entwicklungszweig und verwalten einen separaten Release-Zweig, der nur aktualisiert wird, wenn es Zeit für eine geplante Veröffentlichung ist. Da der Release-Zweig und der Entwicklungszweig voneinander abweichen, können weitere Komplikationen auftreten.
Wenn Entwickler in der Entwicklungsabteilung arbeiten und sich an einen Anwendungsstatus gewöhnen, der dem in der Produktion weit voraus ist, müssen sie sich nicht nur an den Produktionsstatus anpassen, sondern müssen sich auch jedes Mal, wenn dort ein Problem auftritt, wieder an den Produktionsstatus anpassen. Der Stand der Entwicklungsabteilung könnte der Produktion um viele Funktionen voraus sein. Wenn Entwickler täglich in dieser Branche arbeiten, ist es schwierig, sich daran zu erinnern, was für die Produktion freigegeben ist und was nicht. Dies erhöht das Risiko, dass neue Fehler eingeführt werden, während andere Fehler behoben werden. Dieses Ergebnis ist ein scheinbar endloser Zyklus von Korrekturen, die die Zeitpläne verlängern und Feature-Releases um Wochen, Monate oder sogar Jahre verzögern.
# Sicherheitsvorteile eines Trunk-basierten Ansatzes
Ein vollständiger CI/CD Prozess bietet einen vollständig automatisierten Ansatz für die Bereitstellung mit einer zentralen Informationsquelle. Die Pipeline hat einen einzigen Zugangspunkt. Softwareupdates werden zu Beginn in die Pipeline aufgenommen und unverändert von einer Umgebung zur nächsten weitergeleitet. Wenn in einer Phase der Pipeline ein Problem entdeckt wird, müssen die Codeänderungen, mit denen das Problem behoben wird, denselben Prozess durchlaufen und mit der ersten Phase beginnen. Durch die Reduzierung der Eintrittspunkte in einer Pipeline werden auch die Möglichkeiten reduziert, wie Sicherheitslücken in die Pipeline eingebracht werden können.
Da der Eintrittspunkt zudem so weit wie möglich von der Produktionsumgebung entfernt ist, wird die Wahrscheinlichkeit, dass Sicherheitslücken in die Produktionsumgebung gelangen, drastisch reduziert. Wenn Sie einen manuellen Genehmigungsprozess in einer vollständigen CI/CD-Pipeline implementieren, können Sie immer noch entscheiden, ob Änderungen in die nächste Umgebung übertragen werden oder nicht. Der Entscheidungsträger ist nicht unbedingt dieselbe Person, die Änderungen vornimmt. Dadurch werden die Verantwortlichkeiten des Implementierers von Codeänderungen und des Genehmigers dieser Änderungen getrennt. Dadurch wird es auch für weniger technisch versierte Unternehmensleiter praktikabler, die Rolle des Genehmigers wahrzunehmen.
Und schließlich hilft Ihnen der zentrale Zugangspunkt dabei, den Schreibzugriff auf die Benutzeroberflächenkonsole (UI) der Produktionsumgebung auf einige oder gar keine Benutzer zu beschränken. Indem Sie die Anzahl der Benutzer reduzieren, die manuelle Änderungen an der Konsole vornehmen können, verringern Sie das Risiko von Sicherheitsereignissen. Die Möglichkeit, die Konsole in der Produktionsumgebung manuell zu verwalten, ist bei älteren Workflows weitaus wichtiger als bei einem CI/CD automatisierten Ansatz. Diese manuellen Änderungen sind schwieriger nachzuverfolgen, zu überprüfen und zu testen. Sie werden normalerweise durchgeführt, um Zeit zu sparen, aber auf lange Sicht führen sie zu einer erheblichen technischen Belastung des Projekts.
Sicherheitsprobleme auf Konsolen werden nicht unbedingt von böswilligen Akteuren verursacht. Viele der Probleme, die in der Konsole auftreten, sind unbeabsichtigt. Versehentliche Sicherheitslücken sind sehr häufig und haben zur Verbreitung des Zero-Trust-Sicherheitsmodells geführt. Dieses Modell geht teilweise davon aus, dass Sicherheitsunfälle weniger wahrscheinlich sind, wenn selbst interne Mitarbeiter so wenig Zugriff wie möglich haben, was auch als *Least-Privilege-Berechtigungen* bezeichnet wird. Wenn die Integrität der Produktionsumgebung gewahrt wird, indem alle Prozesse auf eine automatisierte Pipeline beschränkt werden, wird das Risiko von Sicherheitsproblemen im Zusammenhang mit der Konsole praktisch ausgeschlossen.