kkamegawa's weblog

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

Visual Studio Team Services CI/CDアドベントカレンダー:ビルド/リリースで使う環境変数を見る(23日目)

はじめに

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

qiita.com

ビルド・リリースで実行するエージェントで参照できる値がいくつか定義されています。

docs.microsoft.com

ここに載ってはいますが、実際にどう定義されているのかという情報を眺めてみましょう。

方法

非常に簡単です。ビルド定義を作って、PowerShellで定義済み環境変数を列挙して表示すればいいだけです。

f:id:kkamegawa:20171223220901p:plain

こんな風にPowerShell Scriptのインラインタスクで[environment]::GetEnvironmentVariables()を実行するだけです。もちろん、ソースのpullが発生しないように、昨日同様、Don't sync sourceにチェックを入れてください。

f:id:kkamegawa:20171223220900p:plain

実行するとこんな感じです。スクロールすると、どんな値が定義されているか調べられるでしょう。

これを見て、実際にどんな値が定義されているか確認してみてください。

今日は簡単ですがこの辺で。

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昨日のほうは紹介できませんでしたが、たぶんほぼ変わらないはずです。

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