kkamegawa's weblog

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

Visual Studio Team Services CI/CDアドベントカレンダー:Inside Build Agent(14日目)

はじめに

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

qiita.com

VSTSにはCircleCIやAppVeypor、Travis CI、Bambooのようなクラウドベースのビルドサービスがあります。240分/月までは無料です。ただ、テンプレートから作ったものをビルドするだけでも3-4分かかるものもあるので、無料枠はどんな感じで使えるのかという感じをつかむくらいでしょうか。

そんなVSTSのビルドエージェントですが、実は自分でたてることもできます。インストールしてどんな挙動になっているのかとか、ちょっとしたTIPSを紹介します。

VSTSエージェントのソース

github.com

VSTSは.NET Core上で動いています。なので、Windows以外にもmacOS, Linuxもサポートしています。Linuxは特にdockerイメージも公開されているので、インストールは楽です。Windows版のDockerイメージも公開してほしいみたいなフィードバックは出ているのですが、まだないようです。

Docker使う方法は以前書いたので、こちらを見てください。

kkamegawa.hatenablog.jp

DockerイメージにはVSTSで動いているソフトと同じものが入っているので、それ以外で必要なものを追加する場合は自分でdockerイメージをビルドします。node.jsや新しいJDKであればビルドタスクで追加もできるので、dockerビルドする必要はありません。

ローカルか、プライベートか。

VSTSが提供するエージェントの場合、ローカルディスクが10GBまでという制限があります(緩和してほしいというリクエストは出ています)。これを超えるとpullやビルドに失敗するので、ゲームなどで大きなコンテンツをビルドするときはレポジトリをわけるか、ローカルエージェントを使うしかありません。

後はCPUが2コアだったはずなので、大きいソリューションを並列ビルド、テストしたいときもちょっと困りますね。

そのほか、新しいXCodeをいち早く使いたいとか、ライセンス上nuget等でとってこれないライブラリをビルドするときもプライベートエージェントを使ってください。

エージェントのフォルダー構成

ビルドエージェントのフォルダー構成はこのような感じです。

f:id:kkamegawa:20171214054159p:plain

_work(インストール時に変更できます)というフォルダの下に1,2,3...と数字が振られます。これがビルド毎に使われる作業フォルダです。

  • a : artifact(成果物)が格納されます。publish to artifactsタスクがこのフォルダーを丸ごとVSTSにアップロードします。
  • b : ビルドで一時的に使います。
  • s : ソースを取得するフォルダーです。

これらのフォルダーの絶対パスを取得したい場合、VSTSのビルドエージェントの定義済みの値を使用します。

docs.microsoft.com

ビルドタスクのPowerShell, バッチファイル、シェルスクリプトで参照できます。

f:id:kkamegawa:20171214054158p:plain

こちらはDeployment Group用に構成したエージェントです。_workというフォルダーの下にr1というフォルダーができており、その配下はビルドと同じ構成になってます。

aというフォルダの下にビルド定義で生成された成果物(artifact)がダウンロードされていることが分かります。ビルド定義でdropフォルダの下に生成すると指定しているのが分かると思います。

ビルドエージェントの更新

ビルドエージェントはGitHubのReleaseからダウンロードします。一部の環境でGitHubのRelease(というよりAWSのS3)へのアクセスが制限されている場合、VSTSの機能での更新はできないので気を付けてください。

Dockerみたいにmicrosoft.comドメインから配布してくれるとありがたいんですが…(フィードバックしたんですが)。

(2018/2/7更新)
ビルドエージェント 2.129(2.127も)からMicrosoft配下のドメインからダウンロードできるようになっています。おかげでAWS S3がアクセス禁止になっている組織でもダウンロードできるはずです。

docs.microsoft.com

そのほかの展開についてはこちらをみてください。ちなみに、VSTSへの接続は一台のビルドサーバーが一つのVSTSへの接続しかできない、ということはありません。リソースが許す限りいくつでもサービスを構築できます(もちろんインストール用のフォルダは別の名前にします)。

PATでの接続になりますが、PATの期限切れの通知はないので気を付けてください。

capability(ビルドエージェントで使用可能な機能)

VSTSでビルドエージェントと一口に言っても何がビルドできるのかわかりづらいでしょう。何がインストールされているかということはAgent Queueハブから対象のビルドエージェントを選択すると、Capabilityという項目でわかります。

