Verzweigungsstrategien für IaC - 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.

Verzweigungsstrategien für IaC

Die typische Git-Methodik verwendet einen primären Trunk-Basiszweig (z. B.main) für die Produktion, einen Entwicklungszweig und Feature-Branches. Viele Organisationen übernehmen sofort dasselbe Design für Infrastructure-as-Code (IaC). Die Git-Methodik ist jedoch nicht direkt mit gängigen Entwurfsmustern für Infrastrukturen kompatibel. Beachten Sie die folgenden Punkte:

  • Anwendungen haben mehrere Umgebungen.

    • Zu den Umgebungsbeispielen gehören Sandbox, Entwicklung, Staging und Produktion.

  • Umgebungen sind nicht eng miteinander verknüpft.

    • Die Produktion ist oft eng mit erfolgreichen Staging-Bereitstellungen verknüpft.

    • Produktion und Staging sind in der Regel vollständig von der Entwicklungsumgebung entkoppelt.

    • Die Entwicklung ist in der Regel vollständig von der Sandbox-Umgebung entkoppelt.

  • Jede Anwendung hat ihre eigenen Umgebungsstandards.

    • Viele Anwendungen verwenden keine Sandbox-Umgebung.

    • Einige Anwendungen benötigen keine Staging-Umgebung, sondern verwenden stattdessen eine blaue/grüne Bereitstellungsstrategie.

Stellen Sie sich ein Szenario vor, in dem ein Anwendungs-Repository drei Umgebungen bereitstellt, die eine Trunk-basierte Methodik verwenden. Die Entwicklungsumgebung ist an den develop Branch gebunden, das Staging an den staging Branch und die Produktion an den Branch. main Für diese Anwendung ist eine neue Funktion erforderlich, um ein Transit-Gateway in der Lösung zu verbinden, die von einem anderen Team und Repository verwaltet wird. Ein Entwickler schreibt den Infrastrukturcode in einen Feature-Branch und führt ihn, sobald er fertig ist, mit dem develop Branch zusammen. Alles scheint gut zu sein.

Es stellt sich jedoch eine Herausforderung. Ein anderer Entwickler hat eine separate User Story für ein separates Feature, schreibt sie in einen Feature-Branch und führt sie mit dem develop Branch zusammen. Das zweite Feature ist jetzt bereit für die Zusammenführung mit Staging und Produktion. Die ursprüngliche Transit-Gateway-Funktion ist jedoch aufgrund eines Risikokriteriums in der Organisation noch nicht bereit. Jetzt sind alle Funktionen nicht mehr in der Produktion verfügbar, und der Anwendungscode ist quasi eingefroren oder defekt.

In diesem Szenario sollten Sie die folgenden möglichen Lösungen in Betracht ziehen:

  • Die gängigste Lösung: Erhöhen Sie die Codewiederholung (reduzieren Sie DRY) an bestimmten Stellen der Codestruktur, indem Sie separate ./environments Ordner im Repository einrichten. Dadurch kann sich der Code der Umgebungen im selben Repository befinden, aber entkoppelt sein.

  • Richten Sie einen CI/CD-Prozess mit komplexer Variablenverwaltung ein.

  • Trennen Sie Umgebungen in separate Repositorys.

  • Seltenste Lösung: Verwenden Sie mehrere Stammzweige.