App Center と Azure Pipelines について

概要

App CenterもAzure PipelinesもCI/CDツールであり、対応したいビルド環境によっては、App Centerで対応できなかったりAzure PipelinesよりもApp Centerの方が良い点など、実際に扱わないと分かりずらいところがありました。

そのため、この記事では双方を触ってみた詳細を解説するため、もし「まずは触ってみよう」と考えられている方は、入門できる記事として参考にされてください。

結論

先に双方異なるポイントを解説します。公式ドキュメントのApp Center Build vs. Azure DevOps Pipelinesに書かれている通り、次の背景から採用するポイントが異なります。

• App Center
  • 複数の環境をビルドする必要がなく、ビルドするリソースは１リポジトリだけで完結するシンプルなビルド環境であること。
  • 他リポジトリやサードパーティなどからリソースを取得するビルド環境と依存していると対応不可である。
  • Webアプリなどではなく、アプリ配信の需要があるiOS/Android/Windowsなどのアプリケーション開発が最適である。
• Azure Pipelines
  • JenkinsやCircleCIなどのCI/CDツール同様にシンプルかつカスタマイズが柔軟に対応できる。
  • Web/Mobile/PCのアプリ開発でWindows製品を取り扱っているプロダクトである。

　
CI/CDを理解している場合は、上記の詳細でどちらを採用すれば良いのか分かることでしょう。
シンプルなビルド環境という内容は抽象度が高いので、どんなビルド環境がシンプルなのか例をあげてみましょう。

ビルドがシンプルとは

CI/CD対応をする準備として、開発しているプロジェクトをCLIでビルドできる状態であることが必須です。
例えば、各アプリ開発で次のビルド内容のみアプリビルドできる開発環境であれば、断然App Centerがオススメになります。

# iOS（Xcode） Build
$ xcodebuild   \
  -workspace APP_NAME.xcworkspace \
  -scheme APP_NAME \
  -configuration Release archive \
  -archivePath ./build/APP_NAME.xcarchive
$ xcodebuild  \
  -exportArchive  \
  -archivePath  ./build/APP_NAME.xcarchive  \
  -exportPath ./build  \
  -exportOptionsPlist ./build/APP_NAME.xcarchive/Info.plist

# Android（AndroidStudio） Build
$ gradlew assemble

# Xamarin.iOS Build
$ msbuild /p:Platform=iPhoneSimulator /p:ArchiveOnBuild=true /t:"Build" iOS/APP_NAME.iOS.csproj
# Xamarin.Droid Build
$ msbuild /p:Configuration=Release /p:Platform=Android /t:SignAndroidPackage Droid/APP_NAME.Droid.csproj

# Unity Build
$ /Applications/Unity/Unity.app/Contents/MacOS/Unity -batchmode -quit -logFile ./build.log -projectPath ./APP_PROJECT -executeMethod BuildClass.Build

　
もし、上記の他に独立した環境のビルドが必要でJenkins Pipeline/CircleCI Workflowを必要とする開発環境であれば、Azure Piplinesを採用されてください。

App Centerは、（2020年03月現在）各ジョブが独立したアーキテクチャ設計になっているようで、成果物の共有ができません。
Azure Piplinesは、その名の通りでJenkins Pipeline/CircleCI Workflowと同じことが可能なので、各ビルドごとにデータの共有を行いたいビルド環境であれば、App Centerでは対応できずAzure Piplinesでの対応となります。

上記の課題をmicrosoft/appcenterにissue化したため、ワンチャン受託されて新規機能としてサポートされる未来があるかもしれません笑

App Center

　

App Centerの売りとしては、上図に記載している6つのマイクロサービスを使うことができ、無料プランで制限はあるものの全て使用することができます。

Microsoft社は、数年前にHockeyAppを買収しており、その後HockeyAppは去年2019/11/16でサービスを終了しました。
以降、HockeyAppはApp CenterのDistributeとしてマイクロサービス化され提供されてます。

また、iOS/Android/Windowsなどサポートしているマルチプラットフォームのフレームワークへのサポートが充実しており、次の項目がApp Centerで対応可能です。

