読者です 読者をやめる 読者になる 読者になる

kkamegawa's weblog

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

VSTS/TFSの継続的インテグレーションとデータベース接続と単体テスト

データベース接続を動的に作る

最近、id:ishikawa-tatsuya さんのLambdicSQLというSQLをラムダでかいちゃおう、というOSSをid:odashinsukeさんと一緒にやってます。いろいろなデータベースに対応する(予定)ですが、とりあえず三人のスキルセットがそろっているSQL Serverを最初にやっています。

github.com

今までは個人でビルドしていましたが、CIやってみようかということで、個人的にVSTSのビルド定義を作ってみました。テストには当然SQL Serverを使うのですが、個人でやるときはそれぞれのSQL Server(LocalDBでもいいはずです)を使えばいいものの、CIとなるとちょっと困る。

接続情報はほかの人には教えたくないこともあり、LambdicSQLではProjectフォルダの下にdb.txtというファイルを作って、接続情報をそのまま平文で書いておくことになっています(もちろんgitignoreには定義済み)。

ではCIのときはどうするか?ということですが、こんな感じでやってます。

f:id:kkamegawa:20170510065239p:plain

まず、普通にVisual Studioのビルドテンプレートを作ります。次にPowerShellのタスクでインラインスクリプト(inline script)を追加します。new-item(別に要らないけど)とadd-contentコマンドレットで、db.txtにSQL Databaseへの接続情報を書いています。

f:id:kkamegawa:20170509055356p:plain

接続情報はそのまま隠すので、variableに独自で文字列を定義して、そのまま書いています。ほんとはタイムアウトとか変更できるように、サーバー名とユーザーID, パスワードだけ隠せばいいんですが。

テストを選別する

とはいえ、毎回すべてのテストが必要なわけでもありません。特にLambdicSQLにはデータベースをcreate/dropするテストもあります。SQL Databaseを作成するたびに2.33円(デフォルトのStandard S0の場合)かかるのはお財布にも優しくありません。

f:id:kkamegawa:20170509071834p:plain

そこでこんな風に、TestCategoryやPriority属性をつけておきます。

f:id:kkamegawa:20170509071833p:plain

テストエクスプローラーで「特徴」を選択するとこんな風にPriority1(CreateDrop以外)とPriority2(CreateDropDatabase)が区別できます。

f:id:kkamegawa:20170510064216p:plain

ビルドのTest AssembliesタスクのTest filter criteriaにPriority=1と指定すると、Priority属性が1のテストだけ実行されます。

Team Foundation Server 2017 Update1リリースと注意事項

TFS 2017 Update1

リリースされましたね。今回SQL Server 2016 SP1やWindows Server 2016もサポートされています。ハードウェア要件はこちらから。

www.visualstudio.com

Express Editionもリリースされていますが、前回同様機能差はなく、SQL Serverのライセンスが付属しない、フル機能が入っている(制限は人数のみ)のようです。6人以上使いたい場合はTFS CALになります。

リリースノートの注意事項

www.visualstudio.com

フィードバックしていますが、日本語版の翻訳には既知の問題が漏れていますので、英語版も見てください。

www.visualstudio.com

TFS 2013からのアップグレードを行うと"counter with name TaskReferenceId does not exist"というエラーが出ます。英文のリリースノートに回避するためのSQLが載っています。

そのほかの既知の問題も気を付けてください。

Erastic Search

TFS 2017 RTMからコード検索にErastic Searchを使うようになりました。RTMでは1.7でしたが、RTMでは2.4になっています。私の手元で何台か入れ替えたのですが、いずれもコード検索ができませんでした。対処としてはどちらかでしょうか。

  • アップグレードではなく、一度「TFS2017をアンインストール」してからTFS 2017 Update1をインストール
  • GitHubにある修正用のスクリプトを実行する

前者はデータベースさえあればいつでも戻るので、大丈夫です。後者はここにスクリプトがあります。TFS 2017用とTFS 2017 Update1用でフォルダが分かれているので気を付けてください。

github.com

Re-IndexingRepository.ps1というスクリプトを実行すれば治る…はずです。ちなみに私は全部やりました。

リリース前のスクリプトだとInvoke-Sqlcmdの -inputfile で指定するフルパスの解釈ができなかったので、pull request送って直してもらいました。

www.visualstudio.com

