Windows Azure ウェブサイト (または IIS) への継続的デリバリー

構成変換

デプロイの間に通常起こる必要があることの 1 つは構成に変更を加えることです。 データベース接続文字列を変更したり、ASP.NET 設定を変更して YSOD などを表示したりしなくなりました。 これらのことをハードコードしたり、サーバーのホスト名に基づいて大きな if-else ステートメントを書いて構成を把握したりしないでください。 代わりに、構成変換のようなものを使用してください。

構成変換は、使用されているビルド構成に基づいて Web.config への「変換」を記述するファイルです。 Release 構成をビルドしますか？ その場合、 Web.config は Web.Release.config に記述されたルールで更新されます。 Release ビルドを行うときに、構成から debug 属性を除去してみましょう：

Visual Studio で作成された典型的な ASP.NET アプリケーションは Debug と Release ビルドのための変換を含みますが、それらは（ビルド | 構成マネージャーメニューを通して）新しいビルド設定を作成しそして次にコンテキストメニュー 構成変換の追加を使用することによって追加することができます。

このチュートリアルでは、Development と Production という 2 つの新しい構成を作成し、さらに 2 つの新しい構成変換（Web.Development.config と Web.Production.config ）を生成しました。

構成変換をテストするには、コンテキストメニュー 変換のプレビュー を使用できます。これにより、生成される構成ファイルがどのようになるかを正確に確認できます。 以下は、 Web.Release.config 変換を実行した結果です：

これを使用して、変更したい設定を仮想的に変更または追加できます。 接続文字列、ファイルパス、アプリ設定、診断構成など。 config トランスフォームで何ができるかについてのドキュメント(英語)がもう少しあります。

WebDeploy

いくつかのバージョンでは、Visual Studio には、ASP.NET アプリケーション用のいわゆる「Web パッケージ」を作成するオプションがあり、これにはアプリケーションの実行に必要なすべてのファイルが含まれています。 ページ、イメージ、CSS、JavaScript、アプリケーションバイナリは、このようなパッケージでエクスポートできます。 データベースや IIS 設定を含めることも可能です。

これらのデプロイパッケージは、さまざまなプロトコルを使用してパッケージをサーバーにアップロードし、前に説明した構成変換を適用できるツールである WebDeploy と一緒に使用できます。

しかし、デプロイする前に、まずデプロイパッケージを作成する方法を見てみましょう。 そしてパッケージのフォーマットについて学ぶために、まず最初に msbuild を呼び出して手動でこれを行いましょう。

デプロイパッケージを手動で作成する

デプロイパッケージは、プロジェクトで Package ビルドターゲットを実行することで作成でき、msbuild を使用すると簡単に実行できます：

msbuild AcmeCompany.Portal.csproj /T:Package /P:Configuration=Release

プロジェクトがコンパイルされ、デプロイパッケージを含む新しいディレクトリが作成されます。 さらに !

ZIP ファイルにはアプリケーションが含まれ、その他のファイルはターゲットマシンへのデプロイを支援するファイルです。 注目すべきファイルは AcmeCompany.Portal.SetParameters.xml です。 これには構成変換の結果が含まれますが、これらの値をオーバーライドできます。 なぜでしょうか？ つまり、デプロイパッケージをビルドする人が接続文字列を知らない場合があるからです。 管理者だけが知っているとしたらどうでしょうか？ その担当者は、このファイルを通じて、本番用の正解となる最終的な接続文字列で設定をオーバーライドできます。

AcmeCompany.Portal.deploy.cmd バッチファイルを実行してターゲット環境にデプロイすることはできますが、これはどのように機能しますか？

WebDeploy では、デプロイパッケージをリモートサーバーに転送して構成を更新するために、複数のメソッドを使用できます。 これは WebDeploy (HTTPS ベースのプロトコル)、FTP、またはファイル共有を使用して実行できます。 最初のオプションでは、 ターゲット IIS サーバーで追加ツールを有効化する必要があります。 これには十分な理由があります: WebDeploy のサーバー側ツールは、サイト間で実際の同期を行い、サーバーから冗長なコンテンツを削除します。 FTP またはファイル共有の場合、追加のツールは必要ありません。

このチュートリアルの残りでは、WebDeploy を使用した Windows Azure ウェブサイトへのデプロイを扱います。これは IIS での動作と同じです。

ステップ 1: Visual Studio でデプロイパッケージ / WebDeploy を構成する

前のステップでは、デプロイパッケージを手動で作成したため、WebDeploy も手動で呼び出す必要がありました。 ただし、もっと簡単な方法があります: Visual Studio からデプロイパッケージと WebDeploy を一度に構成する方法です。

デプロイする Web アプリケーションから、プロジェクトノードのコンテキストメニューを使用して 公開をクリックします。 これにより、デプロイに関連した設定を行えるダイアログが開きます。 ステージング用と本番用など、複数のデプロイプロファイルを作成することもできます。

