kkamegawa's weblog

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

Visual Studio Team Services CI/CDアドベントカレンダー:App Centerとの連携(24日目)

はじめに

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

qiita.com

最近モバイル開発もよく聞くようになっていますというか、全盛時代ですね。私自身はあんまり…なのですが、一通りくらいはやっておかないとなぁということで、App Centerとの連携を試してみることにします。

サインアップ

f:id:kkamegawa:20171224223220p:plain

サインアップはGitHub/MSアカウント/Facebook/Googleもしくは独自アカウントで可能です。私はMSアカウントでやってます。

VSTSとの接続

VSTSとの接続にはAPI Keyを使います。App Center側で専用のAPI Keyを作り、VSTSのチームプロジェクトに登録します。

f:id:kkamegawa:20171224223210p:plain

API TokensからNew API tokenをクリック。

f:id:kkamegawa:20171224223211p:plain

わかりやすい名前と、アクセス権を設定します。VSTSからApp Centerに発行する必要があるので、Readではダメなので、Full Accessを選択します。

f:id:kkamegawa:20171224223212p:plain

API Keyとなるランダム文字列が生成されるのでコピーします。次はVSTS側の作業です。

f:id:kkamegawa:20171224223209p:plain

ServicesからNew Service Endpointをクリックして、Visual Studio App Centerをクリック。

f:id:kkamegawa:20171224223213p:plain

App Centerのtokenに先ほどコピーしたAPI Tokenをペーストして、OKを押します。

f:id:kkamegawa:20171224223214p:plain

ロゴの色が古いですが、気にせずこれでOKです。

App Centerのプロジェクト作成

App Centerはアプリ単位ではなく、バイナリー単位でプロジェクトを作成します。Visual Studioでソリューションを作った場合、複数のプラットフォーム向けのプロジェクトが一つになりますが、App Centerは別なので気を付けてください。

f:id:kkamegawa:20171224223216p:plain

iOS/Xamarinでプロジェクトを作ります。

f:id:kkamegawa:20171224223217p:plain

ビルドにVSTSにあるソリューションを使おうとする場合、Visual Studio Team Servicesを選んで接続すればいい…と思うのですが、ここから接続すると、なぜかAzure ADで認証するVSTSが自動的に選ばれてしまいました。まとめるとこうです。

  • Windows 10はAzure AD(Office 365)に接続(SSOではない)している
  • MSアカウントでも接続している
  • Azure ADで認証しているVSTSもある(去年のアドベントカレンダーで作ったから)
  • しかし、VSTSはMSアカウントのものを使いたい
  • 認証でなぜかAzure AD側のVSTSが自動的に選ばれた

うがー本来OAuthでMSアカウント側のVSTSに接続したかったのですが、頓挫しました。ちなみに、issue trackerからVSTSに接続する場合、ちゃんとMSアカウントのVSTSが選択できました。なんだそれ。

f:id:kkamegawa:20171224230531p:plain

こんな風にissue trackerにはMSアカウントのVSTSが選択できます。ちなみに、Azure ADのVSTS側から、App Centerの認証を取り消してしばらくまってください。

この現象はEdgeだと発生するので、Azure ADを使っている人がMSアカウントのVSTSに接続するときはChromeやFirefoxを使うことを推奨します。

VSTSでのビルド定義

VSTSのビルド定義にはApp Centerでテストする、App Centerに登録するといったタスクが用意されています。

f:id:kkamegawa:20171224223215p:plain

Xamarin.iOS/Xamarin.Androidのテンプレートがあるので、そこから作っていきます。このへんはXamarinになれた方のドキュメントを見たほうがいいと思います。

f:id:kkamegawa:20171224223219p:plain

App Centerへのデプロイですが、ちょっとややこしいですね。App CenterのURLに含まれる appcenter.ms/{username}/app/{appname} の{username}/{appname} 形式になります。

docs.microsoft.com

この辺はまだよくわからないです…

App Centerでビルド

認証キャッシュが切れたようなので、Chromeで再度接続してみたら、MSアカウント側のVSTSに接続できました。やってみたらさらに簡単ですね。

f:id:kkamegawa:20171224223221p:plain