引数がちょっとわかりづらいですが、こうなります。チーム内にTFVC/Git両方ある場合、リポジトリ名はどちらを指定しても変わらないような気がします(一度の実行で全部直りました)が、チームプロジェクトごとにやったほうがいいでしょう。

  • SQL Server名(インスタンス名)
  • TFSのコレクションデータベース名(既定ではTfs_DefaultCollection)
  • TFSの構成データベース名(既定ではTFS_Configuration)
  • Git(Git_Repository)かTFVC(Tfs_Repository)か
  • コレクション名(既定ではDefaultCollection)
  • リポジトリ名(チームプロジェクト名)

これでしばらく待つと、再構築され、復旧するはずです。

Visual Studio Team Servicesとエコシステム(25日目)

はじめに

一人アドベントカレンダーの最終日はちょっと毛色を変えて、VSTSのエコシステムについて書いておきます。実はまだ書いていないもの色々あるのですが、それはおいおい追加します。

VSTSとつながるIDEなど

VSTSにはSubversionのような中央型のリポジトリのTFVCと、分散型のGitの二種類をサポートしています。TFVCはチームプロジェクトで一つのみですが、Gitは複数のリポジトリがサポートされています。

Git

Visual StudioからGitをソリューションエクスプローラ経由で使う場合、Visual Studio 2015 Update3以降を使ってください。Visual Studio for Macがリリースされていますが、monodevelopベースということもあり、Gitのみ使えます。GitをサポートしているIDEやGitコマンド(Git for Windowsなど)で、ssh/httpsが使えればなんでもつながります。

f:id:kkamegawa:20161225173616p:plain

標準でこれだけサポートしています。

f:id:kkamegawa:20161225163605p:plain

Visual Studio for Macでつなぐ場合の例です。事前にPAT(Personal Access Token)を作っておいてください。

f:id:kkamegawa:20161225163606p:plain

IDEの場合は基本codeのpush,pullなどができればいいはずですが、VS Codeの場合はもうちょっと広くとります。

VS Codeの拡張機能

marketplace.visualstudio.com

VS CodeはそのままでもGitの機能を持っていますが、拡張機能をインストールすると、作業項目の作成、閲覧、pull requestの確認ができます。探してみたら、他にも有志が作成した、ビルドステータスを確認する拡張機能もあるようです。

この拡張機能はPATでのアクセス前提なので、事前に作成&VS Codeに登録してください。画面下のステータスバーをクリックすると、作業項目やブランチ切り替え、pull request表示ができます。

f:id:kkamegawa:20161225163607p:plain

(画面では出てこないですが)pull request一覧の確認ができます。

f:id:kkamegawa:20161225163608p:plain

チームプロジェクトの作業項目が確認できます。Gitコミット時に # 番号 でGitHub同様に作業項目と関連付けが行われますが、その番号確認に便利です。

TFVC

TFVCは色々対応がアレなこともあって、プラグインをそれぞれ作らないといけないようです。

Team Explorer Everywhere の導入

Javaが動く環境であればTeam Explorer Everywhereという無償ツールを使ってアクセスできますが、いつもVisual Studioよりも少し遅れての提供になるので、最新のVSTS/TFSでは少し制限が出るでしょう。Gitに慣れてないとかの理由がない限り、Visual Studio以外の環境では素直にGitを使った方がいいでしょう。

TFVCをプラグインでサポートしているIDEはEclipse, IntelliJ(自動的にAndroid Studioも)があります。

拡張機能

VSTS/TFS自身で色々できますが、拡張機能も多く提供されています。商用、フリー両方ありますが、見た所オープンソースのものが多いように思えます(数えてはいません)。

marketplace.visualstudio.com

私も10くらいしか入れていませんし、紹介するもので使っているものばかりではありませんが、参考になれば。

marketplace.visualstudio.com

作業項目の検索ができるようになる拡張機能です。今までと違い、日本語の検索もサポートしています。以前紹介したので、そちらもみてください。

kkamegawa.hatenablog.jp

marketplace.visualstudio.com

コード検索をサポートします。TFSの場合Elastic Searchを使っているので、おそらく似たようなものなのでしょう。メソッド名やシンボルといった区分で検索ができるようになります。

Work Item Visualization

marketplace.visualstudio.com

作業項目には親子関係がついていますが、それを視覚化して表示してくれます。メールに添付できるので、便利ですね。

Octopus Deploy build Release

marketplace.visualstudio.com

プラグインは無償ですが、Octopus自身は有償です。Octopus自身は有名なツールなので、大規模デプロイには便利だと思います…多分。

Docker Integration

marketplace.visualstudio.com

