GitHub Actionsって、実際どうなの
現在、 CI/CD、DevOpsの実装手段としてGitHub Actionsが人気のようです。なぜ人気なのかはいまひとつ不明ですが、私が予想してみるに以下のようのものではないかと思います。
- Gitリポジトリと直結していて扱いやすい。
- ソースの扱いだけでなく、単体テストなども実行可能。
- 従量課金なので「もしかすると運用コストを抑えられるかも」という期待。
- 目新しいから興味本位。
最初の2つはGitLabも同じですね。しかし価格表を少し見ると、運用コストについては疑問が沸きます。ならば比較してみようというのがこの記事です。
類似品について
CI/CDに関する製品は、CircleCI、Jenkins、Bitbucket Pipelinesなどいろいろあります。しかしここでは専用の製品ではなく、クラウドで扱いが簡単なものについて取り上げます。ものによっては複数組み合わせて同様となります。
現在のクラウドでGitHub Actionsと同じように利用できるものは、私が簡単に思いつくだけでも以下のものがあります。
GitLab
2015年にリリースされたGitLab 8.0は、GitリポジトリとCI/CDを統合した元祖です。手順をyamlに書いてリポジトリに保存しておけば、その内容に従ってCI/CDを実行してくれる仕組みは、GitHub Actionsよりこちらが先。
ビルドだけでなく自動化されたテストなども実行できるのも同様です。
課金は時間による従量制ではなく、ユーザ数によって決まります。個人ユーザならFreeプランを選択すれば無料で使えるのがうれしいです。Freeプランでもストレージは10GBなのでまあ余裕があるかと思います。しかしコンピューティング時間は400分/月なのでちょっと少ないかも。ビルドだけならともかく、がっつり開発しているとテストまで実行するなら1人でも足りなくなりそうです。
GitHub Actions
手順をyamlに書いてGitHubリポジトリに保存しておけば、その内容に従ってワークフローを実行してくれる機能で、2019年にリリースされています。GitLabと同じですがyamlの文法は別物で、後発だけあってyamlの書き方はこちらのほうが洗練されている感じがします。
ワークフローの内容はビルドだけでなく自動化されたテストなども実行できますが、yamlで手続きを記述するのは慣れが必要に感じます。
課金の単位は分で、1分未満は切り上げられます。
ランナーの種類も選択可能。ubuntu-slimランナーのみ他より割安なのがうれしいです。
Azure Pipelines
GitHubが登場したのでMicrosoftつながりでAzureから。この記事のためにちょっと調べただけであまり知りませんので、紹介にとどめます。
Azure DevOpsに分類される製品の1つで、CI/CDパイプラインを構成します。
課金は時間による従量制ではなく、ジョブ数によって決まるようです。オープンソースプロジェクトや、単一ジョブに対して1,800分/月の無料枠があります（Microsoftホスティッドジョブ）。Microsoftの製品は条件によって課金体系が細かく分かれているので、把握することも、簡単な紹介となるこのような記事での表現も難しいです。
Azure Container Appsジョブ
Cloud Runジョブと同じく、汎用のジョブ実行インフラです。ビルド用ではありませんが、ビルド・デプロイの手順をコンテナ内に実装してCI/CDに流用も可能なはずです。
自動化されたテストを実行するためのインフラとしても利用できるはずです。
課金単位は秒、無料枠は月あたり 180,000vCPU秒 & 360,000GiB秒。
vCPU／メモリの組み合わせを比較的自由に選べます。
Cloud Build
Google Cloud中心で使っている場合にお世話になるのがこれ。Build Packがいい感じにビルドしてくれれば楽なのですが、思うようにならなかった場合はBuild Packの情報が少ないこともあり、試行錯誤で苦戦させられることもあります。
ビルド専門のプロダクトですので、テストなどは不可能。
課金単位は秒、無料枠は2500分/月。
Compute Engineと同様にVMインスタンスを選択できます。
Cloud Runジョブ
Google Cloudの汎用のジョブ実行インフラです。ビルド用に作られているわけではありません。しかしビルド・デプロイの手順をコンテナ内に実装して、GitHubなどからwebフックで起動すれば、CI/CDに流用も可能なはず。最初のコンテナのデプロイは手作業で。デプロイしただけではURIは割り当てられないので、そこはWorkflowsやCloud Runサービスと組み合わせれば解決できます。なお、試したことありません。
自動化されたテストを実行するためのインフラとしても利用できます。ログ表示や、手作業でビルド開始をGUIで楽にしたいなどのケースには、自力で対処することになります。
課金単位は秒、無料枠は月あたり 240,000vCPU秒 & 450,000GiB秒。
vCPU／メモリの組み合わせを比較的自由に選べます。
運用コスト比較
GitHub Actionsの代表的なランナーにあわせた条件で、1分あたりの運用コストを比較したのが以下の表です。$1=￥154換算、東京リージョン、2026/09/09時点での価格です。
比較対象は、ほぼ同条件で比較の可能な従量課金制のものだけ。定額など条件が異なるものは比較対象外とします。GitHub Actionsの ubuntu-slim ですが、これにあわせて5GiBのメモリを選択できないのでCloud Buildのみメモリ4GiBの e2-medium としています。
そしてGitHub Actionsの各ランナーを基準にした、その他の運用コストの倍率です。
運用コストを比較するとGitHub Actionsは決して安くありません。ubuntu-slimでなんとか他と競える程度でしょうか。しかし1コア、5GBメモリでは出来ることが限られています。それに他が秒単位での課金なのに対して、GitHub Actionsは1分単位の切り上げなので、走らせたジョブが多くなると無駄なコストが発生します。
意外とCloud Buildはちょっと高いですね。
最後に
GitHub Actionsに優位性があるとすれば、GitHubのサイトに実装されたGUIで簡単に再実行やログが確認できることくらいだと思います。Container AppsジョブやCloud Runジョブのような汎用のワークロード実行インフラでCI/CDを実装するなら、以下のような仕組みを作れば、GitHub Actionsと同等になりそうです。
- ジョブごとの実行ログの表示：
各ジョブ（ビルド・テストなど）をジョブIDで識別し、それによってログを絞り込んで表示。 - ジョブの再実行：
指定ジョブの実行パラメータを取得し、同じパラメータを設定して再実行を可能とするUI。ただし手動実行ならCloud Runジョブにはありますので、指定すべきパラメータがわかるようにしておけば何とかなるでしょう。
逆にCloud Runジョブ／Container Appsジョブの方が有利なのは、手動実行／再実行時に、並列実行するタスク数をパラメータとして指定できるマニュアルスケーリングでしょうか。ビルド・デプロイなど並列実行しないタスクでは意味がありませんが、テストの実行では一時的に実行時間を短くしたいなどの要望を満たせます。
