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 環境でのユニットテストの実行時間を2倍速くした話 (Jest + Mongo DB + Circle CI) - ミツモア Tech blog
こんにちは。ミツモアでテックリードしております白柳（@yanaemon) です。 ミツモアのプロダクトは TypeScript で、クライアントサイドの React とサーバサイドの Node.js で書かれており、ユニットテストは Jest + Mongo DB + Circle CI を利用しています。 しかし、プロダクトが大きくなるにつれて、全ユニットテストを実行するのに 10 分程度かかり、開発効率が悪くなっていました。 今回は、それを 2 倍以上速度改善した取り組みについて紹介します。 実施したこと いきなりですが、具体的に実施したことと、改善結果になります。 実施内容 改善結果 1. ファイル分割をし、並列度をあげる これ単体では速度改善は期待できない 2. テスト対象を修正されたファイルのみにする x1 ~ x10 速度 UP ※ただし最終的にはやめました 3. DB 生成な
メルカリShops の CI/CD と Pull Request 環境 | メルカリエンジニアリング
こんにちは！ソウゾウの Software Engineer の @dragon3 です。 連載：「メルカリShops」プレオープンまでの開発の裏側の８日目を担当させていただきます。 この記事では、メルカリShops 開発において、日々バリバリに利用されている CI/CD 環境と Pull Request 毎のデプロイ環境について紹介します。 CI/CD 環境 メルカリShops では、CI/CD （テスト・ビルド・デプロイ）やその他自動化のために GitHub Actions を使っており、ほとんどのワークフロー・ジョブを Self-hosted runners で実行しています。 Self-hosted runners は、専用の VPC ネットワーク 内の GCE インスタンス上で動かしており、Managed Instance Group 等を使い、そのプロビジョニングや起動・停止等は
『FFVII リメイク』は自動デバッグで、休日、夜間問わず、毎日数百回も通しプレイ中。ゲームのバグを自動で検知するシステムを開発【CEDEC 2020】 | ゲーム・エンタメ最新情報のファミ通.com
本記事では、1日目におこなわれた『ファイナルファンタジーVII リメイク』（以下、『FFVII リメイク』）のデバッグに関するセッション“"FINAL FANTASY VII REMAKE"における自動QAシステムの構築と運用”をリポート。 本セッションで語られたのは自動QAシステムについて。まずQAとは、Quality Assuranceの略称で、日本語で言えば、品質保証。ゲーム開発においては、ゲームが正しく動作しているか、バグが発生しないか、検証する仕事・部門・チームのことを指す。ゲームファンにとっては、デバッグと言ったほうが伝わりやすいかもしれない。つまり、自動QAシステムとは、自動でデバッグをおこなうシステムということだ。 セッションには、スクウェア・エニックスのAIエンジニアを務める太田健一郎氏が登壇した。 ゲームに最適化した自動QAシステムを目指して ゲームというのは、そもそも
CircleCIをPerformance Planに移行した - patorashのブログ
会社で使っているCircleCIをPerformance Planに移行しました。 きっかけは以下のブログを読んだことでした。 moneyforward.com 弊社でのCIの課題 弊社ではMoney Forwardさんほどの並列数ではないんですが、16コンテナ契約していて、大きいプロジェクトでは8並列、他のプロジェクトでは4並列を基本として、テストしていました。 大きいプロジェクトを16コンテナではなく8コンテナにしたのは、 大きなプロジェクトであってもテストが並列で2つは走るようにしたかった 大きなプロジェクトにコンテナを占有されてしまわないようにするため です。 昔は早くテストを終わらせたいということで16コンテナ全てを割り当てていたのですが、逆にテスト詰まり(CI待ちがどんどん増えていくこと)が発生してしまい、他のプロジェクトのテストが実行されるのが数時間後になることもありましたが
CircleCIのPerformance Planが控え目に言って最高という話 | Money Forward Engineers' Blog
こんにちは。18新卒でサービスインフラチームの小笠原 (@0gajun) です。 今日はCircleCIのPerformance Planを用いて、CI環境の改善を行った話をします。 （決してCircleCIの回し者ではありません :wink: ） Summary 今までJenkinsをCI環境として用いており、様々な問題を抱えていた CI環境を改善するためにCircleCIに移行した CircleCIにはPerformance Planという従量課金プランが存在する コンテナの並列実行数に制限がなく、実行時間ベースでの従量課金 ただし、まだ Early Accessの段階。 JenkinsからCircleCIに移行することで、次のメリットが得られた CI時間の短縮 CIジョブがキューイングされる問題からの開放 CI環境のメンテナンスコスト削減 CIコストの削減 CircleCIのPerf
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Ruby on CI #ginzarails