初めに 今回は備忘録を兼ねて、circleciの基礎について解説します！ 私と同じようなビギナーの方に向けてできるだけ分かりやすく解説しますので良ければご覧ください。 なお、今回使用するCircleCIのconfig.ymlはリンク先の記事を使用させていただいております。 【circleCI】Railsアプリでgithubと連携してrubocopとrspecテストを走らせる 使用する設定ファイル 今回はcircleciの設定ファイルについての解説ですので、導入方法などについては割愛します。 # Ruby CircleCI 2.0 configuration file # # Check https://circleci.com/docs/2.0/language-ruby/ for more details # version: 2 jobs: build: docker: # speci
個人でも業務でもすごくお世話になっている CircleCI について説明したいと思います。 設定する際の Tips など個人的な観点を元に紹介していきます！ CircleCI の構造をざっくりと理解する CircleCI で設定する .circleci/config.yml ファイルの中身の構造について理解していきます。 config.yml は大きく分けて、 version, orbs, executors, commands, jobs, workflows の6つのキーワードに分かれています。 この6つのキーワードを理解することで CircleCI がよくわからない方もざっくりと理解することができます。 version キーワードを除くその他のキーワードを見てもらうとわかりますが、基本的に ****s になっているので複数指定することができます。 では順番にそれぞれのキーワードについ
【オフライン開催】Omotesando.rb #92 https://omotesandorb.connpass.com/event/302869/ Example code to skip tests if source trees are the same. https://gist.gi…
GitHub Actionsでテストファイルを複数ノードに適切に分割するためのカスタムアクション、r7kamura/split-tests-by-timingsを作った。 CircleCIに同様の仕組みがあり、今回はこれのGitHub Actions版が欲しかった。 既存ツールとして、Go製のleonid-shevtsov/split_testsというCLIツールがあり、これを利用するchaosaffe/split-testsというカスタムアクションがある。 このカスタムアクションでも不足は無かったが、幾つかの理由で今回自作するに至った。 しばらく使いそうなので、保守性を上げるためにも、不要な機能を取り除いて必要最低限の機能にしたかった GitHub Actionsは仕様変更が多いため、自分で保守できるようにしたかった 今回、内部実装としてRust製のmtsmfm/split-testとい
コンピューティングのカスタマイズによって CI/CD パイプラインを最適化 リソース クラスを使用して、CI/CD ジョブのコンピューティング能力を最適化することで、開発者の生産性向上とビルド時間の短縮を実現できます。 生産性の向上 ソフトウェアのデリバリー パイプラインを高速化することで、コードのビルドが完了するまでの待ち時間を短縮し、コードを作成する時間を増やすことができます。
この記事はCircleCI Advent Calendar 2018の24日目の記事です。 テスト分割実行ファンの皆さんこんにちは。 今回はCircleCIの並列テストにおいて、いい感じにテストファイルを分割することを考えていきたいと思います。 【イメージ アニgif】 テストファイルをいい感じに分割したい まず前提として、「いい感じに分割したい」とはどういうことかということを説明します。 例えば今、テストファイルが7個あって、それぞれのテストにかかる時間が経験上「10秒、6秒、5秒、4秒、3秒、2秒かかる」ということがわかっているとします。 この場合、普通に1プロセスで実行すると10+6+5+4+3+2で30秒かかります。 ここで、CircleCIでparallelism: 3(3並列)で分割テストすることを考えます。 まず悪い例として「[10, 3], [6, 5], [4, 2]」と
背景CIのビルド実行時間の長さは度々社内で問題になっており、「CIに時間かかるので業務効率が下がる」といった話が現場でも増加していました。 業務時間中は複数 Pull Request のビルドが発生するので、「CI順番待ちで次の自分のビルドは1時間後」のような現象は日常茶飯事でした。 おまけに「頻度は低いがランダムで失敗するテスト」といった false positive なテストの存在も、開発現場のフラストレーションは溜まる原因になっていました。単純に CI を再ビルドすれば直るのか、自分が追加した実装/rspecに問題があるのか一件判断がつかないケースだと、開発担当者も一旦 CI 上で再ビルドを行い、同じ箇所でコケるのか確認することになるので、これがさらなる CI 渋滞を引き起こしていました。 こうした背景もあり、丁度プロジェクトの隙間で工数もあったので「CI 改善をしっかり工数確保して
## 結論 CircleCIのTest Insightを使うとFlakyテストの可視化が簡単。  ## 経緯 フィヨルドブー
株式会社アンドパッドのアカウント基盤チームでテックリードをしているid:shiba_yu36です。 最近自分のサイドプロジェクトとして、生産性を向上するために、CI実行時間の短縮化を行っていました。その結果、とくに時間のかかっていたCircleCI上のRSpecによるテスト実行時間を、25min -> 12minに改善できました。そこで今回はどのような流れでCIの実行時間を改善していったかについて、具体的に書いてみたいと思います。実行時間改善の勘所について参考になれば幸いです。 改善の流れ: CircleCIでボトルネック調査し、大きいボトルネックを解消する 実行速度改善の前に: Flakyなテストを一斉に直す 速度改善1: bundle installのキャッシュがうまく効いていなかった問題を修正 -> 4minの短縮 速度改善2: developブランチ以外ではカバレッジを取らないよう
概要この記事はCircleCI Advent Calendar 2020の9日目の記事です。 スタディスト開発部の笹木です。今年に入ってからは開発基盤チームという位置づけで、開発環境の整備や、CI含むテスト自動化周りを担当しています。 本記事では、RSpecのテスト実行時間を半減させ、CircleCIの消費クレジットを大幅削減した取り組みについてご紹介します。(消費クレジットについては後述します) 改善の結果が以下のグラフで、定点観測しているジョブの消費クレジットが、ピーク時の半分にまで落とせていることがわかります。もちろんテストコードを減らすといった本末転倒なことはしていません。 RSpecジョブ実行時の、CircleCI消費クレジットを時系列で表したグラフ実施した取り組みは以下の通りです。 CircleCIの料金体系を知る問題を認識するCircleCIの利用状況を可視化するRSpecの
2020年にCircleCIの次世代イメージ・cimg が登場しました1。 個人のRuby on Railsプロジェクトで、従来のcircleci/rubyから次世代イメージであるところのcimg/rubyに移行してみたので紹介します。 ベースイメージの変更 circleci/ruby から cimg/ruby へ変更します。 executors: default: working_directory: ~/app docker: + - image: circleci/ruby:2.7-node-browsers - - image: cimg/ruby:2.7-browsers CircleCI 公式 Orb の利用 今回の変更とあわせて、下記２つのCircleCI公式Orbも導入しました。 CircleCI Developer Hub - circleci/ruby CircleCI
概要 railsのアプリでrubyのバージョンを上げようと思って.circleci/config.ymlのimageを変更したらmysqlに接続できなくなってちょっとはまったので共有しておきます。 結論 mysql-clientパッケージ名がdefault-mysql-clientに変わったので変更する。 bundle installのキャッシュの消さないとmysql-clientのパッケージが変わったので接続できない。 やったこと config.ymlを以下のように変更してpush。 ※ config.ymlは関係ない部分を省略してます。 version: 2.1 jobs: build: docker: - - image: circleci/ruby:2.6.1-node-browsers + - image: circleci/ruby:2.6.3-node-browsers -
このイメージは、従来の CircleCI 製 Ruby イメージ circleci/ruby の後継となるものです。 cimg/ruby は、継続的インテグレーションでのビルドを想定して CircleCI が作成した Docker イメージです。 各タグには、特定のバージョンの Ruby 一式と gem コマンド、Bundler、および CircleCI 環境でビルドを正常に完了させるために必要なバイナリとツールが含まれています。 使用方法このイメージは、CircleCI Docker Executor と組み合わせて使用します。 以下に例を示します。 1 2 3 4 5 6 7 jobs: build: docker: - image: cimg/ruby:3.3.0 steps: - checkout - run: ruby --version 上記の例では、この CircleCI 製
問題 Docker Hubは、無料アカウントと認証なしユーザーで、11月からpull数に制限がかかります。CircleCI上で認証無しで運用しているとIPアドレスベースの制限がかかり、CircleCIのIPアドレスはユーザーと比較して多くないので影響が懸念されます。 CircleCIチームはDocker社と会話してる模様なので、今後もしかしたらユーザーの対応は不要となるかも知れません。しかしCI/CD環境が止まれば影響は大きいので回避策を押さえておきましょう。 解決策 ひとまずDocker Hubのユーザー認証を噛ませれば、IPアドレスでは判断されなくなるので無料アカウントでも200 pulls/6hまでは利用できます。これ以上になるならDocker Hubへの課金が必要ですが、どのみちCircleCI上でユーザー認証を行う必要があるので同様の作業が発生します。 作業手順 以下の作業でCi
先週仕事でやったのをメモします。 CI力が低いので、記事を公開することでツッコミをもらうのが目的です。 モチベーション 弊社ではCIの実行が1回あたり20分ほどかかっています。 これはわりとストレスなので速くしたいです。幸いにも削れそうなところが2つ見つかったので削ってみました。 Shallow Clone CircleCIではデフォルトのcheckoutを使用するとリポジトリの全体をcloneしてきます。 これを回避するためにshallow cloneを導入しました。 まず、次のようなコマンドを定義します。 commands: shallow-clone: description: 'Git clone shallowly' steps: - run: name: 'shallow clone' command: | set -x echo "machine github.com log
11月に入社したCTO室SREの@sinsokuです。 主にやっていることはRailsアプリのレビューや開発環境の改善です。*1 社内のRailsアプリを横断して浅くレビューする（8つくらい） MedPeerの開発環境の改善 docker-compose up で30個のコンテナが起動するのを減らす SwitchPointからActiveRecord v6への移行 CircleCIの実行時間の短縮、稀に落ちるテストの修正 その他の細かい改善 このうち、CircleCIについて知見が溜まったので技術ブログで紹介します。 CircleCIで気をつける点 CircleCIの実行時間を短くするにはいくつかコツがあります。 gemとnpmをできるだけキャッシュする RSpecを並列で実行する前に assets:precompile を実行しておく 各ジョブで必要なgem（もしくはnpm）だけをキャッ
TL;DR rspec-retryは同じプロセスの中で再実行(問題: まじで落ちてるテストも再実行される、プロセスで保持してる状態が壊れると何度実行してももとには戻らない) bundle exec rspec Rerunは別プロセスで再度実行(2連ガチャ) bundle exec rspec bundle exec rspec この記事で紹介してるのは落ちたものに限って別プロセスで再度実行 bundle exec rspec --failure-exit-code=0 bundle exec rspec --only-failures 本題 夏といえばそうめん。流しそうめんって掴みそびれると落ちますよね。 こんかい紹介する.circleci/config.ymlはこちら! たまに落ちるRSpecのexampleを受け止めて、落ちたexampleだけリトライするCircleCIの設定です。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
