tech.guitarrapc.cóm

Technical updates

トップ > Azure > VSTSのYAML Build Previewでビルド
最終更新日

VSTSのYAML Build Previewでビルド

Azure CI/CD

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

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

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

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

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

参考資料

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

http://kkamegawa.hatenablog.jp/entry/2017/12/07/063616

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

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

概要

従来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でマネージドビルドができるので、まぁあってもいいかなぐらいです。

https://www.visualstudio.com/ja/team-services/

YAMLビルドの有効化

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

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

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

これで準備できました。

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

では本筋です。ドキュメントは本家を見ておけば大丈夫でしょう。

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

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

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

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

なるほどいい感じです。

https://gist.github.com/guitarrapc/7d6b84c1e6f676abdf001bdaa92b2525

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

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

https://github.com/guitarrapc/AzureFunctionsIntroduction/commit/2cd118862a79db8b79312b672e821fb38b69d775

ビルドパイプラインを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上でリポジトリのチェックアウトとしては有効化できます。

環境変数の設定

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:ブランチ切って履歴から抹消という手もありますが、そこはチームにお任せで