私自身がまだDockerそんなに使ってないのですが、MS標準ということで一応。ただ、まだWindows Containerはサポートしていないようです(レビュー欄より)。おそらく早晩サポートされるのでしょうが、Windows Containerを使うときは気をつけてください。

Release Annotations for Azure Application Insights

marketplace.visualstudio.com

Application Insightsのグラフに注釈というか、印をつけられるようになります。頻繁にデプロイしている場合、Application Insightsでエラーが出たタイミングでどのリリースだったかというのがわからなくなることがあるので、そういうケースで便利でしょう。

Azure DevTest Labs Tasks

marketplace.visualstudio.com

Azure DevTest Labsは最小限の操作で仮想マシンが作れる(しかも自動起動/シャットダウンのautomationを自動設定されている)便利なサービスです。そんなVMを管理するタスクです。

Generate Release Notes Build Task

marketplace.visualstudio.com

リリースノートって作るの結構面倒ですよね。そういう作業を自動化してくれるそうです。実は使ったことがないのですが、ちゃんと書くようなものを作る場合は使おうかなと思っています。

Export/Import Build Definition

marketplace.visualstudio.com

似たようなビルド定義を作るという作業はよくあります(ブランチ違いとか、チーム違いとか)。Task Groupという機能で複数のビルドタスクをまとめられるようになりましたが、異なるチームで似たようなタスクを取り込み/入力したい場合便利ですね。

TFS artifacts for Release Management

marketplace.visualstudio.com

一台のVSTS/TFSで完結していればいいのですが、そうでないことは結構あります。組織内のTFSを使って、クラウドのサービスにリリースするというとき、直接繋げず、VSTSを経由したいというような場合です。

SonarQube

marketplace.visualstudio.com

MSが最近力を入れている品質管理系のオープンソースソフト(商用版もある)SonarQubeの拡張機能です。もともとMSがVSTS組み込みで提供していたものがあったのですが、そちらは廃止になるようです。組み込み版ではVSTS内で品質情報が見えるようになるそうです。

StyleCop Runner Build Task

marketplace.visualstudio.com

StyleCopを実行するビルドタスクだそうです。そういうもの

LaunchDarkly Integration

marketplace.visualstudio.com

DevOpsの要素の一つであるFeature FlagをサポートするLaunchDarklyの拡張機能です。拡張機能は無償ですが、LaunchDarklyは有償です(結構いいお値段します)。VSTS自身のリリースでも使っているようですね。

blogs.msdn.microsoft.com

Pester Test Runner Build Task

marketplace.visualstudio.com

PowerShellのテストフレームワークとしてPesterというツールがあります。このPesterを実行するタスクですね。

VSTS Kudu Tasks

marketplace.visualstudio.com

IIS/App ServiceへのデプロイはWebdeployを使う例が多いと思いますが、バックエンドで動いているKudoのAPIを使うこともできます。そんなKudoのAPIを使ってデプロイするタスクですね。デプロイ前にはWebdeployではないけど、zipでパッケージにしておかないといけないようです。

ストア関係

marketplace.visualstudio.com

marketplace.visualstudio.com

marketplace.visualstudio.com

MS,Apple,Googleのストアにリリースするためのタスクですね。

TeamCity artifacts for Release Management

marketplace.visualstudio.com

JetBrainsのTeamCityのartifacts(成果物)をVSTSのRelease Managementで使うための拡張機能です。

まとめ

VSTSには色々拡張機能が提供されていて、多様なニーズが充たせると思います。みんなそんなに入れていないようですが、便利な一本を見つけて、使ってみてください。いいもの見つけたらレビュー書いてみてください。

Visual Studio Team ServiesのREST APIを使ってみる(24日目)

はじめに

今日はちょっと趣向を変えて、VSTSのREST APIを使う方法を紹介します。C#で作ってもいいのですが、今日はPowerShell AdventCalendarと相乗りカレンダーということで、PowerShellで使う方法を紹介します。

私が毎回紹介しているVSTSの翻訳はVSTSにmarkdownの下書きを書いていて、出来上がったらGistに送っています。いいかげん自動化しようと思っていたので、ちょうどいい機会なのでやってみます。どっちかといえば、Gistへの更新のほうが悩みました…。ちなみに、Gistへの登録であれば、PSGistというモジュールがScript Gallaryに公開されています。

www.powershellgallery.com

最初はこれを使おうと思ったのですが、GitHubのパスワードをOSの資格情報マネージャーに記録する方法だったので、残念ながら自動化(Hosted AgentでのCI)には使えません。そのうちforkして改造しようかと思います。

