[アーカイブ] InRelease による継続的デプロイの自動化

<オリジナル投稿 2013年9月13日 本ポストの情報はオリジナル投稿時点のものです。マイクロソフトの正式な見解や製品の仕様を示すものではないことをご了承ください。>

  

InRelease とは

InRelease とは、TechEd North America 2013 で InCycle 社からその事業を買収し手手に入れたデプロイメントのソリューションです。もともと TFS 2010 の時代から実績があるこのソリューションを TFS 2013 のタイミングで取り入れることで、DevOps をはじめ、継続的デリバリーをより複雑さを排除して実践いただけるようになります。
InRelease の特徴は以下の2つです。

  • デプロイ候補となるアプリケーションコンポーネントを自動で、異なる環境の様々なターゲットサーバーにデプロイを行う
  • あらゆる構成情報を中央集中管理し、ビジネス駆動のリリース ワークフローの一部としてデプロイメントをロールベースで行う

InRelease のコンポーネント

InRelease のコンポーネントは、いたってシンプルです。以下は、Brian Keller の InRelease Hands On Lab ドキュメントで出てくる図です。
image
InRelease Server (IR Server) が InRelease のサーバー機能となり、DB、ワークフローの制御、デプロイターゲットサーバーとのアクティビティの同期を担当します。
InRelease Client は、InRelease のサーバーの設定を変更したり、状況を確認したりするものです。WPFベースのクライアント (IR Console) と Web ベースのクライアント (IR Web) があります。
InRelease Deployer は、ターゲットサーバーにセットアップされるサービスです。この Deployer サービスが、Pull 型で、自分のサーバーに必要なアプリケーションコンポーネントのデプロイを行ってくれます。

InRelease の Web インターフェイス

とてもシンプルなインターフェイスです。
image
こちらは、前回承認されたリリースについてのレコードです。Prod すなわち、本番環境(Production 環境)にデプロイされているのがわかります。
デプロイされたコンポーネントは、クリックすると確認できます。
image
この例だと、Webサイトをデプロイしているだけなので、1つのコンポーネントしかありませんが、コンポーネントのビルドIDまで特定できていることがわかります。TFS の自動ビルドをご存じであれば、このビルド ID さえわかれば、バグや機能と実行したタスク、実施したテストケースとテスト結果がすべて追跡可能であることは知っていますね?この情報があれば、後からでもすべてたどることができます。
次に、本番環境へどのようなステップ(ワークフロー)で、だれが承認や確認をしたのかなどを見てみましょうちょうど「Prod」というところをクリックすると見れます。
image
ここでは、前の段階(ステージ)でだれが承認したのか、そして自動で何がいつどうデプロイ(インストール)されたのか、そして最終的な検証をだれが行ってどうだったのかが記録されているのがわかります。また、この前の段階は、「previous stage」をクリックするとみることができます。前の段階は、「QA」です。
image
こちらには、前の段階の承認、自動デプロイに、自動検証、そして最終承認が一望できてます。さらに、前の段階を見ると、
image
「Dev」ステージであることがわかります。こちらも「QA:同様に実施されていることがわかります。こちらは、基本的に全自動になっていますね。継続的インテグレーションをし、デプロイ自動化、テスト自動化が行われ、それを手動で確認、承認しているのがわかります。
各Dyployerは、自分(ターゲットサーバー)に必要なコンポーネントをデプロイする必要があると判断したら、InRelease サーバーにたまっているキューを見に行って必要なものを自発的にピックアップして自動デプロイを行います。この時に、TFS でビルドしている場合は、TFS の API を使い、ビルド成果物の場所を検知し、ダウンロードなどを行い、さらにバッチや PowerShell などを実行してくれます。TFS ビルドを使っていない場合は、UNCパスで共有したビルド成果物を見に行くようにします(TFS ビルドは必須で使ってほしいところです!)。

InRelease の設定

InRelease の設定はそれほど難しくはありません。WPFベースのツールで設定を行うことができます。タブがいくつかりますが、それらは順に紹介していきます。
まずは、「Track Releases」タブです。名前の通り、デプロイメントの遷移の追跡とその状況を可視化してくれています。
image
Dev→QA→Prodの各ステージに対しての状況が見れます。
Step Details で詳細に何がだれによっていつ行われたのかを見ることもできます。
image
さらに、「Traffic Overview」から「Releases」に切り替えるとより詳細な情報を見ることができます。
image
自動化されているところ、手動による確認なども明確にわかりますし、自動化されているものを中心に詳細情報を追うことができます。
image
さらに、ログも見れます(ログもとってます!)ので、安心です。
デプロイメントのワークフローも可視化させ確認できます。
image
Windows Workflow ベースで非常にわかりやすいです。もちろん、これらはカスタマイズすることができます。グラフィカルにカスタマイズができますので、便利です。
そして、各アクティビティも前もって準備したものを再利用することができます。
image
こちらには、利用できるツールが一覧表示されています。AzureやIISなどいろいろなものがあらかじめ提供されています。
image
詳細情報を見ると、各ツールでどのようなスクリプトやツールを呼び出しているのかがわかります。
そして、アクションは、実に多彩なものがあらかじめ提供されています。
image
っといったところで、また続きは、追記します(睡魔がwww