Configurationがデフォルトdebugでした。VSTSではReleaseがデフォルトなのに意外と思ってしまいました。

VSTSのビルドタスクではリリースノートが必須項目だったのですが、App Centerにはないですね。apkのサインとかいろいろ楽になっています。

f:id:kkamegawa:20171224223222p:plain

手動でビルドしてみます。

f:id:kkamegawa:20171224223223p:plain

ログを見る限り、VSTSのLinux Hosted Agentが動いているようです。おそらくOSごとに違うエージェントが動いているのでしょう。

こんな感じであっさりビルドできてしまいました。XCodeなどは試せていませんが、おそらく同程度にできるのでしょう。

ビルド時間はVSTSと同様に240分無償のようですが、これ別計算なんですかね…VSTSと同じエージェント使っているんだから、VSTSの枠でやってくれたら料金も一緒になっていいんじゃないかなとは思います。

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アドベントカレンダー:Jenkinsと連携する(22日目)

はじめに

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

qiita.com

以前コードレポジトリの連携でGitHubを紹介しましたが、今度はビルドの連携でJenkinsを紹介します。

Serviceを設定する

VSTSからJenkinsを呼び出すにはふた通りのやり方があります。

  • Service Hookを使う
  • Service登録する

前者のService Hookは昔からある方ですね。今は後者のServiceを登録する方を押しています。Jenkinsのビルドタスクが用意されていますが、Serviceに登録されているエンドポイントを参照します。

f:id:kkamegawa:20171222221103p:plain

New Service EndpointからJenkinsを選択します。

f:id:kkamegawa:20171222221059p:plain

URL、ユーザー、パスワードを指定して、Verifyを実行して、Connectionが成功であればOKです。

f:id:kkamegawa:20171222221100p:plain

こんな風にService EndpointにJenkinsアイコンが出ていれば問題ありません。次はビルド定義を作りましょう。

ビルド定義作成

次はビルド定義を作ります。一つ注意点として、Jenkinsでソースの取得を行うので、デフォルトのソース取得を無効にしておきましょう。大きいプロジェクトだと無駄に時間がかから無くなります。

f:id:kkamegawa:20171222224527p:plain

このDon't sync sourceをチェックしておきましょう。

f:id:kkamegawa:20171222221101p:plain

Jenkinsのビルドタスクは二つ用意されています。

  • Jenkis Queue Job
  • Jenkins Download Artifacts

前者はJenkinsに定義したビルドキューを実行する、後者はJenkinsでビルドしたArtifactsをVSTSにダウンロードするというものです。どちらがビルドよう、リリース用ということはありません。Jenkins→VSTSと行ったビルドパイプラインでもいいでしょう。

f:id:kkamegawa:20171222221102p:plain

Queue Jenkins Jobを登録して、保存すると、Jenkinsのビルドジョブが呼び出せる…はずなのですが、投入はできるものの、404エラーになってしまいました…Blue Oceanで作ったビルドパイプラインを呼び出しているだけなのですが、よくなかったのかな。

リリース定義を作る

リリース定義を作ります。artifactの取得はリリース定義からと、ビルドタスクのいずれでも可能です。

f:id:kkamegawa:20171222230701p:plain

ArtifactのソースにJenkinsを指定して、サービスとジョブを指定すればArtifactsとして使用できます。

f:id:kkamegawa:20171222221107p:plain

もしくは、ビルドタスクで明示的にJenkinsのビルドタスクから取得するように構成します。こちらを使う場合、手動でリリースキューを実行することになるでしょう。

Service HookでJenkinsを構成する

Service Hookもまだサポートされています。Service Hook からServicesの一覧にあるJenkinsを選びます。

f:id:kkamegawa:20171222221105p:plain

Triggerからレポジトリ、ブランチ、コミットした人の設定を行えば、コードがコミットされるごとにJenkinsを呼び出すことができます。

f:id:kkamegawa:20171222221106p:plain

まとめ

Jenkinsに慣れている人(私以外w)は無理にVSTSのビルド機能を使わなくてもJenkinsを使い続けても大丈夫です。

.NET CoreにしてからがJenkinsでビルドしているようですしね。