f:id:kkamegawa:20171214054200p:plain

例えばこれはVSTS AgentのLinux Dockerイメージの場合です。JDK7/8はじめいろいろ入っています。独自のDockerイメージを作るのもいいでしょう。

f:id:kkamegawa:20171214054201p:plain

Hosted VS2017イメージです。実は作成方法はこちらのGitHubで公開されています。

github.com

このスクリプトを使えば理論上同じ機能を持つプライベートエージェントが作成できます。VSTSのHost agentはまだWindows Server 2012 R2のはずなので(そのうち2016になるようです)、Windows 10でなければビルドできないようなもの、例えばMixed Reality対応アプリやUnityに関しては残念ながらローカルエージェントを使ってください。

macOSのXCodeも新しいものにリアルタイムでついていきたい場合は自前で管理するしかないようです。

f:id:kkamegawa:20171214054203p:plain

capabilityはエージェントの環境変数の値がそのまま出ていますが、実は自分でも特殊な値を追加できます。自分のローカルエージェント(default)のUbuntu001のcapabilityから"Add capability"で好きな値(ここではmycapabilities)を指定します。

f:id:kkamegawa:20171214054204p:plain

そして、ビルド定義のDemandsにmycapabilitiesがなくてはならない(exits)と指定します。

f:id:kkamegawa:20171214054205p:plain

仮に、VS2017エージェントプールを指定しても…。

f:id:kkamegawa:20171214054206p:plain

このようにHosted VS2017のエージェントにはmycapabilitiesがないので、ビルドに失敗します。

これは自分で指定した追加capabilityですが、そもそもVisual Studioが必要なのに入っていないエージェントプールを指定しても同じエラーになります。

※:確か以前はキューに投入する前にDemandsと一致していないよという警告が出たはずなんですが…。

TIPS

自分で管理しているとはいえ、ソースの中に機微情報が入っているなどの理由でビルドエージェント内にファイルを残しておきたくない場合があります。

ビルドエージェント2.126(最新版)の新機能に、ビルド終了時pullしたソースコードを消してくれる、という機能が追加されました。

ビルド定義のvariableに"process.clean"を追加して、trueを指定してください。ビルド終了時にローカルのソースファイルが自動的に削除されます。

ビルドエージェントはあまり知られてないことも多いですが、ビルドタスクともどもオープンソースなので、困ったらソース見るといいと思います!

Visual Studio Team Services CI/CDアドベントカレンダー:タスクをライブラリで再利用する(13日目)

はじめに

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

qiita.com

ビルドやリリースで使うタスクはどうしても長くなります。また、ブランチやfork先のレポジトリでビルド定義を一から作るのも大変です。そんなときのためにTask Groupsという機能があります。ちょっと使ってみましょう。

タスクグループを定義する

タスクグループの定義は簡単です。既存のビルド定義やリリース定義から作っていきます。

f:id:kkamegawa:20171213060443p:plain

このようにグループにしたいタスクを選択して、右クリック「Create Task group」をクリックします。

f:id:kkamegawa:20171213060444p:plain

ただし、注意点として、標準のタスクはプロセスごとに共通の値(*/.csproj等の値)を定義しています。リンク機能といいますが、これを指定していると、タスクグループにできません。

f:id:kkamegawa:20171213060445p:plain

このように各タスクで共通の値として設定されている項目にある、unlinkをクリックしておきます。unlink allで全部削除されます。

f:id:kkamegawa:20171213060446p:plain

リンクが解除されると、今までタスクごとに編集できなかったProject(S)の項目が編集できるようになっているのがわかります。

f:id:kkamegawa:20171213060447p:plain

タスクグループの名前でわかりやすいものをつけましょう。ビルドタスク一覧に作者の名前と一緒に表示されます。また参照しているvariableの既定の設定も行います。ここではBuildConfiguration(Release/Debugなど)の指定ができます。

f:id:kkamegawa:20171213060448p:plain

タスクグループをどのカテゴリーに追加するかという選択です。buildを選んだら、タスク追加時に選択する"build"カテゴリーに表示されます。Createボタンを押すと、現在のビルド定義の該当タスクがタスクグループでおきかえられます。

f:id:kkamegawa:20171213060449p:plain