• Objective-C / Swift
• Java / Kotlin
• UWP / WPF / WinForms
• React Native
• Cordova(Preview)
• Xamarin
• Unity

入門

今回は、適当にBitBucketにアップした新規プロジェクト作成しただけのXamarinアプリを用いて登録等を進めていきます。
最初は登録や連携などを済ませて進めていくと次のApp Centerのトップ画面が表示されると思います。

　

次に、ビルドしたいアプリの環境別に登録を進めます。
今回は、OSがiOSでPlatformがXamarinで登録しますが、基本的にベースは一緒でOS/Platform別に異なる点は然程ないため良しなに参考にしてください。

　

アプリの枠ができたらここでCI/CD対応したいプロジェクトを指定します。

　

登録すると次のように画面が変わり、ブランチ別に早速ビルドすることができます。
さらに進んでいくとビルドするオプションが表示され、その環境に応じて環境変数を用意したり成果物を変えてビルドすることができます。

ここで注意点としては、指定したブランチにアップされているプロジェクトの状態がBuild configuration上のオプションに対応していないと（例えば今回だとXcodeのバージョンが最新に対応できていないままBuild appで最新のXcodeでビルドする設定など）、エラーまたは正常ではないビルド結果になるかなと思います。
逆に使っている端末のXcodeをアップグレードできない状況で、App Centerで最新のXcodeでビルドしてどうなるのか確認したいときすごく使えますね。

　　

　

あとは結果を待つだけで、各ジョブから成果物をダウンロードすることができますが、ビルド結果の成果物を自動的にDistributeに登録して自動配布まで設定しておくと良いでしょう。
Build configurationからSimulator buildではなく、Device buildにチェックを付けるとDistribute buildsがOnに変えられ、自動的に登録することができます。

　

Overview

ちなみにOverviewページにGetting startedとありますが、CrashesとAnalyticsを扱いたいときに対応が必要で、Build・Test・Distributeだけ扱いたい場合は特に対応はやらなくて大丈夫です。
ただ、Testを扱うのであればテスト中に問題が起きた際に調査しやすいため、Crashesだけでも対応しておくと良いでしょう。

　

TIPS

　

App Centerは、OS単位で登録する形式になっています。
冒頭に解説した通り、App Centerには次のようなカスタマイズ製がありません。

• アプリビルド前にシェルを使用するビルド環境
• 複数リポジトリが必要なビルド環境
• 複数のアプリビルドを制御するパイプライン/ワークフロー

　

（2020年３月現在）上図のようにビルドのメニュー場では、ビルド設定など存在しません。
設定したOSとフレームワークに応じてApp Center側が自動でアプリビルドするアーキテクチャになっています。

Settingsのメニューでは次のような設定内容になっています。

　

ご覧の通り、アプリの詳細とビルドに関わる管理者の設定、ビルドした結果をいつまで保存するか、Azure DevOps/GitHub/Jiraなどのサードパーティ設定にWebhookなども対応可能です。

さらに詳しい詳細は、公式のVisual Studio App Center documentationに載っているので確実良しなに確認してください。

参考記事

• Visual Studio App CenterについてAndroid Test Night、iOS Test Nightで話してきました。
• Visual Studio App Center で、自動ビルド後に Android の自動実機UIテストを実行する方法
• App Center Hands On with Xamarin

Azure Pipelines

　

複数のマイクロサービスを提供しているAzure DevOps内の1つであるAzure Pipelinesは、JenkinsとCircleCIでやれることは同様にサポートしており、他CI/CDツールとの差別化として次の内容が所感でした。

• 直感的で操作性の高いUI/UXデザインでストレスをあまり感じない
• GitHubとの親和性が高く他ツールやサードパーティとの連携で柔軟に対応できる
• CircleCIのconfig.ymlに似たビルド設定を行うazure-pipelines.yml

入門

Azure PipelinesもApp Centerと同じく特定の開発プロジェクトを登録しないと扱うことができないため、触り始めは適当な検証用リポジトリを使用しましょう。

App Centerとの違いは最初から大きく異なります。
まず最初にやることはNew organizationから「組織」を作り、その後に組織内にNew projectから「プロジェクト」を作ることになります。

