kkamegawa's weblog

Visual Studio,TFS,ALM,VSTS,DevOps関係のことについていろいろと書いていきます。Google Analyticsで解析を行っています

Visual Studio Team Services CI/CDアドベントカレンダー:Deployment Groupで仮想マシンへの展開を管理する(11日目)

はじめに

この記事はVisual Studio Team Servicesアドベントカレンダー12日目の記事です。

qiita.com

仮想マシンへの展開、どうやっているでしょうか?ReleaseやBuildのタスクでFQDNを指定してコピーもいいですが、VSTSには展開する仮想マシンのグループを管理するDeployment Groupsという機能があります。これを使うと、配布エージェントの管理をVSTS側でやってくれるので便利そうです。ちょっと使ってみましょう。

長くなりそうだったので、今日はDeployment Groupsの管理だけです。

Deployment Groups作成

f:id:kkamegawa:20171211061539p:plain

Build & Releaseの中にDeployment Groupsがあります。*がついているので、まだプレビューという扱いです。

f:id:kkamegawa:20171211061537p:plain

Add deployment groupをクリックして、作成します。

f:id:kkamegawa:20171211061538p:plain

名前は任意で決めてください。Descriptionにはわかりやすい説明をつけます。

対象とするOSはWindowsかLinuxです。とはいえ、Linuxで必要となることがあるかどうかはちょっと疑問です。Azureのコンテナーサービス使ったり、Web Apps使ったほうがいいように思います。

エージェントを展開するためのPowerShellスクリプトが用意されるので、Azureで展開する場合、仮想マシンのプロビジョニング時にこのままコピペすれば、使えます。ちなみにAzureのDevTestLabsでは初期設定時にこのエージェントを展開する機能が用意されています。

注意点として、同じエージェントを使いますが、ビルドエージェントではありません。つまり、ビルドとDeployment groupのエージェントを兼ねることはできません。これはUIテストでも同じことです。テストはテスト、ビルドはビルド、となります。マシンが多くなりますね。

f:id:kkamegawa:20171211061545p:plain

対象とする環境にはタグをつけることができます。タグは決まっていないので、任意に設定します。OSはDeployment groupsがそもそも異なるので、Windows 10であれば、1709とかの現在のバージョンやFirefox, Chromeが入っているかどうか、先行リリース環境であるかどうかなどを指定すればいいでしょう。

f:id:kkamegawa:20171211061540p:plain

こんな風に一覧で含まれるターゲットのPCが表示されます。

f:id:kkamegawa:20171211061542p:plain

オンライン、オフラインの状態もわかります。

エージェントの管理

f:id:kkamegawa:20171211061543p:plain

エージェントはしばしばバージョンアップされます。Deployment groups単位で更新ができます。Update agentを実行すると、自動的にグループ内のOSのエージェントが更新されます。

f:id:kkamegawa:20171211061544p:plain

更新してもいいかどうか確認されます。

f:id:kkamegawa:20171211061541p:plain

更新前、Agent.versionは2.124でした。

f:id:kkamegawa:20171211061545p:plain

更新後、Agent versionが2.126になりました。

まとめ

Deployment groupsを使ってテスト環境を管理するところを紹介しました。Release機能でこの管理しているグループに対するデプロイがサポートされているので、明日はその辺を紹介します。

Visual Studio Team Services CI/CDアドベントカレンダー:データベースへのCI/CD(10日目)

はじめに

これはVisual Studio Team Servicesのアドベントカレンダー10日目の記事です。

qiita.com

CI/CDといえば、プログラムが主ですが、データベースにデプロイするときはどうしているでしょうか。Visual Studio 2017 Enterpriseに付属するReadyRollを使ってCI/CDをやってみましょう。Re

なお、VS2017に付属するReadyRollはCoreエディションなので、一部機能のみですが、SQLに対するIntelliSenceとかは使えます。SSDTに内蔵されているものよりも高機能に見えます。

www.red-gate.com

Pro/Communityエディション向けには体験版が用意されています。

marketplace.visualstudio.com

ReadyRollはSQL Server(SQL Database)専用ですが、開発しているRedGate社はMySQLやOracle DBに対応した製品も販売しているようです。

www.red-gate.com

RedGate ReadyRollとEntity Frameworkの違い

データベースの管理ではないですが、移行をサポートしたものとしてすぐに思いつくのはEntity FrameworkのCode Firstとの違いです。以前も書いたのでこちらをみてください。

kkamegawa.hatenablog.jp

ただ、VSTSと組み合わせると結構便利なこともあります。ちょっと見てみましょう。

