GitLab CIとCircleCIのキャッシュ戦略の違い - くりにっき
仕事でCI全般のお悩み相談されることが多くて .circleci/config.yml や .gitlab-ci.yml をリファクタリングすることがよくあるのですが、その時に一番意識してるキャッシュ戦略について長年自分の中の暗黙知になっていて明文化できてなかったので書きます。 前置き 用語の定義 その他 GitLab CIとCircleCIの両方に共通すること キャッシュを過度に使いすぎない 許容できるケース 11/6追記 ないと困るものはキャッシュにしない 10/30 12:00追記 キャッシュをバージョニングする 複数のブランチでキャッシュを共有できるようにする GitLab CI固有の話 GitLab CIのキャッシュの仕様 CircleCI固有の話 CircleCIのキャッシュの仕様 同一のkeyで一度キャッシュが作られたら上書きができない キャッシュのkeyは前方一致 どうして
CIマニアから見た各種CIツールの使い所 - くりにっき
社内外でちょいちょい聞かれるのでメモ。 前置き GitHubを使ってる場合 ライブラリを作ってる場合 Travis CIを選択する理由 2020/4/21追記 Travis CIを選択しない理由 アプリを作ってる場合 CircleCIとWerckerの共通点 CircleCIとWerckerの機能差異 GitLabを使ってる場合 GitLab CIの優位点 Jenkinsなどを使った方がいい場合 追記：2018/12/8 前置き 100%自分の主観なので偏ってます SaaSかオンプレならSaaS派。（自分でサーバの面倒身たくない） 自分が使ったことがないものは紹介していません 今回紹介してるTravis CI, CircleCI, Wercker, GitLab CI, Jenkinsに関しては仕事や趣味で各3〜4年くらいは使ってるはず GitHubを使ってる場合 ライブラリを作ってる場合
CircleCI 2.0でのスローテスト（テスト遅い）問題対処法を思いつくだけ書き出す - Qiita
まえおき スローテストの解消に関して、昨今のCIサービスを考慮した観点で自分なりの手法をまとめてみる。 CIで出来そうなことは可能な限り網羅したつもりだが、他にもあったらコメントか編集リクエストでご指摘いただきたい。 とりあつかうこと・とりあつかわないこと CircleCI 2.0 を前提とする。 1.0はもうすぐ無くなるので対象外 他のCIサービスは今回対象としてないが、一部似たような機能があるかもしれない。 テストフレームワーク固有の話はなるべく排除している サンプルコードがnodeだったりrubyだったりで統一取れてないのはご了承いただきたい。 dockerモードを前提とする。machine: trueでの実行は検証していない 検証してないだけなので、もしかしたら動くものもあるかもしれない CIではなくCD（継続デリバリー）に特化した話は除外する 転用できる部分はあるものの、あまりフ
CircleCIアンチパターン 2015春 - tehepero note(・ω<)
2015-03-31 CircleCIアンチパターン 2015春 CI CircleCI Docker 今日はCircleCIで気持ちよくCIを回すために、抑えておいた方が良いアンチパターンについて書きます。わりと基本的な話なので、心当たりがあれば見直してみると良いと思います。 Fat Repository Anti Pattern（巨大なリポジトリ） CircleCIのコンテナは使い捨てですが、対象のリポジトリを毎回cloneするのではなくて、2回目移行は前回のCI時にキャッシュしておいたリポジトリを利用することで差分取得を実現しています。 checkoutフェーズのRestore source cacheのことですね。 この手法によって最新取得のコストを大幅に低減することができますが、コンテナ初期化時にS3からリポジトリのアーカイブを取得するという特性上、あまりにも巨大な数GB超えのリ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