最初のステップでは、送信先サーバーの詳細を指定する必要があります。 これは通常、WebDeploy ホストへの HTTPS エンドポイント（またはこのオプションが選択されている場合は FTP またはファイル共有の詳細）です。 すべての詳細を入力したら、接続を検証して機能するかどうかを確認できます。

パスワードを指定する必要がありますか？ いいえ ! 開発者がそれを知らない場合は、資格情報を空白のままにすることができます。 開発者がそれを知らない場合、資格情報は空白のままにできます。後で TeamCity からデプロイするときにユーザー名とパスワードを指定します。

次のステップでは、デプロイに関する詳細をいくつか指定できます。デプロイパッケージに含まれていないファイルをターゲットサーバーから削除する必要がありますか？ アプリケーションはプリコンパイル済みにする必要がありますか？ データベース接続文字列をオーバーライドする必要があるでしょうか？ また、Entity Framework Code First を使用している場合、マイグレーションを実行する必要があるでしょうか？

このステップの後でウィザードを閉じて、作成した発行設定をプロジェクトのファイルに保存できます。

これは単なる XML ファイルであり、必要に応じて編集できます。 そして実際に私達は私達の生活を後でさらに楽にするために、すべきです。 XML ファイルを開き、 <デスクトップビルドパッケージの場所> 要素を見つけます。 コマンドラインから WebDeploy のパッケージ化ステップを実行する場合 (TeamCity が実質的に行います)、この場所は見つかりません。 これを解決するには、要素値を変更し、パスの先頭に _$(SolutionDir)_ を付けます。 これは、この要素がどのように見えるかの例です。

ファイルを保存し、TeamCity でデプロイを実行するときに使用できるように、ソース管理に追加されていることを確認してください。

ステップ 2: TeamCity で継続的インテグレーションビルドを設定する

プロジェクトに継続的インテグレーション (CI) ビルドを導入し、VCS チェックインごとにこれをトリガーできるようにしたいと考えています。 この CI ビルドにより、プロジェクトのビルドステータスと健全性に関する即時のフィードバックが得られます。

TeamCity では、VCS URL に基づいてプロジェクトを作成できます。 git、Mercurial、Subversion、... リポジトリへの URL を入力するだけです。

このリポジトリは分析され、ビルドステップを検出するためにスキャンされます。 この場合、TeamCity は Visual Studio 2013 のビルドステップを検出しました。これはビルド構成にすぐ追加できます：

提案されたビルドステップを追加すると、実行時に動作するビルドになります。 アーティファクトパス、バージョン番号などを指定できます。 ただし、不足しているものがあります！ WebDeploy デプロイパッケージがどこにも見当たりません。 その理由は、 Rebuild ターゲットをビルドしているためです。このターゲットは、パッケージ化せずにプロジェクトを単にリビルドします。 これを解決するには、ビルドステップに追加のコマンドラインパラメーターを追加できます：

これらのパラメーターが何をするのかです:

• /p:DeployOnBuild=True — WebDeploy のパッケージ化を引き起こす

• /p:PublishProfile="Development" — 梱包時に使用するデプロイプロファイルを指定します

• /p:ProfileTransformWebConfigEnabled=False — これを詳細に議論しましょう !

ここでビルドを再度実行すると (artifacts\webdeploy\Development => Webdeploy をアーティファクトパスとして指定しています。これは先ほど公開プロファイルで構成したパスです)、アーティファクトとして公開された見慣れた一連のファイルが表示されます：

それでは、実際のデプロイも設定できるかどうか見てみましょう。

ステップ 3: TeamCity でデプロイを設定する

デプロイに使用する戦略は 使い方に記載されています。 デプロイしたいターゲット環境ごとに新しいビルド構成を作成します。 これらの新しいビルド構成は次のようになります。

• ビルドを実行する

• デプロイを実行する

実現したいのは、このようなわかりやすいウォーターフォールです。ビルドを CI から開発、ステージング、本番へ、または CI と本番の間にある任意の環境へ昇格できます。

TeamCity 管理から CI ビルド構成をコピーし、別のお名前を付けます。たとえば Windows Azure ウェブサイトへのデプロイ \- 開発などです。 次に、ビルド構成にいくつか変更を加えます。

ビルドの依存関係を指定することから始めましょう。 ビルド構成の 依存関係で、CI ビルドに新しいスナップショット依存関係を追加します。 これにより、デプロイは、一致する CI ビルドが完全にパスした場合にのみ可能になり、デプロイは、CI の間にビルドしたのとまったく同じ VCS リビジョンに基づいたものになります。

デプロイの チェーン全体にわたってビルド番号を識別できるようにする必要があります。 例: CI ビルド 1.0.0 がステージングにデプロイされた場合、これが実際にはバージョン 1.0.0 であり、中間バージョンではないことを確認する必要があります。 一般設定で、ビルド番号の形式を変更して、元の CI ビルドと同じバージョン番号を使用します。 ビルド番号の形式は、CI ビルドのバージョン番号を複製した %\dep.WebAcmeCorpPortal\_ContinuousIntegration.build.number% に似ている必要があります。