拡張機能の追加

marketplace.visualstudio.com

まず、対象のVSTSにReadyRoll拡張機能を追加します。この拡張機能そのものは無償です。ライセンスはあくまでもクライアントのみにかかるようです。追加すると、ReadyRollのビルドタスクが表示されます。

ビルド定義を作る

f:id:kkamegawa:20171210172604p:plain

ReadyRollには専用のビルド定義が用意されています。こちらを選びます。

f:id:kkamegawa:20171210154152p:plain

こんな感じのビルド定義が用意されています。当然ですが、ビルドエージェントにはHosted VS2017か、Visual Studio 2017 Enterpriseがインストールされているプライベートエージェントをプールを選んでください。

f:id:kkamegawa:20171210154148p:plain

ターゲットのSQL Server(Database)を選んで接続情報を指定します。余談ですが、パスワードはAzure Key Vaultを使うこともできます。

f:id:kkamegawa:20171210154147p:plain

Variable GroupにKey Vaultを指定します。

f:id:kkamegawa:20171210154146p:plain

Key Vaultに登録したVariable Groupを参照しておけば、ビルド定義内でKey Vaultに登録しているパスワードをビルド内変数として参照できます。

f:id:kkamegawa:20171210154149p:plain

Visual StudioのビルドタスクもReadyRollように調整されています。ビルドを実行してみましょう。

f:id:kkamegawa:20171210154150p:plain

VSTSにReadyRoll拡張機能をインストールすると、Database diff scriptとDatabase scriptという項目ができています。ReadyRollプロジェクトをビルドすると、ここに表示されます。このキャプチャを取った11/26時点ではWindows 10 Fall Creators UpdateのEdgeではここが表示されないようで、Chromeでキャプチャを取りました。

f:id:kkamegawa:20171210154151p:plain

データベースに対して実行したスクリプトも表示されます。

ReadyRollでリリース

ビルドができたら次はリリースです。

f:id:kkamegawa:20171210154153p:plain

リリースでの成果物(Artifact)にReadyRollのビルド定義を指定します。

f:id:kkamegawa:20171210154154p:plain

リリースのタスクにReadyRoll deploy Database Packageがあるので、選択します。

f:id:kkamegawa:20171210154155p:plain

ビルドパッケージにはReadyRollで生成されたPowerShellスクリプトを指定します。

f:id:kkamegawa:20171210190710p:plain

このように、リリースも正常に行われています。

Visual Studioでの注意事項

f:id:kkamegawa:20171210190748p:plain

Visual StudioでReadyRollのプロジェクトを作ったときデプロイ先によって、プロジェクトのこの設定を変更してください。

特にSQL DatabaseとSQL Serverでは使えるSQLに差があります。具体的にはuse命令がSQL Databaseでは使えないので、SQL ServerのままだとSQL Databaseへのデプロイに失敗します*1

まとめ

ReadyRollを使った基本的なデプロイまで紹介しました。もちろん一回のデプロイで終わるわけはなく、継続的にリリースするときにはいろいろ考慮することがありますが、もうちょっと使いこなしてみて紹介できればと思います。

*1:最初これに気づかなかった…

Visual Studio Team Services CI/CDアドベントカレンダー:Logic Appでビルド通知(9日目)

はじめに

qiita.com

これはVisual Studio Team Servicesアドベントカレンダー9日目の記事です。今日はLogic Flowを使ったアプリケーションからVSTSのビルドを呼び出し、Teamsと連携してみます。

現在、VSTSとTeamsを統合するにはVSTSがAzure ADの認証を使っている必要があります。MSアカウント認証を使っているVSTSではTeamsにビルド結果の通知とかできません。

ただ、Logic Appを使えばその問題も解決します。もちろんFlowでもかまわないはずです。

Logic Appを作る

f:id:kkamegawa:20171209221702p:plain

AzureポータルからLogic Appを作ります。

f:id:kkamegawa:20171209221654p:plain

Logic AppのコネクターにはVisual Studio Team Servicesがあるので、追加します。"Queue a new build 2(プレビュー)"で指定したプロジェクトのビルド定義の指定ができます。

ビルドが投入されたらOffice 365のTeamsにメッセージをポストしてみましょう。

VSTSのWeb hookを設定

プロジェクト管理(歯車アイコン)のService Hooksから追加します。ServicesからWeb Hooksを選択します。

f:id:kkamegawa:20171209221655p:plain

TriggerでCode pushedを選択します。もちろんpull requestとかのトリガーでも構いません。チームプロジェクト名、ブランチ、プッシュしたグループなどを設定します。

