他のビルドツールで既にあった、ビルドパイプラインと考えればわかりやすいと思います。 これを導入すると何が嬉しいかというと、 ビルドの実行フェーズを複数に分けることで、どこでFailしたかなどが視覚的に掴みやすい並列にjobを実行させることで通常の同期的なビルドフローよりも効率良く回せる具体的にはbundle installとかnpm installとかを並列に回して、共有ディレクトリに結果を入れたりできる色々並列にjobを回したあと、それを待ち受けて最終的な結果を同期的に受け取ることもできるbranchや言語のバージョンによって別々でテストを回したい時などに別個かつ並列にビルドを行える外部APIにつなぎにいく時にfailした場合などでは、Rerun from failedができるので、ケースによっては全工程をなぞる必要がなくなるなどのメリットがあります。 早速自分のこれまでのcircle.
今在籍している企業では、最近CircleCI2.0へのアップグレードが盛んに行われている。 すでにアップグレードを体験された方からは、「は？」「速すぎてドン引き」「爆速すぎてずっと泣いてる」などとの感想が寄せられている。元気そう。 具体的に自分もAPIでバージョンを上げたら、6分半が45秒になった。 で、特定のpackageのtestだったり、インフラ周りの設定のアタッチ等なら小規模なのでなんとなくかけば導入できる。 しかしAPIとなると、意外と設定を載せているところがまだ少なかったので、API用途だとざっくりとこんな感じだよというのを書きたいと思う。 もしそこまでじゃなくていいので、簡単な設定がみたければこちらへどうぞ 全体感APIやある程度の規模のソフトウェアのCIとなると、 依存パッケージのインストールlinterでの文法チェックテストデプロイの諸々をやらなくてはならない。 色々名前
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
