kkamegawa's weblog

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

Visual Studio Team Services CI/CDアドベントカレンダー:NuGetパッケージのCIとパッケージ機能(18日目)

はじめに

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

qiita.com

VSTSにはNuGet/maven/npmパッケージソース機能が用意されています。大部分の用途ではパブリックな公式サイトから取ってくればいいのですが、特定のバージョンのまま検証が済むまでアップデートをさせたくない、というケースはあり得ます。

オンプレミスのTFSを使う場合、インターネットへの接続を(今時ではちょっと難しくなりましたが)抑止したい場合にもパッケージサーバー機能は有効です。

なお、パッケージ機能に関しては、BASICライセンスでは使えません。有償ライセンスを買うか、VS Enterpriseサブスクリプションを購入する必要があります。

当然継続的インテグレーションも可能になっています。使い方を紹介します。

パッケージフィードを作る

まずはパッケージフィードを作らなくては話になりません。Packagesから作成します。ここではすでに作っているので、New feedをクリックします。

f:id:kkamegawa:20171218205721p:plain

わかりやすいフィード名を追加します。

f:id:kkamegawa:20171218205720p:plain

プライベートか、VSTSアカウントが使える人なら誰でも使えるようにするのかという設定、Upstream(nuget.orgやnpm.org,mavenなど)をソースにするのか、ここに登録したパッケージのみ使えるようにするのか、といった設定を行います。

f:id:kkamegawa:20171218205724p:plain

フィード作成直後は当然ですが何もありません。ここから作っていきます。Connect to feedをクリックすると、この作成したフィードに接続するための情報が表示されます。

f:id:kkamegawa:20171218205726p:plain

フィードには正式版以外にもプレリリース(nugetであれば-preオプション必須のパッケージ)版のパッケージなどを設定できます。

nuget/maven/npm/gradleといったパッケージのソースとして使うこともできます。

f:id:kkamegawa:20171218205727p:plain

コマンドでVisual Studioのパッケージソースとして追加できます。表示されているコマンドをそのままコピペして、実行します。

f:id:kkamegawa:20171218205728p:plain

正常に追加されると、Visual Studioのnugetパッケージマネージャーのソースとして追加されているのがわかります。

f:id:kkamegawa:20171218205725p:plain

nugetパッケージのCI

これでどハマりしました。久しぶりで、その上以前使っていたタスクが非推奨になっていたので、一からやり直しの上に、.NET Coreにも罠が待っていました…。そのうち改善されるとは思います。

今回は.NET Coreのライブラリをnugetパッケージにするためのビルド定義を作ります。通常の.NET Coreテンプレートからで構いません。

f:id:kkamegawa:20171218205717p:plain

NuGetのバグ回避のため、最新版をスタンドアロンインストールするタスクを追加しておきます。本来は.NET Core SDKでもnupkg作れるようですが、nugetを使います。

f:id:kkamegawa:20171218205718p:plain

現在のHosted VS2017 agentに入っているnugetでは.NET Coreのnugetパッケージが作れないという既知のバグがあります。ちょっとダサいですが、hosted agentのmsbuildをフルパスで呼び出して以下のタスクを実行します。

msbuild.exe /t:pack /p:Configuration=$(BuildConfiguration)

ビルドしたnupkgファイルをartifactstagingフォルダにコピーします。

f:id:kkamegawa:20171218205716p:plain

nuget pushコマンドで作成したVSTSローカルのパッケージフィードに登録します。

f:id:kkamegawa:20171218205715p:plain

これでビルドすると、先ほど作ったパッケージフィードに登録されています。ここではやっていませんが、ビルドごとにパッケージバージョンののインクリメントを実行することもできます。

f:id:kkamegawa:20171218205719p:plain

クロスプラットフォーム対応nupkgの生成

.NET Coreの場合、macOS/Windows/Linuxと複数プラットフォームのバイナリが入ったnupkgを要求されることがあると思います。そういう場合、以下の方法で実施できるでしょう。

  • Hosted VS2017/Hosted Linux/Hosted macOSそれぞれのエージェントでマルチフェーズビルドを実施する
  • ただし、それぞれのフェーズではnupkgを作らず、生成されたdllのみをartifactとして登録する。
  • Release 定義でartifactを取得して、nupkgを生成する