例えば、「組織」は会社で「プロジェクト」はプロダクトというイメージになります。

　

プロジェクトに入るとOverviewが表示され、早速Pipelineが使えるようになります。
※おそらくプロジェクト作成直後はすぐにPipelineの登録画面に遷移していると思います。

　　

Pipelinesの登録では、App Center同様にCI/CD対応したいリポジトリを指定する必要があります。
このとき、Azure Pipelinesと各サービスのアカウントが連携できてないと表示されないのでその都度連携を対応することになります。

また、その先に進むと更に指定したリポジトリとAzure Pipelinesとの連携が要求されます。

　　

　　

すると次のようにCI/CDの設定ファイルとなるPipelineのYAMLテンプレートが用事されるため、アプリをビルドするコマンドなどを書いていきます。
YAMLに関する詳細は、公式のYAML schema referenceを参照してください。

設定がある程度できたらSaveまたはSave and runでYAMLを保存させ、試しにジョブを走らせてみましょう。
JobsのJobをクリックするとビルドログが見れたりします。

　　

　　

変数を使用したい場合は、YAMLの設定画面上に表示されているVariables、またはジョブを起動させる際のRun pipeline上に表示されているVariablesから指定することができます。
この違いは、前者はパイプラインのデフォルトとして設定し、後者はビルド毎にデフォルトの設定を上書きまたは追加などできるようになります。

　　

ちなみにデフォルトだと、origin/HEADが付いているmasterブランチやdevelopブランチに何らかの変更がマージされたり、pushされると自動的にジョブが動く仕様になっています。
変更する際は、右上のドット縦三つメニューからsettingsを選び、Pipeline settings上から制御することができます。

　

Azure PipelinesでのCI/CD管理についてですが、1リポジトリ＝1パイプラインという関係となり、組織→プロジェクト→パイプライン→ジョブという関係で管理することになります。

YAML設定について注意

パイプライン設定ですが、初回の設定やその後の調整を行いSaveを行うとリポジトリに対して直接Pushされます。
そのため、既存のリポジトリでAzure Pipelineの対応を進める際にすでに特定のカスタマイズが行われている場合は気をつける必要があります。

　

例えば、developブランチにPushが行われるとSlack通知が飛ぶなどのサードパーティ連携があるかなと。
前提として、App CenterもAzure Pipelinesも連携するアカウントは管理者権限が必要で、アカウントとアプリとの連携の際に読み込みだけでなく、書き込みも権限として了承するため最初は気づきにくいですが、チーム開発している際は前もって周知をしておくと良いかなと。

YAMLの管理について

本格的に運用する際は、masterブランチやorigin/HEADがついているブランチに直接pushすることは問題になると思います。
そのため、前もって作業用ブランチを作成し、そのブランチに対して変更内容をpushしてジョブを実行させると運用しやすいでしょう。

ただ、次の課題としてジョブのログを見るRuns画面のリスト上で定期実行しているジョブとテストしているジョブが乱雑することになるので、ぱっと見すぐに判別できる工夫が必要だなと思いました（Azure PipelinesのUI/UXデザインのよくない点だと思いますが笑）。
例えば、Commit messageに特定の文字を入れて定期ジョブだと分かりやすいようにするルール決めが考えられます。

　　

パイプライン/ジョブ間でのデータ共有について

Jenkinsの場合は、動作しているマシーン上でファイル操作が可能でCircleCIの場合は、persist_to_workspaceとattach_workspaceを用いて各ジョブでのデータ共有ができます。

Build Artifacts

特定のジョブでビルドされたArtifacts（成果物）を保存し、別のジョブでそのArtifactsをDownloadしてデータ共有できる機能です。

• Publish Build Artifacts task

- script: |
    sh build.sh
    cp -r ./logs/ $(Build.ArtifactStagingDirectory)
  displayName: 'logs save'

- task: PublishBuildArtifacts@1
  inputs:
    pathToPublish: $(Build.ArtifactStagingDirectory)
    artifactName: 'logs'
    publishLocation: 'Container'

• Download Build Artifacts task

