今まで仕事や勉強で様々な CI サービスをさわってきたので、様々な CI サービスを比較し、どのように選定すべきか、どのように学習すべきかをまとめました。
※ この記事は 2020/10/6 時点の情報なのでご注意ください
CI サービスの分類
CI サービスといっても色々な種類があります。
この記事では独自に 5 つに分類しました。
-
SaaS - CI 専用サービス系
- 例) CircleCI, Travis CI
-
SaaS - Git サービス系
- 例) GitLab CI, GitHub Actions
-
SaaS - パブリッククラウド系
- 例) AWS CodeBuild, Google Cloud Build
-
SaaS - Mobile 系
- 例) Bitrise
-
OSS
- 例) Jenkins, Concourse, Drone
上に例として挙げた 10 のサービス (ツール) を簡単に比較していき、その後どれを使うべきか、どう学習すべきかを説明していきます。 同時に、各サービスの解説書も紹介していきます。
CI サービスの比較
SaaS - CI 専用サービス系
CircleCI
CircleCI は非常によく使われている CI サービスです。 GitHub Actions の登場で状況が変わっているかもしれませんが、少なくとも GitHub Actions 登場以前はたくさんの事例を聞きました。
GitHub との連携を設定し、YAML ファイルには実行したいシェルコマンドを順に書いていくというスタンダードな使い方です。
public リポジトリか private リポジトリかによらず、ある程度の無料枠があります。
私は未読ですが、2020/9/14 に書籍『CircleCI実践入門──CI/CDがもたらす開発速度と品質の両立』が発売されました。興味がある方は読んでみてもいいかもしれません。
Travis CI
CircleCI と似たような使い方のサービスです。
CircleCI との使い分けは、無料枠の違いでなされることも多いと思います。 CircleCI は private リポジトリ含めた無料枠がありますが、並列実行などに制限があります。 一方、Travis CI は OSS なら完全無料になっています。
Travis CI は OSS 版もあるので、自分たちのサーバに構築することも一応できます。
SaaS - Git サービス系
GitLab CI
GitLab に付属する CI サービスです。
GitLab 自体 SaaS 版と OSS 版があるので、SaaS として使うこともできますし、オンプレミスに立てることも可能です。
GitLab のリポジトリに YAML ファイルをコミットするだけで動き出すので、Git との連携が非常に簡単です。 YAML ファイルを書く感覚は CircleCI や Travis CI と近いです。
GitLab 自体非常に高機能なので、『GitLab実践ガイド』などで大枠を学んでみてもいいかもしれません。
GitHub Actions
GitHub Actions は 2018 年に発表された非常に新しい CI サービスです。
GitHub Actions の非常に特徴的な点は、各ステップのアクションとして GitHub に公開されている様々なアクションを指定可能なことです。 世界中のエンジニアが作ったアクションを使いまわすことができ、GitHub の「Social Coding」というキャッチコピーを体現した CI サービスだと思います。 (CircleCI にも「Orb」というジョブなどの構成要素を共有する機能はあります)
GitHub Actions は何より、GitHub との連携が非常に簡単です。CircleCI と異なり、GitHub に YAML ファイルをコミットするだけで自動的にワークフローが登録されます。CircleCI では GUI で GitHub との連携を設定する必要があるので、GitHub Actions の方が CircleCI よりもセットアップが容易です。
public リポジトリなら完全無料で、private リポジトリでも無料枠があるので、これまで CircleCI や TravisCI を採用していた場面で GitHub Actions が採用されることが増えていきそうです。
こちらも私は未読ですが、『GitHub Actions 実践入門』という書籍もあります。
SaaS - パブリッククラウド系
AWS CodeBuild
AWS が提供する CI サービスです。
YAML ファイルにシェルコマンドを書いていく方式なので、使用感は CircleCI・Travis CI・GitLab CI と近いです。
CodePipeline と組み合わせて CI / CD パイプラインを構築する場合もあります。 個人的には AWS アカウントを開発・本番と分けた際のクロスアカウントアクセス設定が複雑になりがちな CodePipeline は使わず、CodeBuild とシェルスクリプトで頑張るのも悪くないと思います。
Google Cloud Build
設定方法はちょっとクセがあり、1 つ 1 つのステップで実行環境のコンテナイメージと実行するコマンドを指定していくことになります。 例えば、あるステップで npm run build コマンドを実行し、次のステップで docker build コマンドを実行するような場合、最初のステップでは Node.js のコンテナを使い、次のステップでは Docker のコンテナを使うことになります。
なので、コンテナを使い慣れていないと使いこなすのは難しいです。 なんでもコンテナ上で実行したい人は大好きかもしれません。
『GCPの教科書II 【コンテナ開発編】 KubernetesとGKE、Cloud Run、サービスメッシュを詳解』という書籍で、1 章を割いて解説されているので、Google Cloud Build の雰囲気を知るために手に取ってもよさそうです。
SaaS - Mobile
Bitrise 系
Bitrise はモバイルアプリの CI サービスです。
前提として、iOS のビルドは macOS でしかできないうえ、macOS はライセンス的に Apple のデバイス上でしか動かせません。 そのため、iOS のビルドが実行できる CI サービスは限られています。 CircleCI や GitHub Actions も macOS でのビルドに対応していますが、Bitrise が料金面で優れています。
設定方法は独特で、各ステップで事前に用意されたアクションを実行していくイメージです。
モバイルアプリのビルド・デプロイ自体 Web とはかなり異なるので、CI を組む際はその知識が必要になります。
OSS
Jenkins
Jenkins は最も有名な CI ツールだと思います。 CI の SaaS がよく使われるようになるまでは最も使われていたのではないでしょうか。
しかし、最近は Jenkins を採用するケースは減ってきています。 理由として、Jenkins はジョブの設定を YAML などのテキストとして記述・管理する Pipeline as Code が苦手です。 一応 Jenkins Pipeline というものを使えば DSL でパイプラインを記述できますが、他の CI サービス (ツール) と比べて記法の学習コストが高い上、Jenkins Pipeline では簡単に実現できない設定があります。
このように、Jenkins では GUI で設定しなくてはならない箇所ができるなどして、最終的にはチーム内に Jenkins 設定担当者 (いわゆる Jenkins おじさん) が生まれることになりやすく、最近は敬遠されています。
Concourse・Drone
Concourse・Drone は YAML でパイプラインを記述するタイプの OSS の CI ツールです。
どうしても CI の SaaS が使えないという制限がある場合に採用を検討することになります。
選定方法
まず、特に制約がない限りは SaaS を使うことをおすすめします。
どうしても SaaS が禁止されているなどして自前で CI サービスを立てる場合、Concourse や Drone、GitLab CI をオススメします。 Jenkins は Pipeline as Code が苦手なため、あまりおすすめしません。
SaaS を使うとして、iOS のビルドがある場合は Bitrise が有力候補になります。 とはいえ、CircleCI や GitHub Actions に慣れていればそちらを使ってもいいかもしれません。
上記の例外的なケースを除いた多くの場合、アプリケーションのプラットフォームが提供する CI サービス (AWS CodeBuild、Google Cloud Build、Azure DevOps、Heroku CI など) を選択するか、アプリケーションのプラットフォームと無関係な CI サービス (GitHub Actions、GitLab CI、CircleCI、Travis CI など) を選択するかが分岐点になります。
これら 2 つの大きな違いは、自動デプロイのためにアクセスキーを払い出す必要があるかないかです。 前者 (AWS CodeBuild など) の CI サービスであれば、IAM Role のような機能によってアクセスキー不要で自動デプロイが可能です。 後者 (GitHub Actions など) の CI サービスの場合、自動デプロイを実施するためにはアクセスキーのような機密情報を払い出す必要があるので、それを許容できるかが選択可否に影響します。
GitHub Actions、GitLab CI、CircleCI、Travis CI からの選択には、無料枠の違いに注意が必要です。 public リポジトリの場合、GitHub Actions、GitLab CI、TravisCI は完全無料で、CircleCI もある程度まで無料で使えます。private リポジトリの場合、GitLab CI は完全無料で、GitHub Actions、GitLab CI、CircleCI はある程度まで無料となります。
これらを踏まえて、あとは好みのツールを選びましょう。 どうしてもどれを使うべきか迷った方は、YAML ファイルをコミットするだけでセットアップできる GitHub Actions か GitLab CI から使い始めてみるといいのではないでしょうか。
学習方法
最後に、CI サービス (ツール) の学習方法です。
まずはスタンダードな YAML でシェルコマンドを記述するタイプの CircleCI、Travis CI、GitLab CI, AWS CodeBuild あたりをさわってみるといいと思います。 GitHub Actions も、シェルコマンドを書き並べるところから簡単に使い始めることができます。
CI で必ずぶつかる、node_modules などをキャッシュして高速化したいという課題を解決する機能がどの CI サービスにも必ずあるので、そのくらいまではさわってみるといいと思います。
その後、GitHub Actions で公開されているアクションを使ってみたり、コンテナについて学習した上で Google Cloud Build をさわってみるといいかもしれません。
iOS エンジニアなら Bitrise をさわってみるべきです。
さらに、Kubernetes を使っている場合は、Argo CI (CD) や Spinnaker といったツールもよく使われているので、キャッチアップしてみるとよさそうです。
実際に開発を進める上では、CI と近い環境を開発者が使っていることも重要です。 そのため、コンテナや ◯◯env などを使った開発環境の統一にも取り組むのもおすすめです。
