Vorteile eines Trunk-basierten Ansatzes für die Integrität der Umgebung - 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.

Vorteile eines Trunk-basierten Ansatzes für die Integrität der Umgebung

Wie viele Entwickler wissen, kann eine Änderung im Code manchmal zu einemSchmetterlingseffekt(Artikel von American Scientist), wo 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 ist, 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. Das heißtIntegrität der Umgebung.

Das Ziel eines 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 der Fix für zukünftige 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 niedrigeren Umgebungen darin besteht, Fehler zu erkennen, bevor sie in die Produktion gelangen, ist die Umgehung dieser Umgebungen durch einen Gitflow-Ansatz ein ineffizientes und unnötiges Risiko.