『GitHub Actions 集約』が現代の主流
GitHub に統合された GitHub Actions への CI/CD 集約が一般化しています。本記事では編集部の視点で、他ツールからの移行を公開情報をもとに整理します。GitHub Actions 応用 もご参考に。
移行の主な動機
(1) GitHub 統合：PR と一体運用。(2) 無料枠：公開リポは無制限。(3) マーケットプレイス：Action 豊富。(4) 運用簡素化。(5) セルフホスト Runner対応。
CircleCI からの移行
(1) config.yml → workflow.yml。(2) orbs → actions。(3) workspace → artifacts。(4) 並列ジョブ → matrix。(5) 移行ツールあり(公開情報をもとに)。
Jenkins からの移行
(1) Jenkinsfile → workflow。(2) shared libraries → reusable workflows。(3) plugin → action。(4) credentials → secrets。(5) 段階的移行が現実的。CI/CD 実践 もご参考に。
GitLab CI からの移行
(1) .gitlab-ci.yml → workflow.yml。(2) stages → jobs。(3) cache → actions/cache。(4) variables → env。(5) 構文の違いに注意。
共通の移行ステップ
(1) 現状の workflow 分析。(2) 並行運用：両方同時稼働。(3) 1ジョブずつ移行。(4) テスト：本番影響なし確認。(5) 監視と切替。
料金比較
(1) GitHub Actions：Linux Free 2000分/月(公開情報をもとに)。(2) CircleCI：Free 6000クレジット/月。(3) GitLab CI：400分/月。(4) Self-hosted Runner：実質無料。(5) 規模で大幅変動。FinOps 実践 もご参考に。
移行の落とし穴
(1) 長時間ジョブ：6時間上限。(2) マシン性能差：CPU/Memory。(3) キャッシュ仕様。(4) secrets 移行。(5) 権限設計。Secrets 管理 もご参考に。
失敗しがちなパターン
(1) 一気移行：失敗時の影響大。(2) 並行運用なし。(3) セルフホスト Runner未活用：コスト増。(4) テストカバレッジ低下。(5) 監視欠如。対策は、(1)段階的、(2)並行運用、(3)Self-hosted、(4)move-only、(5)CI 時間モニタ、です。