- task: DownloadBuildArtifacts@0
  inputs:
    buildType: 'specific'
    project: 'gremito.net'
    artifactName: 'logs'
    pipeline: '4'    # パイプラインのID
    buildId: '28'    # ジョブのID
    downloadPath: "$(System.ArtifactsDirectory)/download"

Pipeline Artifacts

特定のパイプラインでビルドされたArtifacts（成果物）を保存し、別のパイプラインででそのArtifactsをDownloadしてデータ共有できる機能です。

• Publish Pipeline Artifacts task

- script: |
    sh build.sh
    cp -r ./logs/ $(System.DefaultWorkingDirectory)
  displayName: 'logs save'

- task: PublishPipelineArtifact@1
  inputs:
    targetPath: $(Pipeline.Workspace)
    artifactName: 'logs'

• Download Pipeline Artifacts task

- task: DownloadPipelineArtifact@2
  inputs:
    source: 'specific'
    project: 'gremito.net'
    pipeline: 4             # パイプラインのID
    runVersion: 'latest'    # 最新のジョブを指定
    path: "$(Pipeline.Workspace)/download"

VariablesでKeep this value secretの使用に注意

環境変数を使いたい場合は、Variablesに登録することによって対応できます。
その際にトークンやパスワードなどの情報をセキュアにするためにKeep this value secretにチェックしてValueをhtml:password扱いにすることがあると思います。

すると見落としがちですが、下の詳細に次のようなメッセージが表示されます。

To use a secret variable in a script, you must explicitly map it as an environment variable.

公式ドキュメントのDefine variables > Set secret variablesによると次のようにazure-pipelines.ymlに環境変数の指定が必要で、もしこれが無ければ指定してもValueが空っぽになります。（ハマりました笑汗）

- script: |
    sh ./build.sh

  env:
    TOKEN: $(TOKEN)
    SECRET: $(SECRET)

  displayName: 'run shell'

他CI/CDツールとの違い

個人的には、CircleCIに近いCI/CDサービスだと感じました。
もしCircleCIとAzure Pipelinesのどちらかを選択すると考えた際に次の利点が決め手かなという所感です。

• プロダクトのプラットフォームがWindowsまたはAzureを用いている
  • Microsoft製品を扱っているのであれば断然Azure Pipelinesかなと
• まずは無料プランで複数リポジトリをビルドさせたい
  • CircleCIはリポジトリ1つまででAzure Pipelinesは組織は1つまででその中に複数リポジトリのパイプラインを作ることができるため
• ビルドする環境でmacOSを使いたい
  • 現在2020年3月末でCircleCIでmacOSは無料プランで「近日リリース」と表記され使えない状態でAzure Pipelinesは無料プランでもmacOSが扱えます

※ CircleCI - Pricing
※ Azure DevOps - Pricing

CircleCIとAzure Pipelinesのサポートについて

両者ともにできることが似ていますが、サポートしている量および内容が違います。
次の公式ページからCI/CD対応する環境がどちらにマッチしているのかも検討が必要かもしれません。
「サポートされていないからできない」ではなく、他の機能で代用が効くこともあるので無料プランで試してしっかり比較することをオススメします。

• CircleCI Orb Registry
• Azure Pipelines - Task index

まとめ

これで、App CenterとAzure Pipelinesが入門でき、CI対応する際に迷わずどちらを選べば良いのか把握できたのではないでしょうか。
CD対応については今回あまり触れていないため、アプリの自動デプロイについては別の機会でまとめたいと思います。

所感

App Centerはすぐに扱い慣れてシンプルで問題なければコスパ良いですが、カスタマイズ性がほぼないのでどこかでAzure Pipelinesに移行する可能性が出てきますよね。

Azure Pipelinesは、学習コストがそこそこかかったので最初が辛い印象です。
また、サポートは全てGitHubのIssue上でのやりとりになるため、対応が通常より遅い場合もあったり、問題がハッキリと解決できておらず勝手にCloseされるケースも見られるためサポートがあまりあてにならないようです。
その分、サービスとしては無料枠で結構やれることとUI/UXデザインが他のCI/CDツールより良い印象なので今後も適度に使って、CircleCIとの比較を出していきたいなと思いました。