Visual Studio Team Services CI/CDアドベントカレンダー:ダッシュボードでビルド/リリース状況を見る(21日目)

はじめに

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

qiita.com

今回はちょっと趣向を変えて、CI/CDの状態を見る方法について紹介します。個別の実行結果はSlackやTeamsに投稿すればいいのですが、全体の履歴としてみたい場合、ダッシュボードでぱっと見えると便利です。

VSTSのダッシュボードにはビルドやリリースの履歴、今何がどこに展開されているのかぱっとわかるウィジェットの貼り付けができます。全体表示させても便利です。

ダッシュボードの追加

Dashboardsの右端にある+をクリックすると、ダッシュボードの追加ができます。ダッシュボードの名前はわかりやすいものを付けてください。

f:id:kkamegawa:20171221185127p:plain

ウィジェット追加

ダッシュボードを作成してから、ウィジェットを追加します。拡張機能で追加するものを含めて、多くのウィジェットがありますが、CI/CDで関係あるもののみ紹介します。

marketplaceでウィジェットを探すとこれくらいあります。

marketplace.visualstudio.com

Chart for Build History

指定したビルド定義の所要時間、成功/失敗をチャートで表示するウィジェットです。重要なビルド定義を指定すればいいでしょう。

f:id:kkamegawa:20171221185128p:plain

チームプロジェクト内のビルド定義から履歴を表示したいビルド定義を選択します。一つのウィジェットに一つのビルド定義のみ設定できます。複数表示したい場合、ウィジェットを必要な数だけ登録してください。

f:id:kkamegawa:20171221185132p:plain

ビルド履歴はこんな感じで表示されます。バーが長いほどビルド時間がかかっています。途中伸びている項目がありますが、この時はなぜかHosted agentがものすごく遅かったためです。

f:id:kkamegawa:20171221185133p:plain

Deployment status

ビルド定義毎のビルド成果物がどの環境にリリースされているかという状況をクロス定義で見るためのウィジェットです。頻繁にデプロイするビルド定義が多いような環境では有用なウィジェットです。

f:id:kkamegawa:20171221185129p:plain

ビルド定義とViewを選択します。ViewはDeployment StatusTest Pass rateがあるので、お好みで。

ビルド定義と、ビルド定義の成果物が関連付けられているリリース定義を選択します。

f:id:kkamegawa:20171221185135p:plain

こんな感じで表示されます。何もやってないので、寂しいですが。

f:id:kkamegawa:20171221185136p:plain

Release Definition Overview

指定したリリース定義において、どのリリースがどの環境にデプロイされているか確認するためのウィジェットです。Chart of build historyのリリース版ですね。

f:id:kkamegawa:20171221185130p:plain

リリース定義を指定すると、現在の状況が表示されるので、問題なければこのままOKを押してください。

f:id:kkamegawa:20171221185137p:plain

Test Results Trend

ビルド定義、もしくはリリース定義で実行するテスト結果状況を表示するチャートです。テスト実行結果(成功/失敗)および、テスト実行時間もしくはその両方を合わせてチャートに表示できます。

f:id:kkamegawa:20171221185131p:plain

とりあえず簡単にテスト数を折れ線グラフにしてみました。全部成功(といっても2件ですが)しているので、100%のままです。

f:id:kkamegawa:20171221185138p:plain

完成

こうやってビルド、リリース関係のウィジェットを貼ったダッシュボードはこのようになります。ビルド関係が一目でわかるのでいいですね。

f:id:kkamegawa:20171221185139p:plain

もちろん、ビルド定義やリリース定義のカットでダッシュボードを作るとかでもいいでしょう。

ここでは紹介していませんが、Application Insightsを使っているのであればApplication Insightsのウィジェットを貼っておいて、常時モニターに表示しておくのもいいと思います。

残念ながらPower BIのVSTSコンテンツパックの提供が終わってしまいましたが、新しくODataでとってこれるようになったので、ODataを使って独自のチャートを作るのもいいかもしれません。

VSTS Analytics OData now publicly available – Microsoft DevOps Blog

Visual Studio Team Services CI/CDアドベントカレンダー:継続的モニタリングを設定する(20日目)

