tech.guitarrapc.cóm

Technical updates

VSTSの YAML Build Preview でビルド

Visual Studio Team Service (以降 VSTS) は、プロジェクト管理、Gitリポジトリ、CI (リリース含む) などソフトウェア開発を支援する結構大掛かりなサービスです。

私自身は CI の環境としては結構好き*1な一方他の機能はちょっと大掛かりと感じます。本記事では言及しませんが、パッケージ管理も便利です。*2

今回は VSTS でずっとほしかった YAML 定義からのビルドパイプラインについてです。ようやくYAML来たので少しは楽できそうです。

YAMLといっても、この VSTS 拡張じゃないので悪しからず。

https://marketplace.visualstudio.com/items?itemName=adamvoss.yamlmarketplace.visualstudio.com

目次

参考資料

ある程度概要をつかみつつ詳細を見通すのには、このあたりを見ておけばいいと思います。英語記事も含めて触ってみた、こんな感じという内容が多いのは利用者の絶対数と、他CIに比べて Yamlでの調整がしにくいのが大きい感じがします。(GUI でのパイプライン構築が強いのもありますが)

kkamegawa.hatenablog.jp

docs.microsoft.com

azure-pipelines-agent/yamlgettingstarted.md at master · microsoft/azure-pipelines-agent · GitHub

概要

従来 VSTS ではWebポータルからGUIでビルドパイプラインを構築していました。このあたりは、CircleCI や Travis、AppVayor に慣れてると不思議な感覚です。

VSTS の YAML Build とは、簡単にいうと Circle CI のような yaml 定義でのビルドパイプライン構築ができるというものです。慣れた手法ですね。なお、ビルドパイプラインだけなので、Push連動などビルドタイミングやオプション設定はできません。

さて、ではGUI での構築はどうなんでしょうか? YAML を使いたいだけの理由があるのでしょうか?私にとっては、ものによる、と思います。ビルドの95%はシンプルなので YAML がベターです。一方でその場でインスタントに組むにはGUIも悪くないでしょう。

今がPreview だからこそ、感覚として他のビルドで慣れた肌感との違いをメモしておきます。

GUI のメリット

  • リポジトリにコミットがいらないので CI ビルドのためにコミットを重ねる必要がないのはあるあるでしょう。*3
  • パイプラインを作っていてある程度複雑になっても意外とやりやすいと感じます
    • yaml ですこし細かいことをしたときに読み解かなくてもパッとみたいことに目線のスコープを絞れるのは GUIの良さでしょう

GUI で困ること

  • GUIで1つずつのパイプラインを組むので、どんな構成なのかをざっと把握するには不便です。全体の普遍的な把握にはだるいです
  • ビルド構成のクローンからの作成が可能ですが、まとめて直したいときには1つずつ直す必要があって容易に刺身タンポポになります
    • ビルド職人さんはほぼ発生しないのですが、刺身タンポポさんが発生しやすいのは由々しき欠点です
  • リポジトリごとに決まったパターンでのビルドを、ビルド構成/デプロイ先の些細な差異で構築したときに面倒さが爆発します
    • ビルドパイプラインは単純を維持するのがいいので、Parallel にパラメータ変更で回すなどは避けるべきです
    • 一方で、似たビルドが多数できても違いを把握するのは大変でしょう

YAML ビルドの利用開始前作業

YAML ビルドを試す前にちょっとだけ準備です。

アカウントをとる

VSTS にアクセスして適当にアカウントをとっておきます。無料です。Hosted Agent でマネージドビルドができるので、まぁあってもいいかなぐらいです。

www.visualstudio.com

YAMLビルドの有効化

まだ YAML Build は Preview 機能なので有効化が必要です。

  • アカウントのアイコンから Preview features を開く

  • ユーザーアカウントではなく 作成した VSTS アカウント全体の設定に切り替えます for this account
  • Build YAML definitions を on に変更

これで準備できました。

YAML でビルドパイプラインを書いてみる

では本筋です。ドキュメントは本家を見ておけば大丈夫だと思います。

azure-pipelines-agent/yamlgettingstarted.md at master · microsoft/azure-pipelines-agent · GitHub

YAML 定義をする前にどんな定義なのか見る

適当にビルドをWebポータルからポチポチ組むと YAML でどう定義するのか見られます。便利。

View YAML からYAML をプレビューしてみました。

なるほどいい感じです。

gist.github.com

リポジトリに YAML 定義を置いてみる

ではプレビューした YAML使ってビルドプイプラインを定義してみましょう。コピペです。

github.com

ビルドパイプラインをYAMLで作る

書いたYAML からビルドパイプラインを作ります。

VSTS で作業しましょう。

YAML によるビルド定義を作る

VSTS の Build and Release > Build からビルドを新規作成します。

新規ビルドジョブを作ってみると YAML が選択できるようになっています。

