Glaubst du, es ist richtig, das Bauen, Testen und Veröffentlichen des Images in einem Workflow zu kombinieren, sowie Schritte für das Deployment in verschiedene Umgebungen hinzuzufügen?

Das ist nicht immer optimal. Obwohl ein solcher Ansatz für kleine Projekte oder lokale Test-Builds bequem sein kann, hat die Zusammenführung aller Schritte in einen Workflow Nachteile:

• Weniger Flexibilität: Das Deployment in verschiedene Umgebungen (Entwicklung, Staging, Produktion) erfordert unterschiedliche Parameter und oft unterschiedliche Zugriffsrechte. Die Zusammenführung erschwert die Verwaltung dieser Unterschiede.
• Abhängigkeit von der Umgebung: Wenn das Deployment in eine Umgebung fehlschlägt, gilt die gesamte Build als fehlgeschlagen, auch wenn das Erstellen des Images und dessen Test erfolgreich waren.
• Schwierigkeit beim Rollback: Das Zurücksetzen des Deployments wird weniger trivial, da der gesamte Workflow zurückgesetzt werden muss.
• Längere Ausführungszeit: Der gesamte Pipeline dauert länger, was das Feedback für Entwickler verzögert.
• Geringere Skalierbarkeit: Mit wachsendem Projekt und zunehmender Anzahl an Deployment-Umgebungen wird dieser Workflow unübersichtlich und schwer zu verwalten.

Eine gängige und flexiblere Praxis ist die Aufteilung dieser Phasen:

1. Build & Test Pipeline: Verantwortlich für das Bauen des Codes, Testen, Erstellen des Images und Speichern im Artefakt-Repository (z.B. Docker Registry, Nexus). Dieser Workflow wird bei jedem Commit oder Pull Request gestartet.
2. Deployment Pipelines: Separate Workflows für das Deployment in jede Umgebung. Sie nehmen das bereits gebaute und getestete Image aus dem Artefakt-Repository und deployen es in die Zielumgebung. Diese Workflows können manuell, geplant oder automatisch nach erfolgreichem Abschluss der vorherigen Phase gestartet werden (z.B. erfolgreicher Deployment in staging).

Dies ermöglicht:

• Schnellere Rückmeldung zur Codequalität (Build & Test).
• Unabhängiges Deployment in verschiedene Umgebungen.
• Flexiblere Verwaltung der Deployment-Parameter für jede Umgebung.
• Vereinfachung des Rollback-Prozesses.

Ausnahmen können kleine Pet-Projekte oder monolithische Anwendungen mit einfachem Deployment-Prozess sein, bei denen die Kosten für die Aufteilung den Nutzen übersteigen. In den meisten Unternehmensumgebungen ist jedoch die Aufteilung des Workflows eine bewährte Praxis.