社内外でちょいちょい聞かれるのでメモ。
前置き
- 100%自分の主観なので偏ってます
- 自分が使ったことがないものは紹介していません
- 今回紹介してるTravis CI, CircleCI, Wercker, GitLab CI, Jenkinsに関しては仕事や趣味で各3〜4年くらいは使ってるはず
GitHubを使ってる場合
ライブラリを作ってる場合
紛らわしいですが https://travis-ci.org/ は無料版で https://travis-ci.com/ が有料版。
今は両方 https://travis-ci.com/ に統一されてるとのこと *1
OSSであれば基本的にはTravis CIを使っていればいいと思います。
Travis CIを選択する理由
- 「各Rubyのバージョン x 各Railsのバージョン」のようなマトリクステストが書きやすい
- https://docs.travis-ci.com/user/build-matrix/
- CircleCIなどでもできないことはないが、yamlの記述量が増えるのが難点
- ビルドマトリクスの軸が2つ以上になる場合はTravis CIの方が圧倒的に楽
- というか、
CircleCIやGitLab CIで2軸以上のマトリクステストは人間がメンテできる気がしない、、、
- というか、
2020/4/21追記
CircleCIでマトリクスビルドがサポートされたので一部修正
- https://circleci.com/blog/circleci-matrix-jobs/
- https://circleci.com/docs/2.0/configuration-reference/#matrix-requires-version-21
Travis CIを選択しない理由
- ビルド時のスペックが求められる時
- rubocop系のリポジトリはCircleCIの方がスペック高くてビルドが速く終わるという理由でTravis CIからCircleCIに移行している模様
- https://github.com/rubocop-hq/rubocop/pull/5767
- https://github.com/rubocop-hq/rubocop-rspec/pull/528
- Travis CIで用意されていないビルド環境を使いたい時
- 例えばTravis CIはMySQLとPostgreSQLはインストール済だけどOracleはインストールされていない。https://github.com/sue445/index_shotgun ではOracleを使ったテストもやっているのだが、Travis CI内でOracleのインストールを行うよりインストール済のDockerイメージを使った方が速い*2のでOracleのテストだけCircleCIを使っている
- 社内で既に別のCIサービスの有料プランに入っている場合
- TravisCI(有料版)はそこそこの値段するので*3、既に社内でCircleCIなどを導入済の場合は社内ライブラリもそっちに載せた方が楽という選択肢もある
アプリを作ってる場合
アプリの場合
- テスト
- テストが成功したもののみ開発環境にデプロイ
- 開発環境で確認して問題がなかったらステージング環境にデプロイ
- ステージング環境にデプロイして問題なかったら本番環境にデプロイ
というワークフローがよくあると思いますが、Travis CIだと複雑なワークフローを組むのが大変なので CircleCI や Wercker を使うのがいいと思っています。
CircleCIとWerckerの共通点
- 任意のDockerイメージが使える
- ワークフローが組める
- 設定ファイルがymlファイル
- 無料プランでもプライベートリポジトリがビルドできる
CircleCIとWerckerの機能差異
CircleCI 1.0時代はWerckerの方が機能面で優秀でしたが、現時点ではCircleCIの方が全体的に使い勝手がいいと思っています。(今後変わるかも)
理由
- Werckerは1リポジトリ1 Dockerイメージだが、CircleCIはジョブ単位で利用するDockerイメージを変えられる
- Travis CIのマトリクステストをCircleCIで実現する場合、ジョブごとに使うDockerイメージのtagを変えるのが楽だと思います
- CircleCIはスケジューラ(cronのようにジョブを定期実行)をサポートしているが、Werckerは非サポート
- WerckerのAPIをcrontabから定期的に叩けばいけるんだけど、CIサービスだけで完結しないのが難点
- 【宣伝】Werckerでジョブを定期実行しやすくするツールは昔作りました
- CircleCIはほぼ全ての設定がymlに集約されているが、Werckerの場合ワークフローの定義部分は管理画面で設定する必要がある
- CircleCIとWerckerではCircleCIの方が複雑なワークフローを組める
- CircleCIだと自動実行だけでなく、人間が承認することによってワークフローの先のステップに進めるということができる(Manual Approval)
- https://circleci.com/docs/2.0/workflows/#holding-a-workflow-for-a-manual-approval
- 例)開発環境はmasterブランチを常に自動デプロイをしたいが、本番環境には任意のタイミングでデプロイしたいとか
GitLabを使ってる場合
リポジトリ(GitLab本体)と一体化していて連携が楽なのでGitLab CI一択。
設定ファイルの書き方に細かい違いはあるものの、基本的にCircrleCI 2.1相当の機能があるので普通に使う分にはまず機能面で困ることは無いと思います。
GitLab CIの優位点
- Merge When Pipeline Succeedsがある
- MergeRequestのビルドが成功したら自動でマージする機能。GitHubにはなくて地味に便利
- https://docs.gitlab.com/ce/user/project/merge_requests/merge_when_pipeline_succeeds.html
- Runner(ジョブの実行場所)を自分で作れる
- GitLabは( https://gitlab.com/ とオンプレのどっちでも)自分で作ったRunnerを登録できるので、「テストはAWSなどの社外のサーバでいいのだがデプロイだけは社内のサーバを使いたい」ということが可能
Jenkinsなどを使った方がいい場合
下記のユースケースに関してはJenkinsや他のツールを使った方がいいと思います
- 複数のリポジトリにまたがるジョブを構築したい時
- Parameterized Trigger Plugin のように、ジョブ実行時にパラメータを選択したい時
- ビルド環境がハードウェア依存の場合
- イントラ環境でのビルドが必要な場合
追記:2018/12/8
from id:tnir
CIマニアから見た各種CIツールの使い所 - くりにっきb.hatena.ne.jpGitHub\.comを使ってる場合、GitLab CI/CD for GitHub (SaaS)の選択肢はないのかどうか。
2018/12/08 00:01
なるほど。これは知らなかったです
アリかナシかで言えばアリで、GitHubだけどイントラ内でCIをしたい(が自前でJenkinsをホスティングしたくもない)ような場合にはGitLab CIに軍配が上がりそうです。(Runnerをホスティングする手間はあるけど)
*1: https://twitter.com/ndxbn/status/1071045198145191943
*2:TravisだとOracleのインストールだけで10分くらいかかった
*3: https://travis-ci.com/plans
*4:https://circleci.com/docs/2.0/ios-tutorial/
*5:GitLabはそもそもオンプレやんというツッコミはありそうですが、SaaSのGitLab.comとオンプレのRunnerを連携できます