f:id:kkamegawa:20171209221656p:plain

次に設定したトリガーの条件が満たされたときに実行する処理を設定します。ここでLogic Appsで作られたURLを指定します。このURLを知っていれば誰でも(VSTS外からでも)実行できてしまうので、URLの漏洩には気を付けてください。

このURLはAzureポータルで自動的に作成されるこの部分になります。

f:id:kkamegawa:20171209221657p:plain

ここで表示されているURLをそのままコピーしてください。

f:id:kkamegawa:20171209221658p:plain

このように登録されます。

実行してみる

f:id:kkamegawa:20171209221700p:plain

実行されるかどうか、コードを編集してpushします。

f:id:kkamegawa:20171209221659p:plain

Teamsにもメッセージが投稿されました。

f:id:kkamegawa:20171209221701p:plain

VSTSのWeb Hooksが動いた時間も記録されます。

まとめ

VSTSのWeb Hooksを使ってほかのシステムと連携できるのは便利ですね。VSTSには以前Roomという機能があったのですが、外部のツールのほうが便利なので、こういう機能を使って連携する道を選んだようです。

今回はビルド結果の通知だけでしたが、ビルド完了をイベントにすればVSTSでサポートされていない成果物(artifact)をOneDriveにコピーすることも可能です。

Web Hook以外にも便利なものが使えるので、探してみてください。

Visual Studio Team Services CI/CDアドベントカレンダー:PowerShellでビルド実行(8日目)

はじめに

これはPowerShellとVisual Studio Team Servicesの8日目のアドベントカレンダーです。

qiita.com

qiita.com

昔のVSTS/TFSでは.NETのオブジェクトベースのコマンドで管理していましたが、REST APIもだんだん実装されてきました。PowerShellでももちろん使えます。やってみましょう。

ちなみにコマンドもPythonベースのクロスプラットフォームのvsts-cliが提供され始めました。

docs.microsoft.com

ソース

Invoke VSTS Build definition by Build Name.

難しいことはほとんどありません。REST APIはこちらに載っています。現在はAPI version 2.0を使ってください。

www.visualstudio.com

注意点として、PAT(Personal Access Token)をつかってください。

docs.microsoft.com

上記のスクリプトを実行すると、指定したビルド定義名のビルドが実行されます。

f:id:kkamegawa:20171208230522p:plain

VSTSのREST APIでは名前では管理されておらず、IDで管理されています。名前はしばしば変わるから仕方ないですね。

なので、スクリプト中で登録済みのビルド定義の一覧を取得して、IDを逆引きしています。

機密性を上げる

ただ、これはスクリプトの中にPATを直接書いています。ローカルで使うだけのスクリプトであればまだしも、みんなが共通で使うものとしてはいけていません。

そこで、Azure Key VaultにPATを格納して、実行時はそちらを参照するようにしたいとします。

docs.microsoft.com

一応VSTSのvariableのシークレット指定をすれば2048ビットで暗号化されるとのことなので、お手軽にやるならこちらでもいいでしょう。一度シークレット登録すると、もう登録した人にも値は見えません。

f:id:kkamegawa:20171208230527p:plain

こんな感じでちょっと直します。

f:id:kkamegawa:20171208230526p:plain

空のビルド定義からPowerShell実行タスクを登録します。

f:id:kkamegawa:20171208230528p:plain

VariablesのVariable GroupからLink Variable Groupをクリックします。LibraryにあるVariablesのAddをクリック。

Key Vaultを作ったAzureサブスクリプションとKey Vaultの名前を選択します。

f:id:kkamegawa:20171208230523p:plain

使いたいVaultを選択します。

f:id:kkamegawa:20171208230524p:plain

Linkをクリックします。

f:id:kkamegawa:20171208230525p:plain

ビルド定義のVariablesにKeyVaultの値が関連付けられました。ビルドごとにKey Vaultを参照して秘密の値を取得します。

これでめでたしめでたし…ならいいのですが、実はまだちょっと動いていません。あとで直します。たぶん環境変数では参照できないんじゃないかと思っています。

さいごに

PowerShellのREST API久しぶりで色々忘れていました。特にJSON作るところとか、便利なんですが…最近はVS CodeのREST APIクライアント拡張機能があるので、エディタで書くだけでREST発行できて便利なんですよねw。

この辺の自動化でやりたいことがあるのですがそれはまた後日紹介します。

Release昨日のほうは紹介できませんでしたが、たぶんほぼ変わらないはずです。