RailsアプリのCI高速化
参加しているプロジェクトで、RailsアプリのCIの高速化を行った。 まだ進行中の部分も幾つかあるが、結果から言うと、元々8分前後だったテストが3分半程度に短縮された。行った作業を幾つかの観点に分け、どのように高速化を行ったか、どの程度高速化されたか等を記述する。 プロセス数とマシン性能の調整 元々は2コア1プロセス4マシンで8分程度掛かっていたが、8コア8プロセス1マシンに変更することで5分程度に短縮された。 このプロジェクトではCIにGitHub Actionsを利用している。GitHub Actionsではデフォルトで2コアのマシンが利用されるが、Large runnerを利用して8コアに変更した。費用は変わらない。 また同時に、8プロセスで並列実行するためにparallel_testsを導入した。このプロジェクトではMySQLとElasticsearchを利用しており、またファイル
CIコスト下げたい、テスト実行時間減らしたい時のアイデアまとめ - ストロングゼロは睡眠薬
友人にcircle ci 料金下げる。または、rspec実行時間減らした時にやるべきことを聞かれたのでまとめておく Railsプロダクト前提です。 テストしない (野蛮だけどアイデアの一つとしてね....) 不要なコードとテストを削除 並列化 完了時間は実行時間の長いテストに引きずられるので実行時間が均一にする(並列化した後) bundle config使ってdevelopment groupライブラリをinstallさせない (メモリも少なくなります) bundle install や yarn installを別jobで動かしコンテナイメージ作成。テスト実行jobでコンテナfetch draft prだったらcircleci実行しない。open prだけci回す skip ci 活用する resource_class調整 不安定なテストを直す(リトライしている場合) defaultブラ
Railsのテスト実行時間を1/3まで短縮した話 (Rspec + CircleCI)
背景CIのビルド実行時間の長さは度々社内で問題になっており、「CIに時間かかるので業務効率が下がる」といった話が現場でも増加していました。 業務時間中は複数 Pull Request のビルドが発生するので、「CI順番待ちで次の自分のビルドは1時間後」のような現象は日常茶飯事でした。 おまけに「頻度は低いがランダムで失敗するテスト」といった false positive なテストの存在も、開発現場のフラストレーションは溜まる原因になっていました。単純に CI を再ビルドすれば直るのか、自分が追加した実装/rspecに問題があるのか一件判断がつかないケースだと、開発担当者も一旦 CI 上で再ビルドを行い、同じ箇所でコケるのか確認することになるので、これがさらなる CI 渋滞を引き起こしていました。 こうした背景もあり、丁度プロジェクトの隙間で工数もあったので「CI 改善をしっかり工数確保して
失敗したテストのログだけを出力するぞ - おもしろwebサービス開発日記
表題の通りのことができるgem、CiLoggerが便利ですよという話です。 私達は大量のテストをCI上で実行しています。テスト結果を見れば失敗理由が自明なものもありますが、E2Eテストなどでよく起きる「たまに失敗するテスト」の調査はログやスクリーンショットなど、可能な限りの情報を集めないと根本原因がつかめないことが多いです。 そんなときに、特に考えずRailsデフォルトの設定(config.log_level #=> :debug)のままにしておくと、膨大なログの中から該当するテストに関連する行を探し当てる作業が必要になります。これは事前の準備なしではほぼ不可能です。 事前の準備として簡単に思いつく方法は、テスト前後で「どのテストが開始/終了したか」をログに出力することです。 config.around do |example| Rails.logger.debug("start exam
今までありがとうTravis CI、さよならTravis CI - xuwei-k's blog
しっかり調査してないですが、こういったCIサービスがほぼ存在しない時期にほぼほぼ最初に登場して、一時期明らかにデファクトスタンダードだったと思うので、昔からOSS活動している人ほど、とても多く利用してお世話になっていたと思うので、そういう人であればあるほど、この状況は、怒りではなく、悲しいというか残念というか、辛いと思うんですよね・・・。 今までありがとう・・・。 長年Travis CI使ってきたので、GitHub Actionsによって潰される(のかどうなるのかわからないけど)、の可愛そう、という気持ちが若干あるけど、とはいえ、こういうのよくある話な気はするな…— Kenji Yoshida (@xuwei_k) 2020年10月7日 買収されて方針変わったのかなと感じるところもありますし、OSSプロジェクトが無料で使っていても会社としては辛いのではという気もするので今までの感謝の気持ち
GitHub Actionsを開発して公開するまで(Docker編) - Qiita
はじめに Github Actions便利ですよね．毎月2000分までタダで使えるので，個人プロジェクトはほぼこれでまかなえてしまいます．Docker，もしくはJavaScriptで開発できるので，バックエンドの方もフロントの方も触りやすそうです． すでに公式日本語ドキュメントがあるので，最新情報はこちらを確認してください． 個人的に手順全体の概要があったほうがわかりやすいと思い，この記事を書いています． action.ymlの役割とAction自体を検証するCIの作成方法は役立つと思います． その他の詳細部分も書きましたが，個別のAction実装作業には役立たないので読まなくても大丈夫だと思います． この記事の前提 Dockerを利用して開発する前提です．JavaScriptでの開発は扱いません． Dockerにある程度詳しいことを前提としています． 開発に至った背景 CI上でElast
Docker+Rails+HeadlessChromeでRSpecのSystem Testしてみた - Qiita
はじめに 今回はタイトルにある通りdockerを使用してrspecのSystem testを実行したので備忘録的に記事にしました。 こちらのrails+mysqlの環境にRSpec用の環境を加えた形になります。基本的にRSpecを追加する部分のみを記載します。 rails+mysqlの環境についてはこちらの記事をご覧ください。 Dockerを使用した既存のRailsプロジェクトの開発環境構築（Rails+Mysql） 構成としてはrailｓ＋MySQL＋test用のdb＋systemspec用に selenium/standalone-chrome-debugを用いた環境となります。 対象読者 既存のrailsプロジェクトの開発環境にdocker＋rspecを利用したいかた。 dockerはダウンロード済みとしています。 参考 こちらの記事を参考にさせていただいております。 Docker
【追記あり】Travis CIでMJITを有効にしたビルドマトリクスを作る - くりにっき
何番煎じか分からないけど自分用メモ tl;dr; 実行結果 2019/6/19 追記 tl;dr; .travis.yml に下記のようなものを書くだけ script: - RUBYOPT=$RSPEC_RUBYOPT bundle exec rspec matrix: include: - rvm: 2.6 env: RSPEC_RUBYOPT="--jit" - rvm: ruby-head env: RSPEC_RUBYOPT="--jit" 実行結果 https://travis-ci.org/sue445/rubicure/builds/473290010 ビルドスクリプト内で RUBYOPT="--jit" bundle exec rspec とかしてもいいんですが、それだとビルドがコケた時にJIT起因の問題なのかそうじゃないのかが分かりづらくなるのでこっちを推奨です。 あと、
Dependabotの設定ファイルを置くようにした - くりにっき
なにげなくDependabotを見てたらリポジトリに .dependabot/config.yml を置けることを気づいたので置いてみた https://dependabot.com/docs/config-file/ 設定ファイルを置くメリット いつも使ってる設定晒し 解説 default_assignees allowed_updates automerged_updates version_requirement_updates まとめ ちなみに .dependabot/config.yml をコミットしてると設定画面でこんな表示になります 設定ファイルを置くメリット 新しくリポジトリを作ってDependabotを導入する時にボタンをポチらずに済む 別リポジトリから設定ファイルをコピーしてくればいつもの設定が導入できる 設定をgitで履歴管理 いつも使ってる設定晒し Rubyだとこれ
CircleCIのYAMLを短く書けるRails Orbを作りました - メドピア開発者ブログ
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）だけをキャッ
GitHubの新機能「GitHub Actions」で試すCI/CD | さくらのナレッジ
GitHubが2019年11月、新機能「GitHub Actions」を正式に公開した。GitHub上のリポジトリやイシューに対するさまざまな操作をトリガーとしてあらかじめ定義しておいた処理を実行できる機能で、今まで外部サービスとの連携が必要だった自動テストや自動ビルドなどがGitHubだけで実現できるようになる。今回はこのGitHub Actionsについて、機能の概要や基本的な使い方などを紹介する。 GitHubだけでCI/CD的な機能を実現できる「GitHub Actions」 昨今では、ソフトウェア開発におけるさまざまな工程を自動化するような技術の開発や普及が進んでいる。その1つに、CI（Continuous Integration、継続的インテグレーション）やCD（Continuous Delivery、継続的デリバリー）と呼ばれるものがある。CIはソフトウェアのビルドやテストを
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を使ってる場合 ライブラリを作ってる場合
Jenkinsに代わるGo製OSS CIツールDrone
LINE株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。 LINEヤフー Tech Blog この記事はLINE Advent Calendar 2017の5日目の記事です。 はじめまして。LINEのIT支援室という部署で社内システムの開発・運用を担当しております、suzuki-shunsukeです。 DroneというCIツールについて書きたいと思います。初心者向けに公式ドキュメントの「Installation」と「Usage」をベースに自身の経験や考えを肉付けして、Droneとは何か？、Droneの構築方法、.drone.ymlの書き方について説明します。Droneの日本語情報はまだまだ少ないので参考になればと思います。 JenkinsよりもDroneを贔屓した部分が見られますが、あらかじめご了承ください。 Dron
Circle CI 2.0でparallel_testsを使ってお金をかけずに高速化する - patorashのブログ
CircleCI 2.0でだいぶテストが速くなったものの、1回のテストが20分くらいかかっているので、もっと速くしたいなぁと思っていました。お金を払えば並列化は簡単にできるのですが、CircleCIの並列化にも今のところ上限があり、1度のテストで16コンテナまでしか使えません（例え20コンテナ契約していたとしても）。しかし、CircleCIの1コンテナには、2CPU 4GBのメモリがあります（デフォルトでは）。 そこで目をつけたのが、gem parallel_testsです。 parallel_testsとは？ github.com parallel_testsは、マシンにあるCPUの数だけテストのプロセスを起動して並列実行するgemです。Hyper Threadingが有効な場合は、論理コア数で数えるので、CPU数*2のプロセスが起動することになります。以前はCIを使わずローカル環境でr
Travis CI Documentation
This documentation site is open source. The README in our Git repository explains how to contribute. The Google Chrome addon allows Travis CI builds to install Google Chrome at runtime. This addon supports both, Linux and macOS build environments. For Linux, you must be running on Ubuntu Xenial 16.04 or later build environments. Selecting a Chrome version # You can install the stable or the beta v
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Rails CI using Ruby master branch
GitHub - sj26/rspec_junit_formatter: RSpec results that your CI can read
GitHub - willnet/ci_logger: Logger for CI
Ruby on CI #ginzarails
<!-- "> '> --><title>
