3

現在、CI には CruiseControl (ruby バージョン) を使用しており、単体テストと統合テスト (主に rspec) を実行しています。

これは素晴らしいことです。機能上の問題やリグレッションに関するフィードバックがすぐに得られます (私はインスタントをおおよその意味で使用しています;-)。

コミットによってパフォーマンスの低下が発生したかどうかはわかりません。

テストでたとえば 5% のパフォーマンス低下が測定された場合、ビルドを RED にしたいと思います。もちろん、データベース クエリの応答不良、Ruby 関数またはコントローラーの応答に費やされた時間など、問題を指摘します。

継続的なパフォーマンス テストは、過去数年間少し議論されてきたトピックですが、(主に Java と .NET の世界を対象とした) いくつかのベンダーの製品を除けば、Rails 側についてはあまり見かけません。パフォーマンス、負荷、およびボリュームのテストは別の作業であり、通常はメジャー アップデートの前に行われますが、そうでなければ定期的な反復やリリース中に忘れられることがよくあります。そして、ライブ インスタンスを監視する NewRelic の素晴らしい機能と、わずかな幸運のおかげで、大きなトラブルを回避できました。

CI はアジャイル開発の実践に不可欠であり、ビルド中の継続的なパフォーマンス テストの欠如は、私たちのツールに残っている数少ない大きなギャップの 1 つと思われます。

役立つツールを示したり、自分でハッキングした可能性があることを経験したりできるいくつかの回答が欲しいです。注: 私たちは CC に慣れていませんし、他の製品 (商用製品であっても) をビルド サイクルに含めることを嫌うわけではありません。

4

1 に答える 1

1

すでにこれを見たと仮定すると: http://guides.rubyonrails.org/performance_testing.html

別の言い方をすれば、Jenkins ベースの CI フレームワークを通じて Grinder ベースのパフォーマンス テストを毎晩実行しています。すべてのビルドに対して実行されるわけではないことに注意してください。毎晩自動的に最新のビルドが取得されます (したがって、おそらく 4 つのビルドごとに実行されます)。さまざまな同時ユーザー レベルでテストを実行するには約 4 時間かかりますが、大幅に短縮できます。単一のユーザーレベルで実行した場合。Jenkins を介して実行されるため、メトリクスが悪い場合はエラーを返す (RED にする) ことができますが、まだそれを行っていません。

パフォーマンスの低下を本当に探しているだけなら、最新のコードで 1 つのテスト (関心のあるものを測定する) を実行し、ビルドからビルドへの応答時間の履歴を追跡することで解決するはずです。

于 2011-10-14T16:04:56.460 に答える