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

kkamegawa's weblog

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

VSTSのタスクをFlowでMicrosoft To-Doのタスクと連携する

Microsoft To-Doが発表される前から、VSTS/TFSに登録されたタスクをOutlookにも反映させたいと思っていました。実はそういうアドオンは海外には結構あります。MSDNの特典にもあるSmartOutlook4TFSなんかがそうですね。

www.modernrequirements.com

でも、せっかくオンラインのサービスでRESTのAPIがあるから何とかしたいと思っていました。Microsoft Flowを使えばコーディングレスで連携できることに気づいてやってみたら、できたのですがいくつか課題も分かりました。

とりあえずタスクが連携するのは便利です。使う方の参考にどうぞ。

flow.microsoft.com

Flowのサインアップはこちらから。MSアカウントでもOffice 365アカウントでもどちらでもいいです。連携するoutlookやVSTSのアカウント種別で判断すればいいでしょう。私はMSアカウントで作ってみました。

f:id:kkamegawa:20170518172020p:plain

タスクでVisual Studioを検索します。When a work item is assignedを選択します。

f:id:kkamegawa:20170518172015p:plain

アカウントはMSアカウントであれば自動的に認証されているVSTSのアカウントが出てきます。プロジェクト名を選択して、"assigned to"を選ぶと、「必要なパラメータがー」云々、と出てきます。

f:id:kkamegawa:20170518172009p:plain

これ、実は一つ下のTeam to lookup member fromを「先に」選ばないといけないんですね。必須項目ではないのに選ばないと必須項目が選べないのは注意してください。

f:id:kkamegawa:20170518172003p:plain

ここではプロジェクトの中にあるチームを選びます。チームを選ぶことでチーム内のアカウントを列挙するという動作です。

f:id:kkamegawa:20170518171956p:plain

詳細オプションを選択すると、もうちょっと広がります。Area PathやIterationは大規模な場合便利かもしれませんが、ここではTypeに「タスク」のみ指定します。プロダクトバックログやフィーチャーをもらってもToDoで管理できるものでもないですしね。

f:id:kkamegawa:20170518172129p:plain

Microsoft ToDoの実態はOutlookのタスクを見せているだけです。なので、アクションでOutlook Tasksを選びます。

f:id:kkamegawa:20170518172122p:plain

次はVSTSのタスクの内容をOutlook側に転記します。

f:id:kkamegawa:20170518172111p:plain

で、VSTS側にタスクを登録すると、こんな風にちゃんと連携しますね。

f:id:kkamegawa:20170518172105p:plain

しめしめ…と思って、ToDoを見ると…あれ?1601/1/1が期限?

f:id:kkamegawa:20170518174016p:plain

実はこれ、OutlookのタスクのDue Date(締め切り)やStart Date(開始日)に日付が入っていないからなんですね。そして、この日付にふさわしい日付はVSTSからは出てこないのです(残念)。とはいえ、1601/1/1ってのはちょっとないので、こんな風にcreated dateを代わりに入れてみました。

もちろんVSTS側としては管理できる項目ではあるのですが、標準のプロセステンプレートの入力項目としては出てきません。

VSTSのプロセステンプレートをカスタマイズするか、入力フォームで明示的に入力項目として出すことはできます。

kkamegawa.hatenablog.jp

以前のアドベントカレンダーで書いた時よりさらに簡単になっています。

これはタスクがアサインされたときに連携しています。できれば次はToDoでクローズしたら、VSTS側もクローズさせたいものです。

VSTSのタスクには固有のURIがあるので、それをタスクのdescriptionなどに書いておいて、切り出し→FlowでREST API呼び出しという手順になるかと思います(できたら紹介します)。

では楽しいToDo & VSTSライフを!

Visual Studio Team Services 2017/5/11の更新

遅くなりましたが、Sprint 117, 5/11のVSTSリリースノートの翻訳を行いました。オリジナルはこちらから読んでください。