PowerShellからGitHubへのアクセスを解説している動画がChannel9にあるので、こちらもみてください。

channel9.msdn.com

今回はパスワードでの認証ではなく、PATを使うので、PowerShellからGist(GitHub)にアクセスするためのPATを取ります。動画中でも解説されているので、詳しくは省きますが、Gistの権限があればいいはずです。

VSTSのファイルをコミット履歴から取得する

www.visualstudio.com

VSTSのHosted Agentでアクセスするために認証にはPATを使いましょう。最長で1年ですので、忘れたころに更新することになりそうですが。

www.visualstudio.com

  1. 直近のコミットを取得する
  2. コミットの詳細情報を取得する
  3. 変更されたファイルを取得する

という流れになります。3番目の手順で変更一覧が取得できるので、そのitem.pathプロパティにファイル名が入っています。ファイル名をGist側と突き合わせます。

www.visualstudio.com

実はここから時間切れでできてないのですが、指定したファイルをoctect/streamで取得して、gistにアップロードします。

Gistの取得

Gistの取得は簡単です。指定ユーザーのGistを取ってくるAPIたたくだけでいいのですが、ファイルがあるかどうか探すのはちょっと面倒。

Gistの一覧にはFilesコレクションがあり、各ファイルがいわゆるハッシュのキーになっています。なので、Filesコレクションの各ファイルオブジェクト($gistfileオブジェクトに入っているとします)のNotePropertyを取得することでGistのファイル名を取得します。

$gistfile | Get-Member -MemberType NoteProperty | select Name

VSTSのコミット履歴(changeTypeプロパティ)がaddであれば、追加。"edit"であれば、編集となっています。この辺は私の使い方ではaddしかない(masterブランチへのpull requestで追加のみ)はずなので、どうしようかなーと思っているところです。

途中段階のソース

とりあえず上記のフローで書きなぐったのが以下のソースです。あとは判定のテストと、ファイルアップロードができればいいので、お正月中に何とかしようと思っていますw。

RESTあまり使っていなかったのですが、便利ですね。VSTSもこれからはREST APIが強化されるでしょうから使ってみてください。

Copy from VSTS Git Repository to public Gist. It d ...

プログラマ的にWindows 10 Anniversary Updateのうれしいところ

10個あるかな、と思ったのですが、今のところ思いついたものをあげてみました。うーん、まだあるはずなんですが。とりあえず、つらつらと書いてみます。Inkとかは純粋にプログラマ向けとしてどうかなーと思って、あえて入れていません(ぉ)。

他にもお気に入りの機能があれば紹介してください。

Docker互換のコンテナ

言わずと知れたこれですね。Docker for Windowsを使えば現在でも使えます。

docs.docker.com

ただ、こちらはHyper-VでLinux仮想マシン(初期で2GB )が動くので、少しメモリがきつい。なによりもWindowsで動くコンテナであればWindowsネイティブの機能を使うことになります。

msdn.microsoft.com

コマンドはdockerコマンドで共通のようです。PowerShellコマンドレットも用意されるようですが、基本はdockerコマンドで、詳細な情報を見たいときはPowerShellという住み分けになるようです。

MAX_PATHが260バイトの制限から解き放たれる

実は今までもファイル名のprefixに\\?\とつけて、UnicodeでコンパイルしたWin32アプリケーションであれば、64KBまでのパスを使えることができました。しかし、ExplorerがWindows 95時代からのANSIモードで動いていたり、世の中MAX_PATHが260バイトという決め打ちで動いていたり、.NET FrameworkもWindows 95とかを引きずっていた都合上、最大パスは260バイトまで、となっていました。

Anniversary Update以降、グループポリシーでEnable NTFS long pathsを有効に設定すれば、Win32アプリケーションでも有効になります。もちろん、MAX_PATHが260と決め打ちしているような大多数(99.9999%くらい?)のアプリケーションに長いパスを与えると即死、もしくはバッファオーバーフロー起こすので、十分評価してからにしましょう。

betanews.com

Desktop ConverterでWin32/.NETアプリケーションの簡単展開

既存の.NETアプリケーションやWin32アプリケーションにUWPのガワだけかぶせて、ストアでより簡単に配信ができるようになるというDesktop Converterです。間違えないで欲しいのは、あくまでも「ストアに公開できるようになる」というだけで、「UWP化される(mobileやXBoxで動くようになる)わけではありません

