NAnt と DB 統合テスト、そして最終的には継続的インテグレーション

Question

私は、Nant ビルド スクリプト内で統合テストを実行するためのさまざまな戦略を検討してきました。通常、多数の異なるスクリプトが、個別のターゲットを持つ 1 つのモノリシック ビルドにチェーンされています。ステージング (ビルドなどのステージング バージョンをビルドする)、ビルド (ビルドするだけ)、統合 (ビルドして統合テストを実行する)。これはかなりうまく機能し、ビルド ターゲットの実行時間は統合ターゲットの約 3 分の 1 で、それほど長い時間ではないので、頻繁に実行することに抵抗がありません。

一方、統合ターゲットには十分な時間がかかるため、あまり頻繁には実行したくありません。理想的には、デプロイの準備が整う直前に実行します。これは合理的な戦略のように思えますか?ああ、私は正しくやっていますか？

最終的にはこのプロジェクトを継続的インテグレーションに移行する計画です。私は継続的インテグレーション全体については初めてですが、「ビルドのブレーク」という概念は理解しているつもりなので、それを最大限に活用するためにどのような良いプラクティスを採用すればよいでしょうか?

このテーマに関する優れた情報源もあれば、同様に感謝いたします。ありがとう！

Answer 1

はい、あなたは正しい道を進んでいます。ここで行う必要があるのは、nant ターゲットを自動プロセスに接続することです。Team City または Cruise Control を CI ツールとして使用することをお勧めします。自動化されたサーバーのセットアップが完了したら、チェックインのたびにビルド テストと単体テストを実行できます (継続的インテグレーション)。統合テストは通常​​、実行に時間がかかるため、夜間や週末に実行できます。統合テストが成功すると、QA または他のサーバーにデプロイするジョブを作成できます。

Answer 2

あなたはそこにいる道の99％のようです。私のアドバイスは、ただ飛び込んでそれを始めることです。実際に思い切ってそれを行うことにより、あなたがそれを正しく行っているかどうかを考えるよりも多くを学ぶことができます。

現在、私の会社はCruiseControlを使用していますが、個人的には素晴らしいと思います。

Answer 3

この関連スレッドを参照優れたCIビルドプロセスとは？

あなたは正しい軌道に乗っています。適切なCIツールを使用している場合は、チェーンの次のステップをトリガーする個別のプロジェクトとして各セットアップを設定できる必要があります...つまり、成功などのビルドは、統合などをトリガーするデプロイメントをトリガーするテストをトリガーします

このようにして、あなたの最も「休憩」することができますいわば行を停止します。

CruiseControlを使用して、ビルド、単体テスト、構成と展開、統合テストとコードカバレッジの実行、受け入れテストの実行、およびリリース用のパッケージ化を行います。これは、8個程度のWebサービスと12個程度のデータベースで構成され、すべて異なる構成（コンポーネントごとに単一のボックスから冗長ボックスまで）の複数の環境にまたがる構成とデプロイメントの依存関係があります