www.visualstudio.com

5/15更新となっていますが、同じ文章が二回明らかに出てはいけないところに出ていたので、なおしてもらったためです。今回はちょうど//Buildに重なったこともあって、//Buildでも今回のスプリントの強化項目の一つ、CI/CD関係のセッションが多くあったようです。VSTSに限らず、JenkinsなどのOSSを使ったものもありました。

channel9.msdn.com

channel9.msdn.com

channel9.msdn.com

channel9.msdn.com

channel9.msdn.com

channel9.msdn.com

今回はいくつかの新機能がプレビューを卒業して、一般提供開始されたこと、XAMLビルドコントローラーがとうとう(本当に)提供中止になること、Visual Studio 2017を使用する場合のホストエージェントの選択基準の仕様変更といった重要なアナウンスもありますので、ぜひ見ておいてください。Visual Studio 2017をすでにバリバリ使っている人は手順が省略されるだけなので、たいして影響はないと思います。

ではまた三週間後。

translate to Japanese to VSTS release notes from h …

VSTSのビルドが成功しているのに失敗と表示される?

ある日のこと。仕掛けたLambdicSQL for SQL Serverのビルドがどうなっているかな?と思ってビルドステータスをみてみました。

f:id:kkamegawa:20170511061751p:plain

あれ?失敗なのに直近のビルド履歴は成功???実はこのStatusという欄は正確には「My Build Status」の略です。

つまり、「自分がリクエストした直近のビルド結果」を表しています。

f:id:kkamegawa:20170511061749p:plain

で、ビルドのSummaryを見てみると「Passing」ですね。つまり成果物(artifact)はできています。じゃあこれ誰がビルドしたの?ということですが、下の赤枠。

Microsoft.VisualStudio.Services.TFSつまり、なんらかのビルドトリガーでVSTSが自動的にビルドした結果なんですね。今回の場合はSchedule Buildです。

f:id:kkamegawa:20170511061750p:plain

StatusとはMy Build Statusのことと書いたので、試しに別のアカウントで見てみると、StatusはSucceededになっています(ちなみにこのアカウントではビルドしていないんだから無印が正解だと思うんですが)。

この挙動はちょっとわかりづらいので、フィードバックしています。

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のテストだけ実行されます。

VSTSでASP.NET CoreアプリのCI/CDを行う

はじめに

以前、VSTSとAzure App ServivesのCI/CDの話を書きました。

kkamegawa.hatenablog.jp

今はちょっとやり方が変わっているので、改めて紹介します。VSTSで書いていますが、基本はJenkinsやTFSでも変わりありません。

Build定義作成

VSTSのビルドテンプレートからVisual StudioもしくはASP.NET(Preview)を選んでください。

f:id:kkamegawa:20170505133249p:plain

dotnet restoreコマンドでもいいのですが、せっかくテンプレートに入っているNugetタスクを使います。重要なポイントとして、必ず、3.5以上を選択してください。ここでは4.0にしています。

NuGet 4.0はHosted VS2017であれば入っています。

f:id:kkamegawa:20170505133251p:plain

Visual Studioタスクで使用するVisual Studioを必ずVisual Studio 2017にします。

f:id:kkamegawa:20170505133218p:plain

Azure App Serviceへのデプロイにwebdeployを使うので、dotnet publishコマンドを使用します。引数に以下の値を指定します。

publish -c $(BuildConfiguration) -o $(Build.ArtifactStagingDirectory)

これで、ビルド構成(Release, Debugなど)でビルドした結果を -o で指定された出力先にコピーします。ArtifactStagingDirectoryでエージェントの中間生成領域です。

f:id:kkamegawa:20170505133220p:plain

WebDeployはzipファイルなので、ArtifactStagingDirectoryに出力した内容をzipファイルに圧縮します。

f:id:kkamegawa:20170505133221p:plain

生成されたzipファイルをリリース機能でデプロイするための領域にコピーします。