それぞれのhosted agentでは当然サーバーが違うので、複数フェーズビルドでは最後にnupkgをまとめることはできませんが、artifactとして一つにまとめることはできるので、バイナリのみ集めておいて、Releaseでnupkgを作ればいいでしょう。

パブリックとプライベートの使い分け

通常、stableのリリース版はnugetやnpmに発行すればいいですが、内部のプレリリース開発用までnugetに出していると煩雑です。そういう場合のために、外部に公開する前にVSTSのnugetサーバー機能を使って評価すればいいでしょう。

個人的にはdevブランチをビルドするとVSTSのPackageへデプロイ、masterブランチをビルドするとnugetへ登録するというビルド定義を作っています。

おまけ

このビルドがやたら時間がかかってしまい(Windows のビルドエージェントがいつもより遅かった気がする)、ビルドの無償枠がだいぶ溶けました…。

Visual Studio Team Services CI/CDアドベントカレンダー:ビルドタスクの実行条件を指定する(17日目)

はじめに

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

qiita.com

ビルドタスクを定義してもちょっと特定の時は動いてほしくない、という場合はあります。例えば、masterブランチのビルドをCIで実施するけど、手動で実行したときはテストしたくない、というケースはありえます。

そんなときのために、ある条件を満たすと特定のビルドステップを実行しない、という機能がありますので、紹介します。

ビルド定義での条件設定

ビルドタスクの実行条件はControl Optionsをクリックして展開される、Runt this taskで設定します。標準でCustom conditionsが選択されていますが、他の物を指定することもできます。

f:id:kkamegawa:20171217101334p:plain

  • Only when all previous tasks have succeeded
  • Even if a previous task has failed, unless the build was canceled
  • Even if a previous task has failed, even if the build was canceled
  • Only when a previous task has failed
  • Custom conditions

それぞれ順に以下の意味になっています。

  • 前のタスクが成功した時だけ実行する
  • 前のタスクが失敗した時、ビルドがキャンセルされてない限り実行する
  • 前のタスクが失敗した時、ビルドがキャンセルされた場合でも実行する
  • 前のタスクが失敗した場合のみ
  • 独自の条件を指定する

2-4番目に関しては、ビルドが失敗したとき、何らかのクリーンアップを実行するといった場合に指定するといいと思います。

本記事ではちょっとわかりにくい5番目のCustom Conditionsについて解説します。

Custom Conditionの設定

例えば、このビルド定義にはmasterへのコミットでビルドを実行する設定になっています。CIがかかったときはテストタスクを実行してほしいけど、手動で実行したときはテストをしなくてもいい、という条件を設定します。

f:id:kkamegawa:20171217101335p:plain

and(succeeded(), in(variables['Build.Reason'], 'IndividualCI', 'BatchedCI'))

保存して、手動でQueue Buildをクリックします。

f:id:kkamegawa:20171217101336p:plain

VsTest - testAssembliesタスクにチェックが入っておらず、実行されていないことが分かります。

f:id:kkamegawa:20171217101337p:plain

masterにコミットしたときに実行されるCIではVsTest - testAssembliesにチェックが入っていて、実行されていることが分かります。

Custom Conditionsの式は以下の形式です。

論理式(判定結果, 論理式())

論理式にはand, orなどが指定できます。variablesと比較する場合、variables['値']で実行時の値と比較可能です。

docs.microsoft.com

なお、この条件は以下のように重ねることができます。