こんな感じですね。Build configurationもグループの共通設定で可能になっています。

Task groups定義の管理

作ったタスクグループはTask groupsハブで管理できます。

f:id:kkamegawa:20171213060450p:plain

グループの名前、詳細説明(description)、定義のカテゴリーなど作るときに指定した項目が指定できます。

f:id:kkamegawa:20171213060451p:plain

一度作ったタスクグループの内容を変更したい、ということはよくあります。ここでタスクの追加や削除、使用しているタスクのバージョンアップといったことができます。ピンクの旗アイコンがタスクの横についていますが、これがタスクのバージョンアップが可能というお知らせです。ちなみに選択するとpreview版のver2が選択できます。

f:id:kkamegawa:20171213060453p:plain

新しくビルドタスクの追加もできます。

f:id:kkamegawa:20171213060452p:plain

タスクグループをバージョンアップするのはいいのですが、複数のビルド定義で参照されていると影響が…ということもあると思います。そういう時はReferencesから使用しているビルドやリリース定義の参照ができます。

とはいえ、いきなり全部のタスクをアップデートするのは怖いものです。そういうときのために、プレビュー版として公開する機能も用意されています。

f:id:kkamegawa:20171213060456p:plain

新しく同じタスクグループを参照するビルド定義を追加すると、こんなかんじでふえます。

新しいビルド定義で参照する

作ったからには当然新しいビルド定義で参照もできます。

f:id:kkamegawa:20171213060454p:plain

buildカテゴリーにタスクグループを作っているので、buid配下で探すと、作ったdotnet buildタスクがありますね。

f:id:kkamegawa:20171213060455p:plain

追加するとこんな感じです。

プレビュータスクで評価する

前述したように、いきなりビルドタスクを更新されると困ることもあります。そのような場合のために、プレビュー版を作って事前に評価してもらう仕組みがあります。

f:id:kkamegawa:20171213195831p:plain

ビルドタスクの一部を新しいバージョンに更新します。Saveではなく、Save draftで保存して、Publishをクリックします。

f:id:kkamegawa:20171213195833p:plain

Publishを実行すると、Publish as previewというチェックボックスがあるので、チェックすると、プレビュー版のタスクグループとして登録されます。

f:id:kkamegawa:20171213195834p:plain

ビルド定義でバージョンのところに2.*(preview)という選択肢が増えてますね。これでビルドできるかフィードバックをもらって、OKであれば、タスクグループを更新して、全体に反映させます。

まとめ

ビルドやリリースのタスクをグループ化できるTask groups大きな環境になると便利なので、使ってみてください

Visual Studio Team Services CI/CDアドベントカレンダー:仮想マシンへの継続的デプロイ(12日目)

はじめに

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

qiita.com

今日は昨日に引き続き、Azure仮想マシンへの継続的配信を紹介します。最初に…ちょっと失敗して、仮想マシンへの設定で忘れているものがありました。なので、失敗していますが、最終的には成功するはずです、たぶん。あとでUIテストを紹介するときにリカバリーしようと思っています。

仮想マシンでの事前準備

AzureにWindows仮想マシンを立てた人はわかると思いますが、ネットワークプロファイルがパブリックになっています。実はこのパブリックのままだとWinRMでの管理ができません。

Azureでドキュメントが提供されているので、こちらを見てください。

docs.microsoft.com

AzureのDevTest Labsであればこの辺も割と面倒見てくれるはず…です。TFS本ではこの辺をちゃんとドメインプロファイルにしているので、そちらでもカバーできればと思っています。

Azure仮想マシンデプロイ時の注意点

f:id:kkamegawa:20171212205452p:plain

Azure仮想マシンデプロイ時の拡張機能にTeam ServicesのDeployment groups用のエージェントを入れられるように見えるのですが、実はこれ成功したことありません(汗)。これを入れると、どうしてもVMのデプロイでエラーになります。VMそのものはできているのですが、エージェントが構成されていません。

製品グループにもフィードバックしたような感じではありますが、もう一度聞いてみます。

f:id:kkamegawa:20171212205459p:plain

VSTSのAzure File Copyタスクでストレージアカウントを指定するところがあるので、管理ディスク(Managed Storage)を使わないほうがいいかもしれません。WinRMを使うので、ストレージアカウントなくてもいいはずなんですが…停止しているときでもコピーできればいいのですが。