f:id:kkamegawa:20170505133225p:plain

Optionsの中にあるAgentsで必ずHosted VS2017を選んでください。これで準備完了です。

Release機能を使う

f:id:kkamegawa:20170505133223p:plain

リリース定義を作成し、App Serviceへのリリース用の環境を作ります。ここではJapan Westを作りました。

注意点として、Stagingスロットを作っていない場合、一度App Serviceをstopで止めてから入れ替えしないといけないようです。確かこれはASP.NET Coreのissueにも挙がっていた気がします。

止めて、デプロイしてから再度startタスクを実行します。容量にもよりますが、それなりに時間がかかるので、Staging作ってswapさせたほうがいいように思います。

成果物の受け渡しに関しては、以前の記事などを参照してください。

Visual Studio Team Services 2017/4/19の更新

VSTSの4/19のSprint 116(のはず)のリリースノートの参考訳を作ってみました。オリジナルはこちらから読んでください。

www.visualstudio.com

Gitのコミットグラフ、node.jsの複数バージョンの検証、ログの強化、iOS/Google Playへのリリース機能強化、拡張機能をリリースしている人にはダッシュボードの強化となかなか便利そうなものがそろっています。Gitのコミットグラフは私のテナントにも来ていたので、使ってみましたが、なかなかみやすくなっています。

ではまた三週間後。

translate to Japanese to VSTS release notes from h …

VSTS/TFSで並列リリースを行う

www.visualstudio.com

VSTSにはビルドとリリース機能があり、それぞれ継続的インテグレーションと継続的デリバリーを支援します。これらにはMSが提供するエージェント(Hosted Agent)と自前で用意するエージェント(Private Agent)の二種類があります。

エージェントはそれぞれキューと呼ばれる単位で実行が制御されます。一つのキューに対して一つのジョブしか投入できません。

www.visualstudio.com

このページ内の図がわかりやすいですかね。そして同時に投入できるキューはライセンスで制限されています。Build and ReleaseのResource limitsで確認できます。

f:id:kkamegawa:20170425064708p:plain

初期状態では一つのパイプラインのみ使用できます。追加する場合、Marketplaceで購入します(Changeをクリック)。Marketplaceで購入できますが、MSDNの場合、サブスクリプションの上限解除を設定しないと購入できないので、注意してください。請求はAzureにまとめられます。

Office 365やAzureを組織で導入していて、既存のVSTSのサブスクリプションの支払いをOffice 365の組織アカウントに変更したいという場合、やや大変な手順で変更しないといけないので、注意してください。

www.visualstudio.com

パイプラインが2以上になると並列デプロイができるようになりますので、ここではVSTSが提供しているHosted/Hosted VS2017/Hosted Linuxを使ってやってみましょう。まず、Azure Web Appを複数のリージョンに作成しておきます。エージェントを切り替えるには"Run on agent"をクリックします(ここちょっとわかりづらい)。

f:id:kkamegawa:20170425064705p:plain

Japan EastへのデプロイにはHotedを選択します。

f:id:kkamegawa:20170425064706p:plain

Japan WestへのデプロイにはHosted VS2017を選択しています。

f:id:kkamegawa:20170425064707p:plain

Create Releaseを実行すると並列でのリリースが開始されます(IN PROGRESSになってます)。

f:id:kkamegawa:20170425064709p:plain

終わるとこんな感じ。一つFAILEDになってますが、それはHosted Linuxエージェント使ったからです(.NET Coreアプリなんでできると思ったけど甘かった)。

f:id:kkamegawa:20170426065305p:plain

ちなみにオンプレミスのTFSでも(リリースのUIはちょっと違いますが)大体同じです。こちらはVisual Studio Enterprise保有者の数および、VSTSと同様にMarketplaceで購入した数が上限になります。

…というデモをこの前のGlobal Azure Bootcamp @ Kansaiでやりたかったんです(時間切れ)。