CircleCIからGitHub Actionsへ移行する

CircleCIからGitHub Actionsへの移行前の課題

1. コストの説明責任（予算の見通しが立てづらい）

• CircleCIはクレジット＋プラン＋seat等の要素が絡み、月々の着地が読みづらく、組織として「なぜ今この金額か」を説明しづらい状態でした。
• その結果、コスト最適化の効果検証（どの施策でどれだけ下がったか）もしづらく、改善の意思決定が重くなっていました。

2. AI/自動化に必要なデータ取得がUI依存になりやすい

• 実行結果・ログ・成果物をプログラムから取得して集計したり、AIに渡して分析する際に、外部CIのUI操作に依存しがちでした。
• 失敗の一次切り分けや改善提案を仕組み化しづらいのが課題でした。（CircleCIはCLIあるものの、GitHubネイティブならghコマンドで認証も一元化できました。）

どのような状態を目指していたか

• CI/CDツールをGitHub Actionsに一元化し、管理コストを削減
• コスト予測が容易な分単位課金への移行
• テスト分割・並列実行の仕組みを維持しつつ移行

• CircleCI

• GHA自体がghコマンドでアクセスでき、AIフレンドリー
• 時間×インスタンスタイプで明朗会計
• CircleCIで発生していたシート料金がない

改善したかった課題はどれくらい解決されたか

解決した

• コストの透明性
  • 分単位課金により、月次のCI/CD費用が明確に把握できるようになった
• シート料金の削減
  • GitHubリポジトリ利用に含まれるため、追加のシート料金が不要に
• 設定の一元管理
  • .github/workflows/内で完結し、別サービスの管理画面を確認する必要がなくなった

どのような成果が得られたか

• 運用負荷の軽減
  • GitHub内で完結するため、ツール間の連携設定やアカウント管理が不要に
• トラブルシューティングの容易さ
  • PRと同じ画面でCI結果を確認でき、コンテキストスイッチが減少

• テスト分割の仕組みの違い
  • CircleCIではparallelism: 16と--split-by=timingsで自動的にテスト分割・実行時間管理ができたが、GitHub Actionsでは全て自前実装が必要
  • split-testという外部ツールを導入
  • matrix strategyで並列数を全て列挙する必要あり
• 過去のテスト実行時間データの管理
  • CircleCIは自動で記録してくれるが、GitHub Actionsではdawidd6/action-download-artifactで別ワークフローからデータ取得する仕組みを構築
• ワークフローの重複実行問題
  • masterへのマージ時に push イベントと merge_group イベントの両方でワークフローがトリガーされ、RSpecとカバレッジレポート作成が2回実行されていた。merge_groupイベントのみでアップロードするよう変更し、重複を解消した。

ubuntu-24.04-arm-2coreを利用し、2コアマシンで2プロセス並列実行することでCPUを最大限活用し、ジョブ起動回数を半減（16→8）させることでセットアップ時間と課金時間の削減を目指します。