and(and(success(),...)

参考文献

公式ドキュメントはこちらにあります docs.microsoft.com

Visual Studio Team Services CI/CDアドベントカレンダー:外部レポジトリ(GitHub)をビルドする(16日目)

はじめに

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

qiita.com

今までVSTSの内部レポジトリのビルドについて紹介していましたが、今日は外部のレポジトリ具体的にはGitHubのビルドについて紹介します。

VSTSはオールインワンでそろっていますが、外部サービスとも連携します。VSTSもよくはなっていますが、VSTSはクローズのみなので、オープンソースの開発をするならGitHubということは多いと思います。この記事ではVSTSのビルドサービスをGitHubのレポジトリに対して実行する方法について紹介します。

前提条件

以前も書きましたが、GitHubのレポジトリをビルドする場合、ビルド定義を作る人がownerになっている必要があります。Contributorではコミット時のビルドの設定ができないので、注意してください。スケジュールビルドはできます。

f:id:kkamegawa:20171216204504p:plain

GitHubへの認証を設定します。OAuthかPATを使うかお好みで。

f:id:kkamegawa:20171216204454p:plain

対象のレポジトリを選択します。ちょうど先日GitHubにConnect();で使われたデモソリューションのSmartHotel 360が公開されたので、forkしてみました。

f:id:kkamegawa:20171216204455p:plain

ここから先はVSTS内のレポジトリをビルドするときと変わりありません。ビルド定義を作って、ビルドキューに入れてみます。

f:id:kkamegawa:20171216204456p:plain

Hosted VS2017を指定します。

f:id:kkamegawa:20171216204457p:plain

普通にビルド完了ですね。ちなみにこのソリューションのビルド結構時間がかかります。10分弱使いました。

コミット時にビルドする

f:id:kkamegawa:20171216204458p:plain

GitHubの特定のブランチにコードがpushされたときにビルドする、pull request時にビルドするということもできます。

ただ、pull requestのビルドで外部レポジトリを指定した場合、git pullに失敗していました。これはちょっと調べてみます。それは置いといて、GitHubでpull requestしてみましょう。

f:id:kkamegawa:20171216204459p:plain

devブランチを作って、適当に編集して、自分のmasterにpull requestをだしてみます。

f:id:kkamegawa:20171216204500p:plain

mergeします。

f:id:kkamegawa:20171216204501p:plain

今回はpull requestとmasterへのcommitでビルドのトリガーをかけているので、ビルドが二つキューに入れられています。pull requestでCIをかける場合、このようにビルドがキューにはいるので、注意してください。

f:id:kkamegawa:20171216204502p:plain

masterへのコミットでビルドトリガーを指定しているので、自動的にビルドが実行されました。

ビルド結果の見方

ビルド結果ですが、自分がCIを設定しているので、mineハブを見ればいいか…と思うのですが、実はそうではありません。

f:id:kkamegawa:20171216213316p:plain

GitHubのmasterにコミットされたコードのビルド結果は20171216.3ですが、mineハブで表示されているのは20171216.1という、最初に自分で明示的にキューに入れたビルドだけです。

実はpull requestなどのVSTSが外部イベントにより自動的に発生するビルドに関しては、mineには表示されません。以前はmineにこの辺のCIによるビルド品質レポートも含められていたのですが、わかりにくいということでフィードバックにより変更されました(私も最初わからなくて聞きました)。

TFS 2017ではたぶんこのレポートはCI含めて表示されているはずなので、見るときには気を付けてください。

f:id:kkamegawa:20171216204503p:plain

CIおよび、ユーザーの明示的なビルド指示を含めて全部見たい場合はDefinitionsハブで見てください。

こちらはCIやほかの人が実行したビルド結果を含めて成功率が表示されます。

Visual Studio Team Services CI/CDアドベントカレンダー:異なるエージェントを使ってビルドする(15日目)

はじめに

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

qiita.com

6日目の記事で複数段階でビルドする、という機能を紹介しました。

kkamegawa.hatenablog.jp

その時はまだなかったのですが、Sprint 127の新機能でフェーズごとに別のエージェントが指定できるようになっています。今週中に展開が完了するということなので、もう使える方も多いと思います。ちょっとやってみましょう。

docs.microsoft.com

この機能はまだプレビューなので、Enable Preview Featureで有効にしてから試してください。

別のエージェントプールを追加する

f:id:kkamegawa:20171215065108p:plain

Processのところで、Add agent phaseで追加します。これは前と同じですね。

f:id:kkamegawa:20171215065103p:plain

前は選択できなかった、Agent queueが変更できるようになっています。せっかくなので、Hosted macOS Previewを選択します。

f:id:kkamegawa:20171215065104p:plain

こちらは従来通り、Hosted VS2017を選択します。

f:id:kkamegawa:20171215065105p:plain

こんな感じで複数のエージェントが構成できました。

f:id:kkamegawa:20171215065106p:plain

ビルドもそれぞれできてますね。

並列実行は?

f:id:kkamegawa:20171215065107p:plain

こんな風にparallel設定がありそうなので、複数のエージェントが並列でビルドできるのか…と思いきや、実はそうではありません。これはあくまでも「一つのエージェントフェーズ内で」の並列です。

docs.microsoft.com

具体的な用途としては、多くのUnit testを並列で動かすことができるのですが、そのためと思ってもらえればいいと思います。

並行ビルドの要望は出ているので、そのうち入るかもしれません。

Visual Studio Team Services CI/CDアドベントカレンダー:Inside Build Agent(14日目)

はじめに

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

qiita.com

VSTSにはCircleCIやAppVeypor、Travis CI、Bambooのようなクラウドベースのビルドサービスがあります。240分/月までは無料です。ただ、テンプレートから作ったものをビルドするだけでも3-4分かかるものもあるので、無料枠はどんな感じで使えるのかという感じをつかむくらいでしょうか。

そんなVSTSのビルドエージェントですが、実は自分でたてることもできます。インストールしてどんな挙動になっているのかとか、ちょっとしたTIPSを紹介します。

VSTSエージェントのソース

github.com

VSTSは.NET Core上で動いています。なので、Windows以外にもmacOS, Linuxもサポートしています。Linuxは特にdockerイメージも公開されているので、インストールは楽です。Windows版のDockerイメージも公開してほしいみたいなフィードバックは出ているのですが、まだないようです。

Docker使う方法は以前書いたので、こちらを見てください。

kkamegawa.hatenablog.jp

DockerイメージにはVSTSで動いているソフトと同じものが入っているので、それ以外で必要なものを追加する場合は自分でdockerイメージをビルドします。node.jsや新しいJDKであればビルドタスクで追加もできるので、dockerビルドする必要はありません。

ローカルか、プライベートか。

VSTSが提供するエージェントの場合、ローカルディスクが10GBまでという制限があります(緩和してほしいというリクエストは出ています)。これを超えるとpullやビルドに失敗するので、ゲームなどで大きなコンテンツをビルドするときはレポジトリをわけるか、ローカルエージェントを使うしかありません。

後はCPUが2コアだったはずなので、大きいソリューションを並列ビルド、テストしたいときもちょっと困りますね。

そのほか、新しいXCodeをいち早く使いたいとか、ライセンス上nuget等でとってこれないライブラリをビルドするときもプライベートエージェントを使ってください。

エージェントのフォルダー構成

ビルドエージェントのフォルダー構成はこのような感じです。

f:id:kkamegawa:20171214054159p:plain

_work(インストール時に変更できます)というフォルダの下に1,2,3...と数字が振られます。これがビルド毎に使われる作業フォルダです。

  • a : artifact(成果物)が格納されます。publish to artifactsタスクがこのフォルダーを丸ごとVSTSにアップロードします。
  • b : ビルドで一時的に使います。
  • s : ソースを取得するフォルダーです。

これらのフォルダーの絶対パスを取得したい場合、VSTSのビルドエージェントの定義済みの値を使用します。

docs.microsoft.com

ビルドタスクのPowerShell, バッチファイル、シェルスクリプトで参照できます。

f:id:kkamegawa:20171214054158p:plain

こちらはDeployment Group用に構成したエージェントです。_workというフォルダーの下にr1というフォルダーができており、その配下はビルドと同じ構成になってます。

aというフォルダの下にビルド定義で生成された成果物(artifact)がダウンロードされていることが分かります。ビルド定義でdropフォルダの下に生成すると指定しているのが分かると思います。

ビルドエージェントの更新

ビルドエージェントはGitHubのReleaseからダウンロードします。一部の環境でGitHubのRelease(というよりAWSのS3)へのアクセスが制限されている場合、VSTSの機能での更新はできないので気を付けてください。

Dockerみたいにmicrosoft.comドメインから配布してくれるとありがたいんですが…(フィードバックしたんですが)。

(2018/2/7更新)
ビルドエージェント 2.129(2.127も)からMicrosoft配下のドメインからダウンロードできるようになっています。おかげでAWS S3がアクセス禁止になっている組織でもダウンロードできるはずです。

docs.microsoft.com

そのほかの展開についてはこちらをみてください。ちなみに、VSTSへの接続は一台のビルドサーバーが一つのVSTSへの接続しかできない、ということはありません。リソースが許す限りいくつでもサービスを構築できます(もちろんインストール用のフォルダは別の名前にします)。

PATでの接続になりますが、PATの期限切れの通知はないので気を付けてください。

capability(ビルドエージェントで使用可能な機能)

VSTSでビルドエージェントと一口に言っても何がビルドできるのかわかりづらいでしょう。何がインストールされているかということはAgent Queueハブから対象のビルドエージェントを選択すると、Capabilityという項目でわかります。

f:id:kkamegawa:20171214054200p:plain

例えばこれはVSTS AgentのLinux Dockerイメージの場合です。JDK7/8はじめいろいろ入っています。独自のDockerイメージを作るのもいいでしょう。

f:id:kkamegawa:20171214054201p:plain

Hosted VS2017イメージです。実は作成方法はこちらのGitHubで公開されています。

github.com

このスクリプトを使えば理論上同じ機能を持つプライベートエージェントが作成できます。VSTSのHost agentはまだWindows Server 2012 R2のはずなので(そのうち2016になるようです)、Windows 10でなければビルドできないようなもの、例えばMixed Reality対応アプリやUnityに関しては残念ながらローカルエージェントを使ってください。

macOSのXCodeも新しいものにリアルタイムでついていきたい場合は自前で管理するしかないようです。

f:id:kkamegawa:20171214054203p:plain

capabilityはエージェントの環境変数の値がそのまま出ていますが、実は自分でも特殊な値を追加できます。自分のローカルエージェント(default)のUbuntu001のcapabilityから"Add capability"で好きな値(ここではmycapabilities)を指定します。

f:id:kkamegawa:20171214054204p:plain

そして、ビルド定義のDemandsにmycapabilitiesがなくてはならない(exits)と指定します。

f:id:kkamegawa:20171214054205p:plain

仮に、VS2017エージェントプールを指定しても…。

f:id:kkamegawa:20171214054206p:plain

このようにHosted VS2017のエージェントにはmycapabilitiesがないので、ビルドに失敗します。

これは自分で指定した追加capabilityですが、そもそもVisual Studioが必要なのに入っていないエージェントプールを指定しても同じエラーになります。

※:確か以前はキューに投入する前にDemandsと一致していないよという警告が出たはずなんですが…。

TIPS

自分で管理しているとはいえ、ソースの中に機微情報が入っているなどの理由でビルドエージェント内にファイルを残しておきたくない場合があります。

ビルドエージェント2.126(最新版)の新機能に、ビルド終了時pullしたソースコードを消してくれる、という機能が追加されました。

ビルド定義のvariableに"process.clean"を追加して、trueを指定してください。ビルド終了時にローカルのソースファイルが自動的に削除されます。

ビルドエージェントはあまり知られてないことも多いですが、ビルドタスクともどもオープンソースなので、困ったらソース見るといいと思います!

Visual Studio Team Services CI/CDアドベントカレンダー:タスクをライブラリで再利用する(13日目)

はじめに

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

qiita.com

ビルドやリリースで使うタスクはどうしても長くなります。また、ブランチやfork先のレポジトリでビルド定義を一から作るのも大変です。そんなときのためにTask Groupsという機能があります。ちょっと使ってみましょう。

タスクグループを定義する

タスクグループの定義は簡単です。既存のビルド定義やリリース定義から作っていきます。

f:id:kkamegawa:20171213060443p:plain

このようにグループにしたいタスクを選択して、右クリック「Create Task group」をクリックします。

f:id:kkamegawa:20171213060444p:plain

ただし、注意点として、標準のタスクはプロセスごとに共通の値(*/.csproj等の値)を定義しています。リンク機能といいますが、これを指定していると、タスクグループにできません。

f:id:kkamegawa:20171213060445p:plain

このように各タスクで共通の値として設定されている項目にある、unlinkをクリックしておきます。unlink allで全部削除されます。

f:id:kkamegawa:20171213060446p:plain

リンクが解除されると、今までタスクごとに編集できなかったProject(S)の項目が編集できるようになっているのがわかります。

f:id:kkamegawa:20171213060447p:plain

タスクグループの名前でわかりやすいものをつけましょう。ビルドタスク一覧に作者の名前と一緒に表示されます。また参照しているvariableの既定の設定も行います。ここではBuildConfiguration(Release/Debugなど)の指定ができます。

f:id:kkamegawa:20171213060448p:plain

タスクグループをどのカテゴリーに追加するかという選択です。buildを選んだら、タスク追加時に選択する"build"カテゴリーに表示されます。Createボタンを押すと、現在のビルド定義の該当タスクがタスクグループでおきかえられます。

f:id:kkamegawa:20171213060449p:plain

こんな感じですね。Build configurationもグループの共通設定で可能になっています。

Task groups定義の管理

作ったタスクグループはTask groupsハブで管理できます。

f:id:kkamegawa:20171213060450p:plain

グループの名前、詳細説明(description)、定義のカテゴリーなど作るときに指定した項目が指定できます。

f:id:kkamegawa:20171213060451p:plain

一度作ったタスクグループの内容を変更したい、ということはよくあります。ここでタスクの追加や削除、使用しているタスクのバージョンアップといったことができます。ピンクの旗アイコンがタスクの横についていますが、これがタスクのバージョンアップが可能というお知らせです。ちなみに選択するとpreview版のver2が選択できます。

f:id:kkamegawa:20171213060453p:plain

新しくビルドタスクの追加もできます。

f:id:kkamegawa:20171213060452p:plain

タスクグループをバージョンアップするのはいいのですが、複数のビルド定義で参照されていると影響が…ということもあると思います。そういう時はReferencesから使用しているビルドやリリース定義の参照ができます。

とはいえ、いきなり全部のタスクをアップデートするのは怖いものです。そういうときのために、プレビュー版として公開する機能も用意されています。

f:id:kkamegawa:20171213060456p:plain

新しく同じタスクグループを参照するビルド定義を追加すると、こんなかんじでふえます。

新しいビルド定義で参照する

作ったからには当然新しいビルド定義で参照もできます。

f:id:kkamegawa:20171213060454p:plain

buildカテゴリーにタスクグループを作っているので、buid配下で探すと、作ったdotnet buildタスクがありますね。

f:id:kkamegawa:20171213060455p:plain

追加するとこんな感じです。

プレビュータスクで評価する

前述したように、いきなりビルドタスクを更新されると困ることもあります。そのような場合のために、プレビュー版を作って事前に評価してもらう仕組みがあります。

f:id:kkamegawa:20171213195831p:plain

ビルドタスクの一部を新しいバージョンに更新します。Saveではなく、Save draftで保存して、Publishをクリックします。

f:id:kkamegawa:20171213195833p:plain

Publishを実行すると、Publish as previewというチェックボックスがあるので、チェックすると、プレビュー版のタスクグループとして登録されます。

f:id:kkamegawa:20171213195834p:plain

ビルド定義でバージョンのところに2.*(preview)という選択肢が増えてますね。これでビルドできるかフィードバックをもらって、OKであれば、タスクグループを更新して、全体に反映させます。

まとめ

ビルドやリリースのタスクをグループ化できるTask groups大きな環境になると便利なので、使ってみてください

Visual Studio Team Services CI/CDアドベントカレンダー:仮想マシンへの継続的デプロイ(12日目)

はじめに

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

qiita.com

今日は昨日に引き続き、Azure仮想マシンへの継続的配信を紹介します。最初に…ちょっと失敗して、仮想マシンへの設定で忘れているものがありました。なので、失敗していますが、最終的には成功するはずです、たぶん。あとでUIテストを紹介するときにリカバリーしようと思っています。

仮想マシンでの事前準備

AzureにWindows仮想マシンを立てた人はわかると思いますが、ネットワークプロファイルがパブリックになっています。実はこのパブリックのままだとWinRMでの管理ができません。

Azureでドキュメントが提供されているので、こちらを見てください。

docs.microsoft.com

AzureのDevTest Labsであればこの辺も割と面倒見てくれるはず…です。TFS本ではこの辺をちゃんとドメインプロファイルにしているので、そちらでもカバーできればと思っています。

Azure仮想マシンデプロイ時の注意点

f:id:kkamegawa:20171212205452p:plain

Azure仮想マシンデプロイ時の拡張機能にTeam ServicesのDeployment groups用のエージェントを入れられるように見えるのですが、実はこれ成功したことありません(汗)。これを入れると、どうしてもVMのデプロイでエラーになります。VMそのものはできているのですが、エージェントが構成されていません。

製品グループにもフィードバックしたような感じではありますが、もう一度聞いてみます。

f:id:kkamegawa:20171212205459p:plain

VSTSのAzure File Copyタスクでストレージアカウントを指定するところがあるので、管理ディスク(Managed Storage)を使わないほうがいいかもしれません。WinRMを使うので、ストレージアカウントなくてもいいはずなんですが…停止しているときでもコピーできればいいのですが。

Deployment groupのエージェントフェーズを使う

f:id:kkamegawa:20171212203125p:plain

ReleaseでEnvironmentを作るとagent phaseというビルドエージェントと同じものを使っていました。Deployment groupに対してデプロイするにはdeployment group phaseを使います。

f:id:kkamegawa:20171212203124p:plain

追加するタスクはagent phaseと変わりありません。PowerShellのタスクやResource Groupの作成ができます…が、このResource Group内のVMの起動タスクを設定すると、現時点でなぜかエラーが出るようです。ちょっとフィードバックしておきます。

f:id:kkamegawa:20171212203123p:plain

Azureリソースグループ内のVMを起動する、というタスクです(が、私が試したときはエラーになりました…)。

f:id:kkamegawa:20171212203134p:plain

VMにファイルコピーします。ここでストレージアカウントを指定するため、VMには管理ディスクが使えないのではないか疑惑がありますが、ちょっと聞いてみます(こんなんばっかり…)。

Sourceはビルドで生成されたartifactのコピー元フォルダを指定します。

f:id:kkamegawa:20171212203126p:plain

こんな感じですね。フォルダを指定するので、コピー元のartifactの段階でちゃんとフォルダになっている必要があります。ビルド時msi形式で作っている場合、このタスクでコピーしてから、WinRMで実行するか、PowerShell DSCで構成するしかないでしょうか。

f:id:kkamegawa:20171212203130p:plain

VMへのコピーはこんな感じです。Adminのアカウント名とパスワードはVariablesに登録しています。ただ、Workgroup環境だとVMごとにアカウント名が変わるので、やはりAzure Active Directory Domain Servicesなどでドメイン管理しないといけないんでしょうか…。ID複数管理するのが苦にならなければいいけど。

f:id:kkamegawa:20171212203129p:plain

リリース実行

f:id:kkamegawa:20171212203131p:plain

Create Releaseでリリース実行します。

f:id:kkamegawa:20171212203133p:plain

対象のVMにコピーできれば完璧…だったのですが、WinRMの構成やるの忘れていたので、このようなエラーになりました(恥)。Azureに限りませんが、Windows VMへのデプロイを実施するときは以下のことを忘れないでください。

  • セキュリティグループで5986/tcpを通す
  • 仮想マシン内のパブリックネットワークプロファイルに対してwinrm qcを実施ておく(デフォルトではエラーになります)
  • Windows Advanced Firewallでパブリックプロファイルに対して5986/tcpを通す

さすがにパブリックプロファイルに対して5986/tcpを通すのは怖いと思います。AzureのIPアドレス変更に追従できるのであれば、VSTSのIPアドレスのみ通すようにネットワークセキュリティグループを構成すればいいでしょう。

f:id:kkamegawa:20171212203132p:plain

デプロイが終了すると、deployment groupのマシンに対して成功失敗が表示されます。

まとめ

閉まらない結果でした、後日ちゃんとした方法を(TFS2017/2018本ともども)フォローアップします…たぶん。