Agent Queue の選択

適当に名前を付けたら、Agent Queue を選択します。2018/1/24 現在は、YAML ビルドは マネージドビルドであるのみサポートされています。

  • Hosted VS 2017
  • Hosted Linux Preview
  • Hosted macOS Preview

https://docs.microsoft.com/en-us/vsts/build-release/actions/build-yaml

今回は C# プロジェクトなので Hosted VS2017 を選択します。

YAML パスの指定

YAML ビルドは、Git ソースパスとして Github か VSTS がサポートされています。YAML はリポジトリ内の任意のパスを指定できます。ルートが一番楽で、.vsts-ci.yml がドキュメントで記述されている名前ですが他でもok です。

今回は、v2 フォルダ配下に置いたので、v2/.vsts-ci.yml と指定します。

ビルドリポジトリの指定

Get Source からビルドリポジトリを指定します。Github からぽちっと。

Submodule など チェックアウトオプションの指定

YAML 定義の リポジトリのチェックアウト指定には制約があります。

https://github.com/Microsoft/vsts-agent/blob/master/docs/preview/yamlgettingstarted-features.md

  • YAML 上では Submodule checkout を指定できない
  • Build Report の有効化が指定できない

しかしこれらは、UI上でリポジトリのチェックアウトとしては有効化がかのうなので必要に応じてUIで有効化すればいいでしょう。

環境変数の設定

YAML 内部でも Variables は定義可能です。が、ビルドによって変わるものやシークレットは当然入れなくないでしょう。

https://github.com/Microsoft/vsts-agent/blob/master/docs/preview/yamlgettingstarted-phase.md#variables

CircleCI でもそうですが、シークレットな情報は環境変数に鍵付きマスクで設定しておけます。

ビルド実行

ビルド設定ができたらこれでおしまいです。Save & Queue でビルド開始してみましょう。

なお、YAML の定義がおかしい場合、Queue 実行時にわかります。ちょっとタイミング遅いですね。

問題なく YAML が解釈できればビルドが開始するでしょう。

ビルド画面

ビルド画面はリアルタイムでビルド状況が表示されます。ここで YAML のパイプラインがわかります。ビルドUIでわからないのがやはり嫌ですね。

うまく変数も解釈され、ビルドが成功しました。

まとめ

Hosted Agent でしか動かないのが苦しいですが、おおよそ機能は満たしていていい感じです。

VSTS をこれからちょっと使ってみる、iOS ビルドで触ってみる (Hosted Agent on macOS) 場合にはYAML定義が慣れ親しんでいることが多いのでいいと思います。他のビルドサービスより癖が強く YAML 定義のハードルが高いのでなんとかしてほしいですね。

現状の利用シーン

エージェントが弱いのでほどほどの開始から、という印象ですが Private Agent がきたらすぐにでも使えそうですね。

  • Recommend: Your Project is Simple enough includes pipeline count and parameters
  • Recommend: Your Project is referencing variables with many pipelines. yaml offers easy view checking
  • Accept: yaml <-> pipeline conversion is not available
  • Accept: Private Agent is not available

VSTS yaml ビルドのここが苦しい

  • Checkout options: Tag sources, Report build status, Checkout submodules
  • Hosted Agent のみ対応
    • Private Agent対応していないので強いのがほしいときに非力
    • Hosted Agent がかなり非力で大きなリポジトリのビルドが現実的な時間でできないので致命傷になりかねない
  • パラメータなに使えるかとか初見殺し
    • ぽちぽち作成 -> yaml 生成しないとむりぽ
    • Circle CI とかだとコマンド実行しか露出させないのに対してパイプラインのカスタム要素で構築していく VSTS スタイルだときっつい
    • Store のパイプラインのところとかで、パラメータ提供してくれないときつそう
  • yaml定義はパイプラインには出ない
    • パイプラインの途中だけ無効とかが当然できない
    • パイプラインの内容を yaml 翻訳はできても yaml -> パイプライン翻訳ができてないので制約としは自然
  • yaml -> ふつうのパイプライン、ふつうのパイプライン -> yaml の変換ができない
    • 新しく作るしかない...

ここは嬉しい

  • dotnet みたいにグループ定義になっている場合にParameters として変数見えてるので設定しやすい
  • ビルドステップが単純なら各ブランチビルド定義が楽ちん
  • 変数が定義しやすいのは相当楽。見通しいい
  • UIぽちぽちから yaml 出力できるので定義が楽にテンプレート組める
    • ただし、これがただしいとは限らない
    • 変数が抜けていたりする

*1:Windows な Managed CI Service は VSTS か AppVeyorぐらい

*2:Git リポジトリを Github 以外で管理するメリットがかなり薄いのもあり微妙

*3:ブランチ切って履歴から抹消という手もありますが、そこはチームにお任せで