お手伝い先でHoloLens でのCI/CD を構築、運用して1年を超えましたが、日々安定してビルドができています。
先日素敵な記事も出てて良い感じです。*1
Azure DevOpsでHoloLensアプリをビルド（MS-hosted編） | NEXTSCAPE with MR
HoloLens のCI環境について、必要な要件、CI環境の選択、Azure DevOps のMicrosoft-hosted と Self-hosted の選択を見てみます。
目次
- 目次
- ビルド環境の選択(OS)
- ビルドの選択(コンテナ)
- Windows のビルドサービス
- ビルド環境としての AzureDevOps Pipeline
- Microsoft-hosted Agent の懸念
ビルド環境の選択(OS)
HoloLens に限定してビルドについて検討すると、UWP ビルド = Windows SDK が鍵になります。 現状のWindows SDKは、Windows でのみインストールが可能であり、結果としてビルド環境もWindows に限定されます。
Unity は Unity 2019 においても動作環境として、Windows Server を想定していません。(以前サポートにも問い合わせた)
OS：Windows 7 SP1 以降、8、10（64 ビットバージョンのみ）、macOS 10.12 以降
サーバー版の Windows、OS X についてはテストされていません。
Windows Server 2012 R2 でUnity 起動すると即クラッシュします、対策にはDesktop Heap を広げる必要がありました。 幸いにもWindows Server 2016/Windows Server 2019 では問題なく起動し、ビルドも可能です。*2
今HoloLens ビルドを行うなら、Windows Server 2019 でビルドが可能です。(やってる)
ビルドの選択(コンテナ)
現状の Windows SDK + Unity をコンテナでビルドするのは難しい感触です。
Windows Container でコンテナイメージが公開されているようにも見えますがuwp という名はトラップです。中身は、Portal Library (Target UWP 10.0) であり UWPビルドはできません。
coderobin/windows-sdk-10.1 - Docker Hub
UWP のセルフビルドでわんちゃんいけそうですが、ここにUnity が入ると更にサイズが.... 。
コンテナビルドができても、Windows Container だと旨味が少ないので悩ましいですが..... コンテナだと楽なのも事実なのでなんともです。
合わせて必要に応じてこのあたりも対応ですね。
なお、HoloLens はすでにIL2CPP ビルドがデファクトまったなしなので、C# と VC++ のビルドが必要です。また、vcxproj/csproj は SDK 形式ではないため dotnet ではなく msbuildが必要です。*3
Windows のビルドサービス
Windows でのビルドを行うとき選択肢はいくつか考えられます。
- Azure DevOps
- AppVeyor
- Jenkins v2
- Drone
- Team City
Managed な環境でWindowsビルド を提供しているのは Azure DevOps と AppVeyor です。 Self-hosted Agent (自分でWindowsホストにエージェントをインストールして利用する)を提供しているのは、Azure DevOps、AppVeyor(Enterprise)、Jenkins v2、Drone、Team City です。
Team Cityを除きどれもYAMLでのビルドを定義できるのでそこは別にいいでしょう。
Open Source ではビルドをコスト、並列数、時間制約で考えると、Managed な環境であるAzure DevOps が最も強い選択肢になるのではないでしょうか?*4 AppVeyorは癖があることと、Spin upの遅さから選択しにくいものがあります。
個人的にはCircleCI が好きなので見てみると、Windowビルド対応予定があるように書いてあります。
リポジトリもあり、内容を見てみるとPerformance plan でトライアルできるようです。
Windows 向けOrb もあり、使えそうな感触があります。
orbs: win: sandbox/windows-tools@dev:preview
基本的なビルド機能である、caching, workspaces, SSH into the build がサポートされている一方で、Previewの現在、デフォルトでインストールされているのはごく一部のソフトウェアなので注意です。
We install Git, Chocolatey, and 7zip. We don’t install any other dependencies at the moment.
ビルド環境としての AzureDevOps Pipeline
Azure DevOps のビルド環境には、「おまかせできる Microsoft-hosted」 と 「自分で環境を自由に設定できるSelf-hosted」 の2種類あります。
- Microsft-hosted Agent: Microsoft がhost して各種ソフトウェアもビルトインで入っている
- Self-hosted agent: ユーザーがWindows/macOS/Linux のいずれかにインストールしてミドルウェアや環境を好きに構築したうえで動かす
両環境で一番大きく異なるのは、価格、パフォーマンス、実行環境のクリーンさ、ミドルウェアの管理です。
私自身パフォーマンスからSelf-hosted Agent を使う決断を下すことが多かったのですが、現在はHosted agent がいいように思います。(理由は後述)
この選択に関しては、他のAzure DevOps ユーザーも記事をあげているので参考にするといいでしょう。
Too bad! You still need a private build agent when using VSTS – Henry Been
では、Self-hosted Agent と Microsoft-hosted Agent ののどちらを、どのような観点で選択するといいのか考えてみます。
価格面の違い
価格表があるので見てみましょう。
- Microsoft-hosted Agent : 追加の並列ジョブごとに ¥4,480 (分数制限なし)
- Self-hosted Agent : 追加の並列ジョブごとに ¥1,680 (分数制限なし)
Hosted Agentが1並列ビルドに4480円というのはかなり高く感じるのではないでしょうか。*5
一方のSelf-hosted は1680円と安く見えるのに加え、MSDN の Visual Studio Enterprise サブスクライバーはアカウント1つあたり1つの課金済みSelf-hosted Agent ライセンスが付きます。*6 開発者一人ずつにMSDN サブスクリプションを会社で付与している場合、実質無料で開発者の数だけ Private Agent を割り当てて並列ビルドをかけられるので、一見すると大きなメリットに見えます。
The free tier is one parallel job. In addition, you get one free parallel job for each Visual Studio Enterprise subscriber that is a member of your organization. You can get more using paid self-hosted parallel jobs.
実際に Self-hosted Agent のコストを考えるときは動作するホストやストレージ料金を含めることになります。*7 よくあるケースとして、Self-hosted Agent を AzureVMを実行ホストとして実行することを基準に簡単に価格を考えましょう。*8
ビルドVMにCPUとメモリがほしいのでコスパがいいBシリーズの4 vCPU/16G RAMを採用します。
| インスタンス | VCPU | メモリ | 一時ストレージ | 従量課金制 |
|---|---|---|---|---|
| B4MS | 4 | 16 GiB | 32 GiB | ~¥19,131.84/月 |
git で大量のファイルを読み書きし、ビルドで大量のファイルリードがかかるのが主なストレージ負荷になるため、CIには高IOに耐えられる プレミアムストレージが欲しくなるでしょう。
以上を踏まえて、MSDNでSelf-hosted Agent がついてくる環境で、VM とプレミアムストレージを256GB/512GB/1TB の組み合わせと、Hosted agent で (¥4480) で換算して考えてみます。
| VM | Storage | Self-hosted 合計 | Hostedの台数換算 |
|---|---|---|---|
| * ¥19,131.84(VM) | ¥4,896.72(Storage 256GB) | ¥24028.56 | 5.3台 |
| * ¥19,131.84(VM) | ¥9,430.40(Storage 512GB) | ¥28562.24 | 6.36台 |
| * ¥19,131.84(VM) | ¥17,409.28(Storage 1TB) | ¥36541.12 | 8.1台 |
ビルドの数にもよりますが、1VMに載せられるエージェントの数は2-4台程度です。 このため社内マシンを使うなどの選択をしない限り 、Self-hosted は並列度との兼ね合いはかなり悪いものがあります。*9
ビルド環境の手間
ビルド環境はただビルドだけしたいので、手間がかかるのは嫌なものです。 手間をかけるメリットがあるときはかけますが、かける必要がないならかけないのがいいでしょう。
この観点では、Microsoft-hosted Agent は一般的なビルド環境程度には楽です。
Microsoft-hosted Agent
ビルドエージェントが動作するホスト環境の管理が不要なため、手間が大きく軽減されます。 都度新しい環境でビルドされるので、ビルド環境のボリューム容量も気にする必要がありません。
逆にホストの管理ができないことに割り切れないと手間がかかるでしょう。 都度新しいホストが起動するため前回のジョブ実行状態を再利用することはできません。 Hosted Agentに入っていない、インストールに手間や時間のかかるミドルウェアを事前にインストールしておいてビルドのための時間を省略することもできません。 エージェントを選ぶことはできないので、エージェントに高スペック、高IOを期待することはできません。 ジョブごとにクリーンであることが面倒なポイントです。
Self-hosted Agent
ビルドエージェントが動作するホスト環境が管理できることから、うまく使うとビルドを高速化できます。 前回のJon結果やCheckOut 結果を再利用して、gitやdockerのキャッシュをかけておくこともできます。 Unityのようなインストールに時間のかかるミドルウェアをインストールしておくことも可能です。 ミルドウェアの特定のバージョンで問題があったときに、バージョンを固定するのも難しいでしょう。
うまく使う、の度合いが半端なくホストの管理が必要で手間が大きくかかります。 まずSelf-hosted Agent のインストールが必要です。 ビルドするホストのボリューム容量の管理が必要です。1ホストで複数エージェントを動かす場合、ホストごとにワークスペースを持つためn倍(n=ホストの数)の容量を使います。 ホスト管理の手間があるのは手間の多くを占めます。
VMとストレージが更に増え、それぞれにインストールすることを考えるとなかなか面倒なことがわかります。
Microsoft-hosted Agent と Self-hosted Agent の選択
ビルドの頻度にもよりますが、HoloLens 開発でSelf-hosted Agent か Microsoft-hosted Agent を選ぶ場合、今ならMicrosoft-hosted Agent がいいでしょう。
一見Microsoft-hosted Agednt はスペックが低かったり、1並列ビルドが高かったりしますが、手間がかからない、純粋に並列度で考えられるのは大きなメリットといえます。
IL2CPPが当然になった今、HoloLens の1ビルドにかかる時間は早くても15min、普通に20min～30min 程度かかります。 Unity のCacheを持った状態での起動高速化(Library) も、スクリプトの変更に弱かったりするので厳しいものがあります。
総合的にみて、割り切ってMicrosoft-hosted Agent がいい選択肢になるでしょう。
Microsoft-hosted Agent の懸念
Microsoft-hosted Agent は、UWP ビルドができる稀な Managed CI 環境ですが、Windows SDK が怖い部分でもあります。
MRTKv2 は、Windows SDK 18362 が必要ですが、これがHosted Agent のビルドで利用できるようになったのは6/25です。
Sprint 153 で追加対応が来てから自分たちのAgent にくるまで約2週間かかっています。多くの場合この程度かかることから、Azure DevOpsにおいては2週間程度は新機能の利用まで見ておく必要があります。*10
View linked GitHub activity from the Kanban board - Sprint 153 Update | Microsoft Docs
そういった意味で、Visual Studio はともかくとして*11、MRTK が 新Windows SDK に依存した実装を入れたときにCI環境の Windows SDK がなくて悲しい思いをすることはありえます。
とりあえず 今のMRTKv2 で使ってる最新Windows SDK 来たし、まぁしばらくは大丈夫でしょう。
*1:手離れされているので安心して見ていられます。
*2:以前は Windows Serverが使えない縛りから Windows 10 をAzure のDev利用などで持って来る必要がありました
*3:dotnet SDK で完結する今どきの.NET 環境ではない
*4:無料、10並列、時間無制限
*5:そもそもパイプラインで課金という価値観が、CircleCI の新料金プランで崩れていてつらさがあります
*6:企業でMSDNサブスクリプションを配布しており、このサブスクリプションをビルドに利用したい場合、MSDN サブスクライブ画面で会社のAzureアカウントと紐づけてもらうことで割り当てられます。
*7:人的コストを除外します
*8:EC2に置き換えても結構です
*9:VMやストレージ環境
*10:UIの変更を除く
*11:これは比較的すぐにくるので