ただし、何でもかんでもコンバートできるわけではなく、制限があります。特にVisual C++ランタイムと.NET Frameworkが限られるので、古いVCランタイムを使っているアプリケーションの場合、一度移行してから、ということもあるので、注意してください。

Convert your desktop application to a Universal Windows Platform (UWP) app

UACで特権昇格が必要なアプリや、他のアプリと連携する(AppDataに書き込む)ようなアプリがダメ、というのはややきついものの、大多数のアプリケーションでは問題無いでしょう。ただし、その前にインストーラーでインストールされるようなアプリケーションでなくてはなりませんが。

インストーラーがないようなアプリの場合、コンテナ使うしかないですかね。

ネットワークが高速化

ネットワークは門外漢ですが、Linuxなどではすでに対応している新しいRFCもしくはドラフトの規格に対応しているそうです。TFOとかは素人目に見ても頻繁にopen/closeするようなサーバにアクセスする場合の高速化が見込まれると思われます。

blogs.technet.microsoft.com

PowerShell (WMF 5.1)

WMF 5.1 リリース ノート (プレビュー)

Bashに持って行かれた感がありますが、Windows における自動化、スクリプトでの運用管理を行いたい場合はWMF(PowerShell)なのは変わりません。いろいろ聞かれましたが、Bashは(今のところ)Windows 10を開発者モードに変更しないと使用できません。つまり、Bashは管理者がシステム管理のために使うのではなく、あくまでも開発者向けのツールセットの一部となっています。

PowerShellはWindowsクライアントおよびサーバの管理、自動化のためのものです。

PowerShell 5.0 にあったバグや、高速化、PowerShell DSCをはじめとした機能強化が盛りだくさんです。

.NET Framework 4.6.2

先ほどWin32アプリケーション向けの長いファイル名を扱うようにする設定を紹介しましたが、.NETの場合はapplication manifestに指定することにより、プロセス単位で制御することが可能です。

<?xml version="1.0" encoding="utf-8" ?>  
 <configuration>
  <runtime>
    <AppContextSwitchOverrides value="Switch.System.IO.UseLegacyPathHandling=false;Switch.System.IO.BlockLongPaths=false" />
  </runtime>
</configuration>

.NET Coreおよび、.NET Framework 4.6.2がインストールされたWindows 10 Anniversary Update(1607)で有効だそうです。

blogs.msdn.microsoft.com

長いファイル名の他にもモニタごとのDPIを認識するようになったとか、新しい暗号化に対応したとか、着実な強化が行われています。

blogs.msdn.microsoft.com

Bash on Ubuntu on WindowsでツールセットがLinux共通に

//Build 2016での話題は間違いなくこれだったでしょうね。cygwinとかもまぁいいのですが、なんとなくもどかしさを感じていました。PowerShellのすべてがオブジェクトになるというのは.NETなどの相互運用で大変便利です。

しかし、他のプラットフォームの方に使ってもらおうとする場合、そのへんが足かせにもなっていました。移行のためにコマンドレットにエイリアスを登録されているものもある(lsやwgetとか)のですが、結局オプションが違うから使わないんですよね。

あと、長いファイル名の扱いも、UnicodeアプリであったとしてもWindowsだから260バイト固定とかになっているものも少なからずあり、困っていました。node.jsもしばらく困ったなぁ…。

しかしそんな時代もさようなら。パスさえ少し考慮すればUbuntuで動いているものがまぁ大体動くようです。もちろんまだ実装されていないシステムコールや実装されないであろうシステムコールもありますが、コマンドラインの開発用ツールセットは割りと動くようですね。

blogs.msdn.microsoft.com

詳細な仕組みなどは上記のブログで。もしも困る場合はGitHubにissueをたててみればいいようです。

github.com

UWPアプリのバックグラウンド実行サポート

通知ではなく、バックグラウンドで実行したいような場合よさそう?

blogs.windows.com

Windows Server Coreの初期設定を行う

PowerShellだけでやろうかと思っているので、たぶんWindows Server 2012 R2以降じゃないとできないはず。まだやってる最中なので、適宜追記予定。

コンピュータ名の変更

Rename-Computer -NewName 2016tp5 -ComputerName .

これで2016tp5というコンピュータ名に代わる

Active Directoryドメインに参加する

Add-Computer -DomainName CONTOSO -Restart

Contosoドメインに参加する。ドメイン参加するための認証ダイアログが表示されるので、適宜入力。-Credencialを指定するとその認証を使ってくれる。

リモート管理を有効にする

コマンドプロンプトから

Winrm qc

PowerShellで