CI ビルドは私たちのソリューションのためのデフォルト設定を構築していました。 今は別の環境にデプロイしていて、開発と本番用にデプロイ構成（および構成変換）を作成したため、Visual Studio ビルドステップを通じてビルド構成を変更しましょう。

今度は実際のデプロイステップが来ます ! 今までのところプロジェクトを構築しましたが、実際のサーバーに提供するために実際に何もしていません。 コマンドラインランナーに基づいて新しいビルドステップを追加することでそれを変更しましょう。 ビルドスクリプトとして、次のように入力します。

かなり長いですね？ このコマンドを見ていきましょう：

• "C:\Program Files\IIS\Microsoft Web Deploy V3\msdeploy.exe" は、ビルドエージェントで使用可能である必要がある msdeploy.exe へのパスです。

• -source:package='artifacts\WebDeploy\<ターゲット環境>\AcmeCompany.Portal.zip' はアップロードしたいデプロイパッケージを指定します

• -dest:auto,computerName="https://<Windows Azure Web サイトの Web 発行 URL>:443/msdeploy.axd?site=<Windows Azure Web サイト名>",userName="<デプロイユーザー名>",password="<デプロイパスワード>",authtype="Basic",includeAcls="False" はデプロイサービスの URL を指定します。 Windows Azure ウェブサイトの場合、これは前述のフォーマットになります。 IIS の場合、これは異なる場合があります (WebDeploy パラメーター に関する Sayed Ibrahim Ashimi の優れた投稿を参照してください)

• -verb:sync は WebDeploy に変更されたファイルのみを同期するように指示します (すべてのデプロイに対してすべてのファイルがアップロードされるわけではないため、これはデプロイ時間を劇的に短縮します。)

• -disableLink:AppPoolExtension -disableLink:ContentExtension -disableLink:CertificateExtension は、リモートマシン上の特定の構成ステップを無効化するために使用されます。 これらは環境によって異なる場合があります。 完全な一覧については MSDN を参照してください。

• -setParamFile:"msdeploy\parameters\<ターゲット環境>\AcmeCompany.Portal.SetParameters.xml" は重要なファイルです。 これは、接続文字列など、リモートサーバーにデプロイされた Web.config ファイルで置き換えられる WebDeploy パラメーターを指定します。 このファイルについては、後で詳しく説明します。

msdeploy.exe に渡されたパラメーターファイルはどうにかして作成されなければなりません。 CI ビルドのビルドアーティファクトにこのファイルのコピーが含まれていて、デプロイの秘密（本番データベースの接続文字列など）がソース管理で使用可能な場合に使用できます。 少なくとも私たちの開発者が使用しているのと同じソース管理ルートでは、これは望ましくないでしょう。

私のセットアップでは、 AcmeCompany.Portal.SetParameters.xml ファイルをカスタマイズし、異なるターゲット環境用の構成を、TeamCity サーバーだけが利用できる別の VCS ルートに配置しました。 これにより、データベース接続文字列は TeamCity 以外には秘密に保たれます。

これらの手順を繰り返して、ステージング用、QA 用、本番用などのビルド構成を作成できます。 このチェーン全体に渡ってビルドを促進したいため、これらの設定はすべて以前の環境へのスナップショット依存関係を持つべきです。

これはこれがどのように見えるかです: 各ターゲット環境にデプロイされているバージョンが異なることを示す 3 つの異なるビルド構成

ステップ 4: CI ビルドを昇格する

すべての準備が整ったので、ビルドをある環境から別の環境へ昇格する方法を見てみましょう。 CI ビルドのビルド結果に移動すると、 アクション ドロップダウンを使用してビルドを次の環境へ昇格できます。

ビルド構成のスナップショット依存関係を構成しているため、TeamCity は次の環境が開発であることを認識しています。

これにより、バージョン 1.1.3 を開発環境にデプロイする新しいビルドがトリガーされます。 検証が済んだら、そのビルドの結果に移動して、そのビルドを次の環境にプロモートすることができます。

スナップショットの依存関係を作成したため、どのビルドの 依存関係タブに移動して、それがデプロイされた環境を確認することもできます。 開発から見た 1.1.3 のビルドです。 CI ビルドが行われ、デプロイから開発までが完了し、デプロイから本番までがまだ実行中です。

まとめ

デプロイをビルドの連鎖として考えると、TeamCity からデプロイを行うのはそれほど難しくありません。 このチュートリアルでは、ビルドアーティファクトをターゲット環境に転送する方法の例として WebDeploy を使用しましたが、これも別の解決策（xcopy など）である可能性があります。

VCS ラベリングを使用すると、特定のデプロイが発生したときにソースにラベルを付けることもできます。 ビルドをピン留めすることで (必要に応じて TeamCity API 経由で)、ビルドのクリーンアップによって特定のビルドやアーティファクトが除去されないようにできます。