Wie lässt sich die Deployment-Zeit mit GitHub Actions verkürzen?

Wie lässt sich die Deployment-Zeit mit GitHub Actions verkürzen?

Dieser Artikel beschreibt verschiedene Ansätze, mit denen die Deployment-Zeit mithilfe von GitHub Actions verkürzt wurde, sowie die Erfahrungen bei der Lösung der dabei aufgetretenen Probleme.

• Mit der Zeit wurden die Deployment-Zeiten immer länger, was sich negativ auf Entwicklungsgeschwindigkeit und Teamproduktivität auswirkte
• Der Artikel erklärt, wie zur Lösung des Problems verschiedene Verbesserungen umgesetzt wurden, etwa die Umstellung des Deployment-Prozesses auf Parallelverarbeitung und die Einführung selektiver Build-Trigger

Problemsituation

• Die Deployment-Zeit mit GitHub Actions wurde schrittweise länger und erreichte im Durchschnitt 27 Minuten
• Dies begann, die Entwicklungsproduktivität zu beeinträchtigen
• Frontend, Intro und Backend wurden nacheinander gebaut und deployt; mit der Zeit wurde diese Vorgehensweise ineffizienter und verlängerte die Deployment-Zeit

Wichtige Verbesserungen

• Einführung von Parallelverarbeitung
  • Die bisher seriell ausgeführten Deployment-Jobs für Frontend und Backend wurden in parallele Abläufe aufgeteilt, wodurch sich die Deployment-Zeit von 27 auf 18 Minuten verkürzte.
  • In diesem Prozess wurde auch der GitHub-Workflow-Code modularisiert
• Einführung selektiver Build-Trigger
  • Es wurde path-filter verwendet, um nur geänderte Teile zu bauen, dabei zeigte sich jedoch ein problematisches Szenario bei Rollbacks
  • Statt des path-filter-Ansatzes wurden Workflow-Optionen bereitgestellt, mit denen Entwickler das Deployment-Ziel auswählen können
• Strategie zur Verwendung von Docker-Image-Tags
  • Durch die Wiederverwendung von Docker-Images wurde die Deployment-Zeit von 18 auf 15 Minuten verkürzt.
• Parallele Verarbeitung beim Deploy
  • Auch die Deploy-Phase wurde so aufgeteilt, dass Parallelverarbeitung möglich ist, was die Deployment-Zeit weiter verkürzte
• Ausgliederung des Intro-Bereichs
  • Der Build der Intro-Seite wurde im Frontend vom Service-Build getrennt, um die Deployment-Effizienz zu maximieren.

Ergebnis

• 55 % kürzere Deployment-Zeit (27 Minuten -> 12 Minuten)
• Zeitersparnis von bis zu 70 % möglich, geringere Infrastrukturkosten und höhere Produktentwicklungsproduktivität.
• Zusätzliche Vorteile
  • Durch die Modularisierung der Workflows wurden Wiederverwendbarkeit und Wartbarkeit verbessert
  • Kürzere Problemlösungszeiten und höhere Systemstabilität