開発のイテレーションを高速に回す上で、CI は非常に重要な役割を担っています。バージョン管理システムにコードをプッシュ（コミット）したと同時に、CI に対してコードのビルドやテスト、解析をリクエストすることで、アプリケーションのデプロイやディストリビューションからユニットテストとコードの静的解析までの流れを自動化し、作業の抜け漏れ防止や効率化が見込めます。
最近では、Jenkins のように自分たちで CI を管理しなくても、ビルドやテストの手順と環境構築に必要な少しの情報を与えれば勝手に動作してくれる CI サービスがいくつか出てきました。代表的なところでは、TravisCI, CircleCI, wercker, drone.io などがあります。この中でも特に、TravisCI は古くから GitHub と連携して自動で動いてくれるようになっており、よく使う人も多いのではないかと思います。
ただ、幾つかの点で TravisCI に不便を感じる事があったので、思い切って CircleCI に乗り換えてみたところ、とても快適に CI が扱えるようになったので、その差異について記録しておこうと思います。
ビルドスクリプトの変更の気軽さ
TravisCI では、ビルドを実行するコンテナに接続する手段がありません。このため、ビルドスクリプト（YAMLファイル）に何か変更を加えようとすると、必ず GitHub にコミットをプッシュしなければなりません。気にしなければ問題にならないかもしれませんが、ビルドスクリプトが期待通り動くようにするまでに何度もコミットをプッシュしていくと、それだけでそれなりのコミットログがビルドスクリプトの修正のためだけに積み上げられていってしまい、肝心のアプリケーションの変更のためのコミットが埋もれていってしまいます。
それに比べて CircleCI では、ssh でコンテナにアクセスでき、コンテナ内でビルドスクリプトの変更とビルドを試すことが出来るようになっています。これならば、ビルドスクリプトの変更のためのコミットは 1 つで済みます。
成果物へのアクセス
TravisCI では成果物へのアクセス手段がありません。AWS S3 にアップロードするような手順をビルドスクリプトに書くことをしない限り、ビルドによって生成される成果物は消滅してしまいます。成果物を見るために S3 へアクセスしなければならないのも面倒です。
CircleCI の場合、ビルドスクリプトに、どのディレクトリを成果物とするかを指定するだけで、それらがビルドごとに保存され CircleCI のコンソール上でアクセスできるようになります。一々 S3 へアクセスしなくても、CircleCI の UI から全てに手がとどくのはとても便利です。
料金
CircleCI は private repository は 1 コンテナまで無料です。ちょっと試す分には断然お得です。
まとめ
自分は別に CircleCI の回し者でもなんでもないのですが、TravisCI で悩ましかったポイントが解消され、とても便利でお手軽に使うことが出来ているので、これを機に CircleCI を試してみてはいかがでしょうか。