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