GitHub Actionsのデプロイ時間、短縮してみる？

GitHub Actionsのデプロイ時間、短縮してみる？

GitHub Actionsを活用したデプロイ時間を短縮するために試したさまざまな方法と、その過程で直面した問題を解決した経験をまとめた記事です。

• デプロイ時間が徐々に長くなり、開発速度とチームの生産性に悪影響を与える問題が発生
• 問題を解決するため、デプロイプロセスを並列処理に切り替え、選択的ビルドトリガーを導入するなど、さまざまな改善をどのように進めたかを説明した記事です

問題の状況

• GitHub Actionsを使ったデプロイ時間が徐々に長くなり、平均デプロイ時間が27分に到達
• 開発生産性に影響し始めた
• Frontend、Intro、Backendを順次ビルド・デプロイする方式で、時間の経過とともに非効率なデプロイ方式となり、デプロイ時間が増加

主な改善点

• 並列処理の導入
  • 直列でデプロイしていたFrontendとBackendのデプロイ作業を並列に分離し、デプロイ時間を27分から18分に短縮。
  • この過程でGitHub Workflowコードのモジュール化も実施
• 選択的ビルドトリガーの導入
  • 変更された部分だけをビルドするためにpath-filterを使ったが、ロールバック時に問題となるケースを発見
  • path-filter方式は使わず、開発者がデプロイ対象を選択できるようWorkflowオプションとして提供
• Docker Image Tagの使用戦略
  • Docker Imageの再利用により、デプロイ時間を18分から15分に短縮。
• Deployの並列処理
  • Deploy段階でも並列処理ができるよう分離し、デプロイ時間をさらに短縮
• Introの分離
  • フロントエンドからIntroページのビルドをサービスビルドと分離し、デプロイ効率を最大化。

結果

• デプロイ時間を55%削減（27分 -> 12分）
• 最大70%の時間短縮が可能になり、インフラコスト削減、プロダクト開発生産性を向上。
• 追加の利点
  • Workflowのモジュール化により、再利用性と保守性が向上
  • 問題解決時間の短縮、システム安定性の向上