Set-Item WSMan:\localhost\Client\TrustedHosts * -Force

これで enter-pssession コンピュータ名 -Credential administrator などでリモート管理可能になります。

システムロケールを英語に変更(英語版を入れた人は不要)

set-WinSystemLocal en-us
restart-computer

なぜかといえば、現時点ではコンテナは英語じゃないとうまく動かないものがあまりにも多いため。

Windows コンテナをインストール

TP5の場合、この記事参照。

Getting started with containers and Docker on Windows Server 2016 Technical Preview 5 | Julien Corioland – Microsoft Azure Technical Evangelist

最初にWindows Containerの機能をインストールするが、その際一度再起動が実施される。再起動前にdockerクライアントはインストールされないため、このスクリプトを二回動かす必要がある。

powershell.exe -NoProfile C:\Install-ContainerHost.ps1

firewallの設定

(以下Todo)

  • Hyper-Vリモート管理を有効にする
  • Hyper-V 管理クライアントを有効にする
  • Firewallリモート管理を有効にする
  • 「仮想マシンの監視」リモート管理を有効にする

この辺で一通りできるようになるかな。

Azure DevTest Labsでテスト用仮想マシンを作るべき理由

Azure DevTest Labs | Microsoft Azure

まだプレビューですが、Azure DevTest Labsというサービスがあります。これはテスト用の仮想マシンの作成と管理に特化したサービスです。Azure 仮想マシンほど細かくいろいろ設定することはできないのですが、その分かなりお手軽になっており、ARMで作る仮想マシンと比べて以下のような利点があります。

テンプレートが異様に短い

最低限の仮想マシンでも大体これくらいです。診断の拡張機能や初期設定をしようとPowerShell DSCの拡張機能を入れるともっと長くなります。

azure-quickstart-templates/azuredeploy.json at master · Azure/azure-quickstart-templates · GitHub

対して、DevTest Labsで作る仮想マシンテンプレートはこんな感じ。実はこれでGitとAzure PowerShellが入ります。

Azure DevTest Labs Deploy sample script

PowerShell DSCを使わなくてもいろいろ入る

PowerShell DSCでリソース使えばもちろんいろいろ入るのですが、Azureで試行錯誤するのは結構大変です。DevTest Labsではデプロイ時についでにいくつかのソフトを追加できます。Chocolatyを指定できるので、パッケージを入れることや、Gitのリポジトリクローン、PowerShellスクリプトの実行、VSTSのdropフォルダのコピーとか便利ですね。

f:id:kkamegawa:20160405052244p:plain

JSONだとこの辺。

https://gist.github.com/kkamegawa/bfb437684d56f05bfa99308a6ca4f9ad#file-windowsvirtualmachine-json-L60

自動運転が最初から入っている

azure.microsoft.com

Azure Automationを使えば自動運転を設定することができますが、DevTest Labsでは最初から設定することができます。

f:id:kkamegawa:20160405052245p:plain

停止し忘れてクラウド破産とか(あるていど)防げそうです。通常は日中の自動運転でしょうが、例えば夜間に自動テストしたい、というような場合は夜間にのみ動くLabを作ればいいでしょう。

コスト上限の設定

仮想マシンを無制限に立てられると同じくクラウド破産になりそうですが、あらかじめユーザごとにいろんな上限を設定することができます。

  • 仮想マシン数
  • 仮想マシンのサイズ
  • DevTest Labs単位での仮想マシン数上限

まだ残念なところ1 - Visual Studioからの配置ができない

そのうち直るんでしょうが、残念ながらAzureのQuickStartから仮想マシンのテンプレートを流用して作った場合、配置ができません。Visual Studioの配置でStorageアカウントを指定するところがあるのですが、こんなのいらないので、削除したら配置ができなくなりました(てへっ)。

PowerShellから実行すればいいので、そんなに困りません。CIも大丈夫のはずです。

まだ残念なところ2 - Visual Studioのテンプレートがない

uservoiceに上がってるし、事実上New-AzureRmResourceGroupDeploymentひとつ発行するだけでいいので楽なんですが、やっぱり作ってほしいですねぇ。あと、テンプレートはDevTest Labsから仮想マシンを作ってView Templateでみればわかると思います。

まとめ

いくつかちょっと難しいとところもあるけど、ARMのテンプレートが圧倒的に小さく、追加インストールするソフトがある場合は助かります。テスト用の仮想マシンだとそんなに難しいものはいらないので、今後はこのDevTest Labsに仮想マシンを作っていこうと思います。