これは、ASP.NET だけでなく、すべての開発に共通の問題です (もっと早く読んでおけばよかったと思います)。開発者の 1 人である私のチームは当然、リリース プロセス全体でBuildMasterを社内で使用しており、ほとんどのシナリオでは無料です。ツール内で、すべての標準 CI ビルドを実行して成果物を作成し、特定のアプリケーションまたは環境に応じて、内部または外部でホストされている 40 以上のサーバーのいずれかにこれらの成果物をデプロイする自動化プロセスをセットアップできます。 .
さまざまなテスト環境への展開について具体的に言及されたので、これはツールの基本的な側面です。アイデアは、既に配置されている環境ワークフロー (例: 統合 -> QA -> 生産) をモデル化し、本質的にソース管理から生産までビルドを促進することです。ほとんどの場合、アーティファクトを環境に展開する展開アクションを追加するだけで簡単ですが、それよりもはるかに複雑になる場合もあります。
また、構成ファイルの変更は、BuildMaster の別の組み込みコンポーネントである展開の一部であるとさりげなく言及しました。私たちが考えていたのは、ツール自体をすべての構成ファイルと展開の中心的なハブとして使用することでした。これにより、展開計画の単純な「構成ファイルの展開」アクションで最新の変更が自動的に適用されます。
このプロセスに関してあなたが言及しなかったことの 1 つは、データベースの展開の側面です。ほとんどの ASP.NET アプリケーションは関連付けられたデータベースを必要とします。それ以外の場合は、静的な HTML ファイルである可能性があります。展開ごとにデータベース スキーマを適切なデータベース バージョンに更新することが重要です。驚くことではありませんが、これを処理する BuildMaster 内のモジュールもあります。ツール自体に DDL-DML スクリプトを保存し、スクリプトを1 回だけ実行するという考え方です。環境ごとに、ビルドがそれらを介してデプロイされるときに、各環境のすべてのデータベースが最新であることを保証します。その他のスクリプト (ストアド プロシージャ、ビュー、トリガーなど) は基本的にコード ファイルであるため、ソース管理に属します。これらの DROP-CREATE-CONFIGURE タイプのスクリプトは、ほとんどの場合、単純な展開アクションで毎回実行できます。
ほとんどの開発者が考えていない配置パズルのもう 1 つのピースは、プロセスの自動化です。多くの開発者は、これらのプロセスを手動で実行するために、サインオフを実行したり、変更要求フォームに記入したりする必要があります。繰り返しますが、これはすべて BuildMaster 内の自動化されたワークフロー セットアップの一部として利用できます。すべての単体テストに合格しない限り QA 環境への昇格を許可しないブロッカーをセットアップするか、QA チームの誰かがビルドを承認し、問題追跡ツールのすべての問題が解決/クローズされない限り、ステージング環境への昇格をブロックすることができます。その特定のリリース。
答えから CC.NET を省略したことに気づきましたが、私たちのアプリケーションはすべて BuildMaster を介してビルドおよび展開されているため、不要になりましたが、ドロップ場所からアーティファクトを簡単にピックアップして、後の環境に展開することもできます.