はじめに

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

qiita.com

継続的インテグレーション、継続的デプロイ(デリバリー)はよく聞いたことがあると思います。最近VSTSの開発で継続的モニタリングという言葉もでてきました。VSTSのリリーステンプレートにも入っています。

どんなものかちょっと見てみましょう(CI/CDじゃなかったのかという突っ込みは…)。

リリース定義の作り方

リリース定義にAzure App Service Deployment with Continuous Monitoringがありますので、選んでみます。

f:id:kkamegawa:20171221000909p:plain

二つEnvironmentがありますが、すでに一度作ったものに追加する形でキャプチャ撮ったので、スルーしてください。

f:id:kkamegawa:20171221000910p:plain

モニタリングのテンプレートから作った場合、以下の三つのタスクが定義されています。

  • Enable Continuous Monitoring
  • Configure Application Insights..
  • Azure App Service Deploy

これを見てわかると思いますが、「App ServiceにデプロイするついでにApplication Insightsを定義してやるよ」ということをリリース定義でやってくれるものです。Enable Continuous Monitoringは要はApplication Insights拡張機能を指定したWeb Appsに設定してくれるというものです。

f:id:kkamegawa:20171221000911p:plain

次のConfigure Application Insightsタスクで、Application Insightsの監視ルールが設定できます。実はこのタスクで作った場合、既定の設定が選択されているので、その設定をそのまま使っても構いません。

f:id:kkamegawa:20171221000912p:plain

  • Availability が99%を下回った場合
  • リクエスト失敗が5回より大きい
  • サーバーの応答時間が5秒より大きい場合
  • サーバーの例外が5回を上回った場合

ここでサブスクリプションの所有者、コントリビューター、読み取り権限のある人、その他指定した人にこのアラート条件を満たしたときにメールを送信する設定もできます(Subscription owners.. にチェック)。

これ以外の警告条件を指定したい場合もあります。Alert rulesの横をクリックして、条件設定をします。

f:id:kkamegawa:20171221000913p:plain

警告名、メトリクス、条件、閾値を指定します。余り警告が来てもあれなので、許容できる範囲を合意しておきましょう。

f:id:kkamegawa:20171221000914p:plain

メトリクスにはWebサーバーで大体要求されるような項目が入っていると思います。

f:id:kkamegawa:20171221000915p:plain

App Serviceのデプロイには特に問題はありませんね。

f:id:kkamegawa:20171221003044p:plain

実際これをリリースしてみると、Application Insightsの警告ルールに設定されています。

まとめ

Application Insightsにはメトリクスをとる機能と、ログを出力する機能があります。今まではどちらもVisual Studioのウィザードで設定することが多かったと思いますが、モニタリングに関してはCDのタスクで設定できるようになりました。

メトリクスルールもCDで構成できるので、これを仮に複数のリージョンに展開するとなったときでも既存のリリース定義から複製すればいいだけなので、Azureポータルでぽちぽち手作業するのにくらべて、間違いが起きなくなります。

また、リリースに含まれるので、アラートルールを変更する場合でもリリース定義を変えることにより、記録として残るので、とても便利だと思います。

使ってみてください。

Visual Studio Team Services CI/CDアドベントカレンダー:ビルド時のユニットテストと品質履歴を参照する(19日目)

はじめに

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

qiita.com

今まであまり触れてきませんでしたが、VSTSで単体テストを実施するとテストの成功率やカバレッジの記録が採取できます。これを履歴で見るとカバー率の履歴が分かります。どんな感じで表示されるのか、紹介します。

.NETでやっていますが、JavaであってもJaCoCoのコードカバレッジ形式に対応しているので、ほぼ同じことができるはずです。

テストタスクを構成する

Visual Studio Testというタスクがあるので追加します。設定できるところは非常に多いのですが、重要なポイントだけ解説します。

f:id:kkamegawa:20171219210210p:plain

vstestが認識するテスト結果のフォーマットを指定します。JUnit, NUnit, VSTest, XUnitが選択できます。

f:id:kkamegawa:20171219210208p:plain

