12
6

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

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

Last updated at Posted at 2018-12-21

普段TravisCIを使っていた人が、CircleCI 2.0を使い始めました1

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のほうが記述量が増えました2

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

以下のように、プルリクエストのページで各jobの成功/失敗が確認できるのがとても良いと思います。
スクリーンショット 2018-12-21 11.36.37.png

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

スクリーンショット 2018-12-21 11.41.25.png

以下のように、少し手間がDetailsを押せばTravisCIでも見れます。
スクリーンショット 2018-12-21 11.43.14.png

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

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

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

こんな感じに届きます。

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

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

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

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

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

Screen Shot 2018-12-14 at 8.33.55.png

==>

Screen Shot 2018-12-14 at 8.32.54.png

見た目も大事ですよね。


(また、CircleCiの良いところ思い出したら追記したいです)

  1. TravisCIもCircleCIも無償の範囲での利用です。

  2. CircleCI 2.0を使っています。1.0のときはTravisCIに設定が近いかも知れません。

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

12
6
1

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
12
6

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?