CI サービスをいくつか触ってみたのでまとめ。
今回の目的は、テストを実行すること。なので、ビルドやデプロイ辺りはちゃんとは見ていない。
ドキュメントで確認しただけの項目などもあったりするので、間違っていたらごめんなさい。教えてもらえると助かります。
ただ、これは記事を書いた時点での比較で、今後のサービスの変更に対応する予定はないです。
機能比較
機能比較は全て無料プランでのもの。有料だと対応している場合でもここでは x にしている。
比較項目は私の独断と偏見で適当に選出した。
| 項目 | AppVeyor | CircleCI | Drone IO | Magnum CI | semaphore | shippable | Travis CI | wercker | 備考 |
|---|---|---|---|---|---|---|---|---|---|
| YAML による設定 | ○ | ○ | × | ○ | × | ○ | ○ | ○ | リポジトリ内の YAML ファイルからビルド手順を設定できる |
| Web UI による設定 | ○ | ○ | ○ | ○ | ○ | × | × | × | Web UI でビルド手順のスクリプトを書くことができる |
| GitHub 連携 | ○ | ○ | ○ | ○ | ○ | ○ | ○ | ○ | GitHub のリポジトリ一覧から新規プロジェクトを作れる |
| BitBucket 連携 | ○ | × | ○ | ○ | ○ | ○ | × | ○ | BitBucket のリポジトリ一覧から新規プロジェクトを作れる |
| GitHub PR 対応 | ○ | ○ | × | × | ○ | ○ | ○ | ○ | GitHub の Pull Request を自動でビルドしてステータスを返せる |
| ビルド環境キャッシュ | × | ○ | × | × | ○ | × | × | ○ | 複数ビルド間を跨ぐキャッシュ領域を利用できる |
| 手動リビルド | ○ | ○ | × | ○ | ○*1 | ○ | ○ | ○ | 過去のビルドを手動でリビルドできる |
| 複数環境ビルド | ○ | × | × | × | × | ○ | ○ | × | 環境変数などで複数の環境に対してビルドできる |
| private なプロジェクト | × | ○ | × | ○ | ○ | ○ | × | ○ | ビルド状況などを private にできる(かなり未検証) |
| ビルド時間制限 | 30分 | 20分 | 15分 | 30分 | 60分 | 60分 | 50分 | 25分 | 無出力時間による制限が別途ある場合もある |
YAML による設定の利点は、プロジェクト構成の変更とビルド手順の変更を紐付けることができること。
Web UI による設定の利点は、プロジェクトに直接関係ないファイルを置かなくて済むこと。特にファイルを置く権限がない場合などには助かる。
各サービスについて雑感
以下、かなり主観かつざっくりな雑感。
AppVeyor
.NET 向けの CI サービス。
.NET に特化した機能が色々使えるけど、重要なのは、テスト環境が Windows であるということ。他に Windows 環境での CI サービスを少なくとも私は知らないのでかなり貴重。.NET 製じゃなくてもこれを使えば Windows 環境でテストができる。
設定のスクリプトは、Windows のバッチファイル(.bat) と、PowerShellスクリプト(.ps1)の形式で書ける。PowerShell は .NET のライブラリにアクセスできるので、外部からリソースのダウンロードなども可能。
ビルドトリガーが引かれると、新しいビルドは QUEUE に積まれて、実際にビルドが始まるまでに結構時間がかかる。
ビルド時間について、このページでは全てのプランは40分と書いてあるが、このページでは、Free、Professional、Premium は 30 分で Enterprise は 50 分と書いてある。どちらが正しいか不明。
CircleCI
必要な機能は一通り揃っている印象。
YAML での設定において、各ビルドフェーズに、pre(フェーズ前)、override(フェーズのデフォルト動作を上書き)、post(フェーズ後)それぞれに対してスクリプトが書けたり、コマンド毎にカレントディレクトリや環境変数、タイムアウト時間などを指定できるので、柔軟に設定できる。
Drone IO
Go 言語製の CI サービス。
他のサービスがビルド手順をいくつかに分割している中、Drone IO のビルド手順は1つのみと、とてもシンプル。
Pull Request 時のビルドは、がんばればできるらしいけど、それでもPR以外の普段の push で API が叩かれたり、ビルドページから Pull Request のページへ飛べなかったりするので、できるとは言わない方が良さそう。
Magnum CI
現時点でまだ public beta の CI サービス。結構前からずっと beta な気がする。
使い勝手については特に問題はない。普通に使える。
beta なので、private リポジトリが無制限で使える模様。いつ beta が取れるのかは不明。
semaphore
ビルド中にスレッドが使えるのが特徴。ビルドパイプラインの各コマンド単位で、どのスレッドで走らせるか指定できる。無料で 1 ビルド中に 2 スレッドまで使える。
あとはプロジェクト構成を見て、一般的な構成の場合は自動で検出してビルド設定を自動で終わらせてくれるらしい。私が試したプロジェクトは一般的な構成ではなかったので、どこまでやってくれるのかよくわかってない。
shippable
Travis CI と互換があり、.travis.yml ファイルが置いてあるとそれを認識してビルドを行ってくれる。ただ、どこまで互換があるのかは不明。Travis CI には language に generic が指定できるのだけど(ただしドキュメント化されていない)、shippable では指定できなかった。
Web UI が開かれるまでに結構時間がかかる。
wercker
他の CI と比べても変わった、box と step という特徴がある。
box はテストの実行環境。ユーザーが作成したものを wercker ディレクトリに登録しておけば、誰でも使えるようになる。特定のツールがインストール済みの環境などを作っておけば、ビルド時間が短縮できる。標準でいくつか用意されているので、それらを使ってももちろんよい。
step はビルドの手順の1つ。bash で言う1つのコマンドで、wercker ではこの step のリストをビルド手順として指定する。step は、特定の動作を抽象化してまとめたもので、Amazon 3S との同期とか、npm install とか、そういう感じのが1つの step として登録されている。最悪 script step というのがあるので、これで bash でやってもよい。この step もユーザーが自作できる。
まとめ
無料でもこれだけの選択肢があるというのがすごい。
よりどりみどりなので、各自のユースケースにあった CI サービスを選んで使うといいと思う。
*1:ブランチ最新のみ
