kkamegawa's weblog

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

Visual Studio Team Services CI/CDアドベントカレンダー:CI/CDまとめ(25日目)

はじめに

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

qiita.com

なんとか完走できました。というか、これは最後のポエム的なエントリーです。

VSTSとCI/CDについて

VSTSのCI機能は早くからありましたが、CDに関しては、少し後からという感じでしたね。もともとRelease Managementという買収した製品があり、それをTFSに組み込み、さらにはVSTSに持っていくというところから始まったので、最初のリリース機能はおまけみたいなものでした。

だんだんと改良を続けてきて今に至るわけですが、まだまだもっとこうなればいいなーと思うところはあるものの、当初からしたら随分良くなったと思います。

Webへの傾倒

最近のVisual Studio Team Services/Team Foundation Server/Visual Studioのリリースを見ていると、Webへ舵を切っているように見えます。実際、Test ManagerやFeedback Clientはサポートこそされているものの、Visual Studio 2017標準ではインストールされません。

MSの昨今の方針を示すように、クライアントもクロスプラットフォームのために.NETオブジェクトモデルから、REST APIを押しています。もちろん、.NET Coreでもいいのでしょうけど、あのオブジェクトモデルを.NET Coreに移行させるとなると、既存のライブラリ群からの移行が大変そうです。

Python製のVSTS-cliも出てきたし、Web拡張機能を使うにもRESTの方が都合がいいでしょう。これはこれで正しいように思います。

github.com

今後はモバイル用のビューの不足ですね。Work itemなど一部はサポートを始めましたが、まだまだ不足しています。かと言って、そう簡単に作れそうもない気もしますし、必要かと言われれば…うーん。

エージェントについて

CIに使うビルドサーバーを管理したくない、というのはその通りだと思いますが、反面外に出せないライブラリやコンパイラーを使うために独自のエージェントを立てる道が用意されているのはハイブリッドを得意とする、MSらしいなと思います。

ただ、ちょいちょい?と思うことはあります。昨日までは1分で終わるようなソリューションのビルドにある日突然7−8分かかったりとか。今回だいぶビルド無償枠を使ったのですが、この不思議なポーズ(?)現象のおかげで、無為に使われてしまいました。

後、これは致し方ないのですが、スプリント単位でVSのエージェントが更新されるものの、15.5がリリースされるちょっと前に15.4にしました!というのはもうちょっとなんとかならないものかと。

VSのビルドツール類がコンテナーになって、VS Hosted AgentがWindows Server 2016ベースになれば解消するのでしょうか。

ビルド/リリース時のキャッシュ

NuGetパッケージのリストアやDockerコンテナーのpullでもうちょっとキャッシュされないかなぁとは思います。パッケージリストアで1-2分、docker pull も結構早いのですが(特にazure container registry使うと)、他のCIサービスがキャッシュしているように見えるので、この辺の改善もされるといいなとは思います。

Azureいらないようで、実はいる

同じ会社のサービスだから当然と言えば当然なのですが、Azureと一緒に使うとより便利です。パッと思いつく限りで。

  • Application Insights, Monitorなどを使ったリリースゲート
  • Key Vaultを使った機密性の高いデータの格納
  • Azure AD(AAD)を認証に使うとAADのグループがそのままチームになる
  • DevTest Labsと連携してテストエージェントの展開

まだ試せていないですが、VSTSをAzure ADで認証して、クライアントはAzure AD, Azure AD Domain Servicesを使っていると、WinRMのpublicプロファイル問題も解消できるんでしょうかね。

App CenterとVSTSとの住み分け

これどうなるんでしょうね。当面、別々に運用するようですが、当然連携するところもあります。ただ、ビルドするのは間違いなく、App Centerのビルド定義の方が楽ですね。

TestとCI/CD

今回ほとんど紹介できませんでしたが、CI/CD 時にSeleniumなどで自動化テストを行うと言ったことも可能です。

あとは本番前のいわゆるシステムテスト(負荷テストなど)もできますね。機能的にはほとんど変わってないはずなので、昨年のカレンダーを見ていただいてもいいと思います。

今回できなかったところ

ネタとしてはあったんですが、私の検証不足や執筆ペースの都合で諦めたものも結構あります。

  • AWS との連係(拡張機能を入れるだけですが)
  • もっと他にいろんなパターンのデプロイ
    • LogicApp / Functions
    • Hadoopなど
    • AWS(Lambda/S3/EC2)
    • Cognitive系
    • データベース上級編
    • 大規模並列デプロイ
    • JavaやJavaScript, PHP, Pythonなどの他プラットフォーム
  • Docker(これはちょっとハマり中)
  • VSTSビルドタスクを作ってみる
  • Release Gateの他のパターン
  • モバイル開発(Xamarin, Swift, Kotlinなどバックエンドを含めて)

TFS本と並行してできればと思っています。

終わりに

今年もカレンダーなんとか完走できました!読んでくれて、ちょっとでもVSTSに興味を持ってもらえれば嬉しいです。

来年は他に書く人がいそうだったらやりましょう。

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でビルドしているようですしね。