こんにちは。スタディサプリ ENGLISH Web フロントチームの kazuma1989 です。 先日、私たちのチームは開発フローに Visual Regression Testing を導入しました。Visual Regression Testing は、フレームワークを紹介する記事は見つかるものの、具体的な知見があまり広まっていない印象なので、具体的な設定値や選定理由も含め紹介してみます。 React による Web フロント開発を前提にしていますが、Visual Regression Testing のコア部分は「画像の比較」であるため、他のプラットフォーム開発でも参考になればと思います。 Visual Regression Testing (VRT) とは Visual Regression Testing （日本語で 画像回帰テスト、以下 VRT）は、画像の差分を検出する、スナ
背景CIのビルド実行時間の長さは度々社内で問題になっており、「CIに時間かかるので業務効率が下がる」といった話が現場でも増加していました。 業務時間中は複数 Pull Request のビルドが発生するので、「CI順番待ちで次の自分のビルドは1時間後」のような現象は日常茶飯事でした。 おまけに「頻度は低いがランダムで失敗するテスト」といった false positive なテストの存在も、開発現場のフラストレーションは溜まる原因になっていました。単純に CI を再ビルドすれば直るのか、自分が追加した実装/rspecに問題があるのか一件判断がつかないケースだと、開発担当者も一旦 CI 上で再ビルドを行い、同じ箇所でコケるのか確認することになるので、これがさらなる CI 渋滞を引き起こしていました。 こうした背景もあり、丁度プロジェクトの隙間で工数もあったので「CI 改善をしっかり工数確保して
こんにちは、IESHILでエンジニアをしている須貝です。 今回は先月ローンチしたIESHIL CONNECT（イエシルコネクト）の運用で、CircleCI 2.0を使ってbundle updateを自動で実行するようにした話をします。CircleCI 1.0ではなく2.0というのがちょっとしたポイントです。 ところで、みなさんCircleCI 2.0を使っていますか？ 2.0では純粋なDockerベースになっていてローカルでも実行可能、より柔軟に設定を記述できる、とにかく速いなど1.0と比較すると大幅に進化しています。どんどん使っていきましょう。 やろうとした背景 そもそも何でこれをやろうとしたの？という話なんですが、 IESHIL CONNECTはIESHILとは別に新規開発したRailsアプリです。せっかくの新規開発ですから、IESHIL本体の開発では手を回せていないことをやろう、とい
日々、bundle updateしてますか！ circleci-bundle-updateとcircleci-bundle-update-prを使って、bundle updateの Pull Requestを自動化する手順をまとめてみます。作者の記事を読めばいいっちゃいいんですが、地味に抜けていた手順と各ステップは何のために必要かを整理してみました。 このgemは、Pull Requestに各gemの差分リンクを貼ってくれるのが便利だな！って思って採用してます。素敵なgemをありがとうございます。 github.com github.com ステップは CircleCI経由でbotからgithubにpush出来るようにしておく CircleCI経由でbotからgithubにPR作れるようにしておく 外部からCircleCIへbuild指示できるようにする 外部からcronでCircleCI
入社前に1周終わらせてきたということで、少しやることをプラスして2周目に入ってもらっている。Railsチュートリアルの周回まわりの効能については、akiinyo のエントリを参照。 今回2周目ということで、本編プラスαとして伝えていることの大枠。 Travis CI や CircleCI などの CI サービスと連携する テストコードを RSpec で書いてみる GitHub への PR を出して CI をパスするようにする 新卒2人がそれぞれで進めているので、一方がレビューしてマージする この過程で開発環境を整備しているものを dotfiles で GitHub 管理する Idobata にフィードを流すなどやってみても良さそう 進行具合をみて工夫できそうな点があれば、一緒に考えて見直しを入れて行きたい。
CircleCI上でCapybara, Poltergeist, PhantomJSを利用したテストがMouseEventFailed失敗する問題を解消した。 以下のような構成のRailsアプリをCircleCI上でビルドすると、Capybara::Poltergeist::MouseEventFailedという例外が発生してテストが失敗するケースがあった。 Rails 4.2.x RSpec 3.4.x Capybara 2.6.2 Poltergeist 1.9.0 PhantomJS 2.1.1 (CircleCIのプロジェクト設定でUbuntu 14.04 (Trusty) containerを利用するように設定しておく必要あり) この時、失敗の原因となっているテストコードは、 click_link '日本語のラベル' のようなもの。 調査のためにCircleCIにSSHで接続し、
#概要 Slack / Hubot / GitHub / CircleCI などをつかってChatOpsにチーム開発できるフローをつくったので、ChatOpsによるデプロイ方法を中心にその方法をまとめてみます。 ChatOpsの主役であるチャットアプリには今回Slackを使いました。 HipChatでも同じように出来ますが、Slackの方がUIが優れていており、外部サービスとの連携も洗練されていたのでこちらを選択しました。 #ChatOpsな環境の概要 SlackとHubot（PaaSであるheroku上にデプロイ）を連携させる SlackからHubot経由でGitHubにプルリクエストをつくる GitHub上の変更を監視し、CircleCIでテストを実施 デプロイ用のブランチに変更があった場合（GitHubのWEBコンソールでデプロイ用ブランチへのプルリクエストをマージした場合）、Cir
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
