いくつかの Nant ビルド スクリプト内で統合テストを実行するためのさまざまな戦略を検討してきました。通常、多くの異なるスクリプトが、個別のターゲットを持つ 1 つのモノリシック ビルドにチェーンされます。ステージング (ビルドのようにステージング バージョンをビルドする)、ビルド (ビルドするだけ)、統合 (ビルドして統合テストを実行する)。これはかなりうまく機能し、ビルド ターゲットは統合ターゲットとして実行するのに約 3 分の 1 の時間を要します。
一方、統合ターゲットには時間がかかるため、あまり頻繁に実行したくありません。理想的には、デプロイの準備が整う直前です。これは合理的な戦略のように思えますか? IOW、私はそれを正しくやっていますか？
最終的にこのプロジェクトを継続的インテグレーションに移行する計画です。私は継続的インテグレーション全体に慣れていませんが、「ビルドを壊す」という概念を理解していると思うので、それを最大限に活用するために、どのような良い実践をすればよいのでしょうか?
このテーマに関する優れた情報源も評価されます。ありがとう！
はい、あなたは正しい軌道に乗っています。ここで行う必要があるのは、nant ターゲットを自動化されたプロセスに接続することです。CI ツールとして Team City または Cruise Control を使用することをお勧めします。自動化されたサーバーのセットアップが完了したら、チェックインのたびにビルドと単体テストを実行できます (継続的インテグレーション)。通常、統合テストは実行に時間がかかるため、夜間または週末に実行できます。統合テストが成功すると、QA または他のサーバーにデプロイするジョブを作成できます。
99% 到達したようですね。私のアドバイスは、ただ飛び込んでやり始めることです。自分のやり方が正しいかどうかを考えるよりも、実際に思い切って実行することで、より多くのことを学ぶことができます。
私の会社では現在 CruiseControl を使用していますが、個人的には素晴らしいと思います。
この関連スレッドを参照してくださいWhat is a good CI build process?
あなたは正しい軌道に乗っています。まともな CI ツールを使用している場合は、各セットアップを、チェーンの次のステップをトリガーする個別のプロジェクトとして設定できるはずです...つまり、成功したビルドは、統合をトリガーする展開をトリガーするテストをトリガーします。
このようにして、最も簡単な「ブレーク」は、いわばラインを停止します。
CruiseControl を使用して、ビルド、単体テスト、構成と展開、統合テストとコード カバレッジの実行、受け入れテストの実行、およびリリース用のパッケージ化を行います。これは、8 つほどの Web サービスと 12 ほどのデータベースからなるシステムであり、すべてが相互に関連する構成と展開の依存関係を持ち、構成が異なる複数の環境 (単一のボックスから各コンポーネントの冗長なボックスまで) にまたがっています。