Deployment groupのエージェントフェーズを使う

f:id:kkamegawa:20171212203125p:plain

ReleaseでEnvironmentを作るとagent phaseというビルドエージェントと同じものを使っていました。Deployment groupに対してデプロイするにはdeployment group phaseを使います。

f:id:kkamegawa:20171212203124p:plain

追加するタスクはagent phaseと変わりありません。PowerShellのタスクやResource Groupの作成ができます…が、このResource Group内のVMの起動タスクを設定すると、現時点でなぜかエラーが出るようです。ちょっとフィードバックしておきます。

f:id:kkamegawa:20171212203123p:plain

Azureリソースグループ内のVMを起動する、というタスクです(が、私が試したときはエラーになりました…)。

f:id:kkamegawa:20171212203134p:plain

VMにファイルコピーします。ここでストレージアカウントを指定するため、VMには管理ディスクが使えないのではないか疑惑がありますが、ちょっと聞いてみます(こんなんばっかり…)。

Sourceはビルドで生成されたartifactのコピー元フォルダを指定します。

f:id:kkamegawa:20171212203126p:plain

こんな感じですね。フォルダを指定するので、コピー元のartifactの段階でちゃんとフォルダになっている必要があります。ビルド時msi形式で作っている場合、このタスクでコピーしてから、WinRMで実行するか、PowerShell DSCで構成するしかないでしょうか。

f:id:kkamegawa:20171212203130p:plain

VMへのコピーはこんな感じです。Adminのアカウント名とパスワードはVariablesに登録しています。ただ、Workgroup環境だとVMごとにアカウント名が変わるので、やはりAzure Active Directory Domain Servicesなどでドメイン管理しないといけないんでしょうか…。ID複数管理するのが苦にならなければいいけど。

f:id:kkamegawa:20171212203129p:plain

リリース実行

f:id:kkamegawa:20171212203131p:plain

Create Releaseでリリース実行します。

f:id:kkamegawa:20171212203133p:plain

対象のVMにコピーできれば完璧…だったのですが、WinRMの構成やるの忘れていたので、このようなエラーになりました(恥)。Azureに限りませんが、Windows VMへのデプロイを実施するときは以下のことを忘れないでください。

  • セキュリティグループで5986/tcpを通す
  • 仮想マシン内のパブリックネットワークプロファイルに対してwinrm qcを実施ておく(デフォルトではエラーになります)
  • Windows Advanced Firewallでパブリックプロファイルに対して5986/tcpを通す

さすがにパブリックプロファイルに対して5986/tcpを通すのは怖いと思います。AzureのIPアドレス変更に追従できるのであれば、VSTSのIPアドレスのみ通すようにネットワークセキュリティグループを構成すればいいでしょう。

f:id:kkamegawa:20171212203132p:plain

デプロイが終了すると、deployment groupのマシンに対して成功失敗が表示されます。

まとめ

閉まらない結果でした、後日ちゃんとした方法を(TFS2017/2018本ともども)フォローアップします…たぶん。

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

Visual Studio Team Services 2017/11/28のSprint 126のリリースノートの翻訳を行いました。オリジナルはこちらから読んでください。

docs.microsoft.com

最近は小幅な更新でしたが、Connect();に合わせて貯めていたんでしょうか。非常に大きな更新になっています。

DevOpsプロジェクト、マルチフェーズビルド、Docker Hub/ACRのサポート、継続的モニタリング、テスト環境のスタンドアロン化、Wikiを作業項目にリンクできるようになった…本当に盛りだくさんです。

いくつかの機能はすでにロールアウトしているので、Preview Featureを有効にすれば使えます。

継続的モニタリングに関してはWindowsなどでもおなじみですね。最初に一部の人たちに提供してモニタリングで監視して、問題ないようであれば次の人たちにリリースするというやり方です。

余談ですが、VSTSもこのような段階的なリリースが行われており、開発者たちが使うRing0、次の一部のMS関係者(VSのPMなど)及び、特別な顧客向けのRing1、一般向けのRing2と状況を見てリリースされているそうです。

たぶん今年のリリースはこれで終わりで、Sprint 127を飛ばして、次は来年のSprint 128になるんじゃないかなと思います。ではまた六週間後。

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