TravisCIとCircleCIでちょっとずつ違うビルド環境の考え方の違い
tl;dr TravisCIとCircleCIの根底にある違いの考え方を理解すると早い。 そして、違いを考慮しているproductを使うと便利。 e.g. checkstyle形式の結果をpull request review commentするsaddler CI result 考え方 CircleCI pushされたbranchをビルドする。 TravisCI pushされたbranchをビルドする。 pull requestのbranchを、仮にmasterにmergeしてみて、ビルドする。 仮にmasterにmergeしてみて?? TravisCIの二つ目のがわかりにくくて、混乱する。 やっていることは正しいんだけど、挙動が直感から外れるので、 TravisCIヘビーに使っているユーザーにもわりと意味不明挙動扱いされやすい(要出典) pull requestするとtravisのビル
まだ Travis で消耗してるの？ - Qiita
開発のイテレーションを高速に回す上で、CI は非常に重要な役割を担っています。バージョン管理システムにコードをプッシュ（コミット）したと同時に、CI に対してコードのビルドやテスト、解析をリクエストすることで、アプリケーションのデプロイやディストリビューションからユニットテストとコードの静的解析までの流れを自動化し、作業の抜け漏れ防止や効率化が見込めます。 最近では、Jenkins のように自分たちで CI を管理しなくても、ビルドやテストの手順と環境構築に必要な少しの情報を与えれば勝手に動作してくれる CI サービスがいくつか出てきました。代表的なところでは、TravisCI, CircleCI, wercker, drone.io などがあります。この中でも特に、TravisCI は古くから GitHub と連携して自動で動いてくれるようになっており、よく使う人も多いのではないかと思い
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
