TravisCIを使っていた人が1週間ぐらいCircleCIを使ってみた感想

普段TravisCIを使っていた人が、CircleCI 2.0を使い始めました[^use_free_cis]。
[^use_free_cis]: TravisCIもCircleCIも無償の範囲での利用です。

1週間ぐらい**CircleCIを使った感想**をTravisCIと比較しながら書きたいと思います。

## :rocket: 早い！

好きにDockerイメージを指定できるため、環境が整っているものを選べば、環境構築のプロセスで時間を取られなく早いです。小さいプロジェクトだと、pushして数秒で成功/失敗の結果がわかるものもありました。

### docker build を実行するjobも早い

TravisCIだとsudoが必須になるDockerを動かすと、sudoがないものよりrunするまで待ち時間がかかります。ですが、CircleCIは`docker build`するjobも開始までの待ち時間がありませんでした。

## とても細かく設定できる

とても細かくCIしたい内容を設定できる感じです。checkoutするタイミングもキャッシュするタイミングもその他色々細かく制御できそうな感じです。そのため、TravisCIだと裏でどんなことが起こっているのか把握しづらかったですが、CircleCI 2.0は何をするか自分で細かく制御できる感じがします。workflowなども考え方も高速なビルドができてとてもいいです。

その反面`.travis.yml`よりも`.circleci/config.yml`のほうが記述量が増えました[^I_use_cirleci2]。


[^I_use_cirleci2]: CircleCI 2.0を使っています。1.0のときはTravisCIに設定が近いかも知れません。

## GitHubのPRのページでjobごとに成功/失敗が見れる

以下のように、プルリクエストのページで各jobの成功/失敗が確認できるのがとても良いと思います。
<img width="788" alt="スクリーンショット 2018-12-21 11.36.37.png" src="https://qiita-image-store.s3.amazonaws.com/0/84451/7e96691b-0aa6-8aad-2da9-86a18e91c9b8.png">

以下ように、TravisCIの場合だとGitHub上PRのページでは全体での成功/失敗しかわかりません。

<img width="720" alt="スクリーンショット 2018-12-21 11.41.25.png" src="https://qiita-image-store.s3.amazonaws.com/0/84451/71823644-30f1-66f7-2cff-cd0356ea5db9.png">

以下のように、少し手間がDetailsを押せばTravisCIでも見れます。
<img width="254" alt="スクリーンショット 2018-12-21 11.43.14.png" src="https://qiita-image-store.s3.amazonaws.com/0/84451/63d4dac8-9bba-06fc-0094-e6f7de570a0e.png">

## Slack通知の設定がとても手軽

TravisCIはリポジトリごとの`.travis.yml`にどこに通知するかの設定を書かなくてはいけなく、とても面倒でした。そして、トークンなどをsecretする作業がとても面倒でSlack通知設定の手軽さはありませんでした。

それに対して、CircleCIは各リポジトリのビルド結果を特定のチャンネルに通知できる設定があるので、通知設定がyamlの外側の世界でとてもいいです。

こんな感じに届きます。
<img width="500" src="https://qiita-image-store.s3.amazonaws.com/0/84451/9678bbe2-6ac4-0420-b427-a5d246b4fde2.png">



## 更にローカルで動かせるようになりそう

今後ローカル環境でCircleCIがもっとちゃんと動くようになりそうなので、TravisCIよりも将来性がありそうです。ローカルで動かせると、わざわざpushしなくても挙動を試せるため、CIの設定ファイルをデバッグしやすいと思います。

CircleCIの設定yamlでDockerイメージを明示的に指定している点などから、ローカルで動かすのがTravisCIよりも実現しやすいのではないかと思っています[^travis_ci_on_local]。

[^travis_ci_on_local]: だいぶ前にTravisCIをローカルで動かしたくて調べたときは、Ruby限定で動くなどを見たのでTravisCIをローカルで試すのは難しいのかなと思ってます。

CircleCIをローカルで動かす: <https://github.com/CircleCI-Public/circleci-cli>
まだ、workflowに対応してないみたいですが、将来的に対応してくれそうなので期待してます。

## TravisCIと比べて気になったところ

ちょっとCircleCIの残念に感じたところも書きたいと思います。

### 複数のバージョンで同じjobをしようとすると、YAMLのanchor/aliasが必要になる

もちろん、コードを重複させてもいいのならanchorを使う必要はないです。ですが重複したコードはメンテナンス性をものすごく下げるので、できれば重複させたくないです。
TravisCIだと、`node_js: [10, 8, 6]` とかで簡単に複数の言語のバージョンを増やせたのと比べる少し手間を感じます。

ですが、朗報で2.1で改善するという記事を見つけました。今後に期待です。
参考：　[CircleCI 2.1 の新機能を使って冗長な config.yml をすっきりさせよう！ – PSYENCE:MEDIA](https://tech.recruit-mp.co.jp/dev-tools/post-14868/)

### yamlがちょっと複雑

`.travis.yml`と比べれば`.circleci/config.yml`(CircleCI 2.0)は複雑になると思います。複雑だと読むのに時間がかかるかもしれません。ただ、これは細かく制御できることのトレードオフだと思うので、気にしていません。それよりも読みやすい`.circleci/config.yml`の書けるようになることが大事な気がします。


### GitHubに新規リポジトリを作ったときに自動でCIしてくれない

TravisCIは、GitHubにリポジトリ作って、`.travis.yml`を設置すれば自動で回ってくれるのでとても手軽なのですが、CircleCIは[ADD PROJECTS]しないとCIしてくれないので、ちょっと面倒です。`.circleci/config.yml`があるリポジトリは自動でCIしてくれるオプションほしいです。

### ちょっとWebのUIが使いづらく感じる

あくまでも個人的な感想です。
見つけたjobを探すのに少し時間がかかる気がします。
ビルドのログの詳細を見るためにクリックする回数が少し多い気がします。（多分直に慣れると思います）


### デフォルトのバッヂが...

デフォルトのバッヂがよく見かけるsheild-styleではなく他のバッヂとか並べたときに相性が悪いです。

これは、`~.svg?style= shield`にすればいいだけなので、すぐに変更できます。

これを変更するのも面倒な人もための、Chrome拡張を作りました：
[CircleCIのバッヂをデフォルトで格好良くしたい！ - shield-style - Qiita](https://qiita.com/nwtgck/items/39a3d6914e002c1bba12)

<img width="128" alt="Screen Shot 2018-12-14 at 8.33.55.png" src="https://qiita-image-store.s3.amazonaws.com/0/84451/61d47687-db81-41e3-a0ce-46c49a3b7b3b.png">

==>

<img width="195" alt="Screen Shot 2018-12-14 at 8.32.54.png" src="https://qiita-image-store.s3.amazonaws.com/0/84451/95d85a77-0df8-322b-c2f1-b300110000ea.png">

見た目も大事ですよね。

- - -
（また、CircleCiの良いところ思い出したら追記したいです）