テストアダプターのバージョンが特定のものでないといけない場合に指定します。通常はlatestで構いません。

setting fileはテストの実行時フィルタリングや明示的に設定を与えたい場合に指定します。通常、.runsettingsというファイルです。フォーマットはこちらを見てください。

.runsettings ファイルを使用して単体テストを構成する | Microsoft Docs

f:id:kkamegawa:20171219210209p:plain

テストを並列や複数のマシンで実行する設定です。ここはマルチフェーズビルドを実施する際に指定します。通常はチェックなしで構いません。

Run test in isolationはテスト実行時の分離モードを指定します。テストによっては指定しないと警告が出ますが、遅くなることがあります。

Code coverage enabledはコードカバレッジを取得します。ユニットテストであれば指定することをお勧めします。ただし、.NET Coreではまだコードカバレッジを採取する仕組みがないはずなので、実行しても無視されます(山のようにリクエストは出ています)。

f:id:kkamegawa:20171219210217p:plain

Select test usingにはTest assemblies, Test plan, Test runが選択できます。ユニットテストではTest assembliesを選択すれば自動的に対象の名前(Testsに一致するプロジェクトが生成するアセンブリ)をユニットテストと認識して実行します。

Test planはいわゆる自動テストです。Testハブからテスト計画を作ってテスト対象プログラムを自動実行します。

Test Runはテスト実行らしいのですが…どうも、テストの実行IDを指定して履歴を見るような感じなんでしょうか。まだ使ったことがないのですが、こちらを見てください。

Run automated tests from test plans in the Test hub VSTS and TFS | Microsoft Docs

テストは実行するだけでは品質データとして蓄積されません。Publish Test Resultsタスクを使ってVSTSに発行します。

f:id:kkamegawa:20171219210211p:plain

テスト計画を作る

Test Planを選択した時、TestハブでPlanを作ります。Planの名前とArea Path, Iterationを指定します。

f:id:kkamegawa:20171219210212p:plain

Planを作った後はテストケースを構築します。テストのシナリオを作り、具体的なステップを書いていきます。CI/CDアドベントカレンダーからははずれるので、深入りしませんが、ドキュメントを参考にどうぞ。

docs.microsoft.com

ビルドと品質レポート

ビルド時にカバレッジとテスト結果を発行していると、TestタブにUnitTestの結果が表示されます。このときはテストケースが一つだったので、Test数が1で100%成功ですね。

f:id:kkamegawa:20171219210213p:plain

Summaryにはコードカバレッジの結果も出ています。ブロックで50%、ソースコード行数で58%カバーしています。

f:id:kkamegawa:20171219210216p:plain

テストケースを一つ増やして2にすると、ブロックが57.89%, ソースコード行数が64.71%に向上しました。赤枠で囲んでいるところでカバレッジが上がったことが分かります。

f:id:kkamegawa:20171219210215p:plain

Download codecoverageをクリックすると、Visual Studioで開けるコードカバレッジ結果ファイルがダウンロードされます。

f:id:kkamegawa:20171219210218p:plain

未カバー率が100%のところがあるので、ダブルクリックすると、Visual Studioで該当ソースコードが開きます。

f:id:kkamegawa:20171219210219p:plain

赤で塗られているところが未カバー範囲で、薄い水色がテストでカバーされているところになります。

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

六週間後かと思っていたのですが、二週間で出てしまいました。今回のリリースは少しだけで、一週間で展開されるということなので、もう皆さん使えるようになっていると思います。オリジナルのリリースノートはこちらを読んでください。

docs.microsoft.com

今回重要な注意事項として、SSHでログインしている場合、URLが変わるので、早く対応しましょう。ケースによっては5倍くらい早くなるというのは魅力的ですね。

複数フェーズビルドが強化されてそれぞれ別のエージェントキューが指定できるようになったのはいいですね。.NET Coreのように複数のプラットフォームでビルドしたい場合とか便利そうです。

Hosted VS2017エージェントに管理者権限でソフトが追加できるようになるのは地味にうれしいです。管理者権限で追加できるのは大丈夫なのかという気もするんですが…うーん。

ではまた三週間後。

Translate to Japanese to VSTS release notes from h ...