[B! ci] iga_kのブックマーク

Capybaraとreg-cliを使ってお手軽にビジュアルリグレッションテストを行える環境を整備しました📸 - メドピア開発者ブログ

こんにちは、MedPeerの開発を担当している森田です。今回は私が開発に参画しているMedPeerに元々E2Eテストで利用していたCapybaraと、reg-cliを利用してビジュアルリグレッションテスト(以下VRT)を行える環境を整備したので、それについてご紹介させていただきます。なぜ、VRTを導入するのか？ VRTの要件と技術選定実際に構築したVRT基盤の概要 VRT基盤の具体的な話 System Spec内でスクリーンショットを取得する reg-cliでスクリーンショットの差分をチェックする分かりやすいコマンドでVRTを実行できるようにする CIで差分をチェックする OS間での利用フォントによる違いを吸収するおわりに参考にさせて頂いた資料なぜ、VRTを導入するのか？ MedPeerでは元々System Specを活用したE2Eテストを利用してフロントエンドを含めて品質を

iga_k 2024/07/13

画像差分テスト。フォントを整えるのなるほど。

リンク

Rails CI using Ruby master branch

iga_k 2024/02/01

rails
ci

リンク

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を利用しており、またファイル

iga_k 2023/10/31

r7kamuraさんの知見。勉強になる。

リンク

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ブラ

iga_k 2023/08/04

知見！

リンク

GitHub - sj26/rspec_junit_formatter: RSpec results that your CI can read

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

iga_k 2022/12/22

各種CIが読める形式のRSpecレポートを出力する rspec_junit_formatter gem

リンク

Railsのテスト実行時間を1/3まで短縮した話 (Rspec + CircleCI)

背景CIのビルド実行時間の長さは度々社内で問題になっており、「CIに時間かかるので業務効率が下がる」といった話が現場でも増加していました。業務時間中は複数 Pull Request のビルドが発生するので、「CI順番待ちで次の自分のビルドは1時間後」のような現象は日常茶飯事でした。おまけに「頻度は低いがランダムで失敗するテスト」といった false positive なテストの存在も、開発現場のフラストレーションは溜まる原因になっていました。単純に CI を再ビルドすれば直るのか、自分が追加した実装/rspecに問題があるのか一件判断がつかないケースだと、開発担当者も一旦 CI 上で再ビルドを行い、同じ箇所でコケるのか確認することになるので、これがさらなる CI 渋滞を引き起こしていました。こうした背景もあり、丁度プロジェクトの隙間で工数もあったので「CI 改善をしっかり工数確保して

iga_k 2022/12/01

CircleCIでの実行チューニングの知見

リンク

失敗したテストのログだけを出力するぞ - おもしろwebサービス開発日記

表題の通りのことができるgem、CiLoggerが便利ですよという話です。私達は大量のテストをCI上で実行しています。テスト結果を見れば失敗理由が自明なものもありますが、E2Eテストなどでよく起きる﹁たまに失敗するテスト﹂の調査はログやスクリーンショットなど、可能な限りの情報を集めないと根本原因がつかめないことが多いです。そんなときに、特に考えずRailsデフォルトの設定(config.log_level #=> :debug)のままにしておくと、膨大なログの中から該当するテストに関連する行を探し当てる作業が必要になります。これは事前の準備なしではほぼ不可能です。事前の準備として簡単に思いつく方法は、テスト前後で﹁どのテストが開始/終了したか﹂をログに出力することです。 config.around do |example| Rails.logger.debug("start exam

iga_k 2022/08/24

なるほどー！

リンク

GitHub - willnet/ci_logger: Logger for CI

iga_k 2022/05/11

「失敗したテストのログだけを出力」

rspec
ci

リンク

今までありがとうTravis CI、さよならTravis CI - xuwei-k's blog

しっかり調査してないですが、こういったCIサービスがほぼ存在しない時期にほぼほぼ最初に登場して、一時期明らかにデファクトスタンダードだったと思うので、昔からOSS活動している人ほど、とても多く利用してお世話になっていたと思うので、そういう人であればあるほど、この状況は、怒りではなく、悲しいというか残念というか、辛いと思うんですよね・・・。今までありがとう・・・。長年Travis CI使ってきたので、GitHub Actionsによって潰される(のかどうなるのかわからないけど)、の可愛そう、という気持ちが若干あるけど、とはいえ、こういうのよくある話な気はするな…— Kenji Yoshida (@xuwei_k) 2020年10月7日買収されて方針変わったのかなと感じるところもありますし、OSSプロジェクトが無料で使っていても会社としては辛いのではという気もするので今までの感謝の気持ち

iga_k 2020/11/05

ci
oss

リンク

Ruby on CI #ginzarails

銀座Rails#24の発表資料です https://ginza-rails.connpass.com/event/181807/

iga_k 2020/08/28

sueさんの銀座rails CI知見資料

ci

リンク

<title>

iga_k 2020/07/08

CI/CDの説明

ci

リンク

GitHub Actionsを開発して公開するまで(Docker編) - Qiita

はじめに Github Actions便利ですよね．毎月2000分までタダで使えるので，個人プロジェクトはほぼこれでまかなえてしまいます．Docker，もしくはJavaScriptで開発できるので，バックエンドの方もフロントの方も触りやすそうです．すでに公式日本語ドキュメントがあるので，最新情報はこちらを確認してください．個人的に手順全体の概要があったほうがわかりやすいと思い，この記事を書いています． action.ymlの役割とAction自体を検証するCIの作成方法は役立つと思います．その他の詳細部分も書きましたが，個別のAction実装作業には役立たないので読まなくても大丈夫だと思います．この記事の前提 Dockerを利用して開発する前提です．JavaScriptでの開発は扱いません． Dockerにある程度詳しいことを前提としています．開発に至った背景CI上でElast

iga_k 2020/05/22

plugin入り

リンク

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

iga_k 2020/04/23

リンク

【追記あり】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起因の問題なのかそうじゃないのかが分かりづらくなるのでこっちを推奨です。あと、

iga_k 2020/04/23

MJIT有効にする方法

リンク

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だとこれ

iga_k 2020/02/25

CIチョットデキルsueさんの知見、めっちゃ便利やん〜〜〜。

リンク

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︶だけをキャッ

iga_k 2020/02/14

キャッシュいい感じにしてくれるの嬉しい

リンク

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はソフトウェアのビルドやテストを

iga_k 2020/02/05

便利そうまとめ

リンク

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を使ってる場合ライブラリを作ってる場合

iga_k 2020/01/09

ci
ruby

リンク

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

iga_k 2019/10/04

Jenkinsのコンテナ版

リンク

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

iga_k 2018/10/15

リンク

はてなブックマーク

タグ

関連タグで絞り込む (18)

ciに関するiga_kのブックマーク (24)

お知らせ

今週のはてなブックマーク数ランキング（2024年7月第2週）

はてなブックマーク透明性レポート（2024年 2月-2024年4月）

今週のはてなブックマーク数ランキング（2024年7月第1週）

公式Twitter

キーボードショートカット一覧

はてなブックマーク

公式Twitter

はてなのサービス