2

現在、4 人の開発者が Visual Studio 2012 で作業しており、ソース管理には TFS 2012 を使用しています。私たちが取り組んでいるプロジェクトは、レガシー、asp、vb6 com コンポーネントと新しい C# コードを組み合わせたマルチテナント Web アプリケーション (複数のデータベースを持つ単一ソース ディレクトリ) です。ソース管理とユーザー ストーリーとバグの管理に TFS を使用しています。私たちのサイトの仕組みにより、サーバー上でのみローカルで実行またはデバッグすることはできません。ソース管理は現在、開発者ごとに個別のブランチでセットアップされており、作業ディレクトリは、IIS で Web サイトがポイントされている開発サーバー上の共有ネットワーク パスにマップされています。Dev01-Dev05 など。開発者は、ブランチでプロジェクトに取り組み、開発 Web サイトを使用してテストし、変更を自分のブランチにチェックインして、トランクにマージします。

非常に長い説明ですが、基本的に各開発者にはブランチとサイトがあり、それらは独自のサイトを持つトランクにマージされます。

ステージング サーバーをデプロイするには:

  1. サーバー上のbatファイルを介してトランクのWebサイトをコンパイルします
  2. 特定のステータスの特定の WorkItem に関連付けられた変更セットについて TFS にクエリを実行するために作成した Windows アプリを実行し、それらの変更セットのすべてのファイルを公開フォルダーから展開フォルダーにコピーします。
  3. サーバー上で別のバッチ ファイルを実行し、RedGate の Deployment Manager を使用してそれらの新しいファイルからパッケージを作成します。
  4. 私たちのネットワークの DM サイトにアクセスして、そのリリースを作成してデプロイします (コマンド ライン ツールをこのために機能させることができなかったので、手動で行う必要があります)。
  5. リリースをサポートするために、各データベース (10 程度の顧客データベース) のチケット番号と一致するフォルダに保存されている SQL スクリプトを実行します。

TFS の自動ビルド機能を使用してみましたが、Web サイトを正しくビルドすることはできませんでした。クルーズコントロールをいじってみましたが、ほとんど成功しませんでした。これを行うためにスカンク作品の寄せ集めのプロジェクトを使用すると、非常に時間がかかり、せいぜい信頼性が低くなります。

私の完璧なシナリオは次のとおりです。

  1. ゲート付きチェックイン、開発者がトランクにマージするたびにビルド/公開を試み、ビルドが失敗した場合は拒否して開発者に通知します。
  2. 一日の終わりに、特定のステータスの TFS アイテムを収集し、それらに関連付けられたファイルをステージング サイトに展開します
  3. これらの TFS アイテムの SQL スクリプトを、ステージング内のすべての顧客データベースにデプロイします
  4. 最終的に* 自動回帰 UI テストを実行し、新しい WorkItem を作成するか、失敗した場合は開発者に電子メールを送信します
  5. TFS ワークアイテムを新しい状態に更新して、QA/顧客がアイテムをステージング環境でテストする準備ができていることを認識できるようにします
  6. 正常に展開されたアイテムのレポートを送信する

ステージング、そして最終的には本番環境へのリリースの準備と展開に何時間も費やさないようにするには、どうすればここにたどり着くことができるでしょうか? 潜在的な解決策に対してかなりオープンです。変更するのが難しいものは、使用しているソース管理であり、実際にはサブバージョンなどに切り替えることができないため、TFS にかなりこだわっています。

ありがとう

4

2 に答える 2

2

戻って、TFS を使用して Web ソリューションをビルド/公開しようとし始めました。ビルドを正常に完了することができました。msbuild 引数 /p:DeployOnBuild=True を追加し、msbuild プラットフォームを x86 に設定すると、うまくいくようです。次に、 https://github.com/red-gate/deployment-manager-tfsを見つけました。 これは、redgate ツールを使用してパッケージとデプロイを行うためのビルド プロセス テンプレートを提供します。少し遊んだ後、ようやくビルドを作成してパッケージ化し、ステージング環境にデプロイすることができました。

次に、いくつかのカスタム スクリプトを実行して展開する正しいアイテムのみを収集するようにテンプレートを変更し、すべての sql ファイルを展開して、完了後にワークアイテムを適切なステータスに設定します。

于 2014-02-17T14:50:22.327 に答える
1

あなたのプロセスの本当に詳細な説明。共有してくれてありがとう！

TFS を設定して、単一のブランチでチェックインをゲートすることができると思います。これにより、トランクに設定できれば、マージが正常に構築されることが保証されます。それが機能するか、カスタムビルドジョブを取得できる場合、msbuild がトリガーされる可能性があります。

これを機能させることができれば、そのトランク コードをアーティファクトとして使用して、Deployment Manager に送信できます。これにより、TFS 変更セットを介して展開用のファイルをアセンブルする必要がなくなります。トランクは常に構築できると確信できるからです。

Deployment Manager を使用して、アプリケーションだけでなくソース管理からデータベースをデプロイしていますか?

これは、プロセスをさらに自動化する方法になる可能性があります。 SQL ソース管理とSQL CIを使用すると、データベースの構造をソース管理し、チェックインのたびにデータベースを最新の状態に保ち、データベースの単体テストを実行できます。また、Deployment Manager 用のデータベース パッケージも作成されるため、アプリケーションとデータベースの両方を含むリリースをデプロイできます。

手順 4 で使用しているコマンドを送信して、Deployment Manager を使用してリリースをデプロイする場合は、私がお手伝いします。私が使用するコマンドは次のとおりです。

DeploymentManager.exe --create-release --server=http://localhost:81 --project="Project Name" --apiKey=XXXXXXXXXXX--version=1.1
DeploymentManager.exe --deploy-release --server=http://localhost:81 --project="Project Name" --apiKey=XXXXXXXXXXX--version=1.1 --deployto=CI-Environment-Name

これにより、そのプロジェクトで利用可能な最新のパッケージを使用して、リリース バージョン 1.1 が作成されます。オプションで、リリースを作成するときに使用するパッケージを指定できます

--packageversion=<package name>=<version>
--packageversion="application=1.5
于 2014-02-11T10:06:28.030 に答える