App Center と Azure Pipelines について


## 概要

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

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


## 結論

先に双方異なるポイントを解説します。公式ドキュメントの[App Center Build vs. Azure DevOps Pipelines](https://docs.microsoft.com/ja-jp/appcenter/build/choose-between-services)に書かれている通り、次の背景から採用するポイントが異なります。

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

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


### ビルドがシンプルとは

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

```shell

# 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](https://www.buildinsider.net/enterprise/jenkins/005)/[CircleCI Workflow](https://circleci.com/docs/ja/2.0/workflows/)を必要とする開発環境であれば、Azure Piplinesを採用されてください。

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

[上記の課題をmicrosoft/appcenterにissue化](https://github.com/microsoft/appcenter/issues/1725#issuecomment-597847691)したため、ワンチャン受託されて新規機能としてサポートされる未来があるかもしれません笑


## [App Center](https://visualstudio.microsoft.com/ja/app-center/)

　<a href="https://medium.com/@bharatchavan/react-native-appcenter-analytics-and-crash-reporting-c5ff19e1f768"><img width="650" alt="1_RzCHqsM377400N-ImfdTxA.jpeg" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/82601/67abbdd9-2364-ef32-ddbf-66f4b13a0978.jpeg"></a>

App Centerの売りとしては、上図に記載している6つのマイクロサービスを使うことができ、[無料プラン](https://visualstudio.microsoft.com/ja/app-center/pricing/)で制限はあるものの全て使用することができます。

Microsoft社は、[数年前にHockeyAppを買収](https://japan.zdnet.com/article/35057794/)しており、その後HockeyAppは[去年2019/11/16でサービスを終了しました。](https://techcrunch.com/2018/11/17/microsoft-to-shut-down-hockeyapp/)
以降、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のトップ画面が表示されると思います。

　<img width="450" alt="スクリーンショット 2020-03-09 14.54.36.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/82601/46dae5f1-572e-bd9e-6beb-da57e3faf2d6.png">

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

　<img width="400" alt="スクリーンショット 2020-03-09 14.54.47.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/82601/bf7aac01-3226-036e-9af0-1fe1a57d4655.png">

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

　<img width="450" alt="スクリーンショット 2020-03-09 14.57.06.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/82601/0e968335-b4bb-6b33-8a43-9c7f5b2cdc80.png">

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

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

　<img width="350" alt="スクリーンショット 2020-03-09 14.57.53.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/82601/de32d45a-cf74-e82a-d395-65c3c48f3a3b.png">　<img width="350" alt="スクリーンショット 2020-03-09 14.58.02.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/82601/f8ab2f94-38c4-2741-f577-0e1c4faac377.png">

　<img width="400" alt="スクリーンショット 2020-03-09 14.59.16.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/82601/4d8ea97d-0f42-1131-eec3-ff6fb6d590f2.png">

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

　<img width="600" alt="スクリーンショット 2020-03-09 15.00.15.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/82601/b9688b03-2d2a-24a4-00ba-b9630258ebda.png">


#### Overview

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

　<img width="600" alt="スクリーンショット 2020-03-17 13.19.38.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/82601/f76e68cd-1e01-25af-fadd-9065b9a63ece.png">



### TIPS

　<img width="600" alt="スクリーンショット 2020-03-10 12.00.22.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/82601/f9eab627-9c4c-d77a-fbcc-904ff664346b.png">

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

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

　<img width="600" alt="スクリーンショット 2020-03-10 12.16.02.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/82601/791bd4b6-231f-9478-2b5d-716c1d787682.png">

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

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

　<img width="400" alt="スクリーンショット 2020-03-10 12.10.46.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/82601/5d0ab7d6-26b5-3322-0342-32a648d3b178.png">

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

さらに詳しい詳細は、公式の[Visual Studio App Center documentation](https://docs.microsoft.com/ja-jp/appcenter/)に載っているので確実良しなに確認してください。


### 参考記事

- [Visual Studio App CenterについてAndroid Test Night、iOS Test Nightで話してきました。](http://nakasho-dev.hatenablog.jp/entry/2018/04/18/005429)
- [Visual Studio App Center で、自動ビルド後に Android の自動実機UIテストを実行する方法](https://hiro128.hatenablog.jp/entry/2018/11/22/231905)
- [App Center Hands On with Xamarin](https://github.com/ytabuchi/AppCenterSample/blob/master/AppCenterHandsOn.md)


## [Azure Pipelines](https://azure.microsoft.com/ja-jp/services/devops/pipelines/)

　<a href="https://azure.microsoft.com/ja-jp/services/devops/pipelines/"><img width="650" alt="スクリーンショット 2020-03-09 18.52.39.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/82601/11d7350d-5f01-9bd3-bedc-f38a27136c1b.png"></a>

複数のマイクロサービスを提供している[Azure DevOps](https://azure.microsoft.com/ja-jp/services/devops/)内の1つであるAzure Pipelinesは、JenkinsとCircleCIでやれることは同様にサポートしており、他CI/CDツールとの差別化として次の内容が所感でした。

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


### 入門

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

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

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

　<img width="600" alt="スクリーンショット 2020-03-09 12.54.11.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/82601/076cf4a0-2b3e-3e2f-eef5-e94e819b68c2.png">

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

　<img width="350" alt="スクリーンショット 2020-03-24 17.16.43.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/82601/c833e157-de2e-839d-ea7e-83dc379e0a5e.png">　<img width="365" alt="スクリーンショット 2020-03-09 12.55.43.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/82601/e09b795b-da7a-81f6-96a8-40dd632b1a66.png">

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

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

　<img width="350" alt="スクリーンショット 2020-03-09 12.55.55.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/82601/e58e6fb9-dacc-d356-ea71-822ec2f7f0ba.png">　<img width="350" alt="スクリーンショット 2020-03-09 12.56.11.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/82601/553ec7e8-d674-7525-0670-08c4aa373ada.png">

　<img width="340" alt="スクリーンショット 2020-03-24 19.56.06.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/82601/85941c75-1757-642e-e383-91f5f9e967e9.png">　<img width="415" alt="スクリーンショット 2020-03-24 20.00.48.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/82601/d6223108-c7fb-7a96-7afe-10be87388b16.png">


すると次のようにCI/CDの設定ファイルとなるPipelineのYAMLテンプレートが用事されるため、アプリをビルドするコマンドなどを書いていきます。
YAMLに関する詳細は、公式の[YAML schema reference](https://docs.microsoft.com/en-us/azure/devops/pipelines/yaml-schema)を参照してください。

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

　<img width="320" alt="スクリーンショット 2020-03-24 20.09.13.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/82601/89203715-efc4-b0dc-b1a2-91d062cb7132.png">　<img width="400" alt="スクリーンショット 2020-03-25 11.16.47.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/82601/d20a640d-7980-ecf9-7407-2caaba2ccdac.png">

　<img width="360" alt="スクリーンショット 2020-03-25 12.12.43.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/82601/45dc5030-0e83-d893-dff0-70f41cdfef55.png">　<img width="360" alt="スクリーンショット 2020-03-25 12.13.32.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/82601/903ec8d4-a536-8f81-9321-e2ce48fb4b67.png">



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

　<img width="230" alt="スクリーンショット 2020-03-25 11.23.41.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/82601/df1875cb-918a-dfeb-ac84-6765134f9a2a.png">　<img width="250" alt="スクリーンショット 2020-03-09 13.00.09.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/82601/c5f2027e-6e6e-b8af-116c-8d5c233f75f5.png">


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

　<img width="400" alt="スクリーンショット 2020-03-25 11.15.02.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/82601/f9faa431-55f1-2b8d-e707-3e969dbe29b1.png">


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


### YAML設定について注意

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

　<img width="600" alt="スクリーンショット 2020-03-16 15.23.43.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/82601/5587de12-970e-2edc-7e2e-b29cb46f0630.png">

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


#### YAMLの管理について

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

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

　<img width="400" alt="スクリーンショット 2020-03-25 15.12.30.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/82601/75303208-5329-1897-81d1-7133e1f5f13d.png">　<img width="300" alt="スクリーンショット 2020-03-25 15.18.33.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/82601/dc9e4b43-3419-7986-762a-4a76d0586bae.png">



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

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


#### Build Artifacts

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

- [Publish Build Artifacts task](https://docs.microsoft.com/ja-jp/azure/devops/pipelines/tasks/utility/publish-build-artifacts?view=azure-devops)

```yaml
- 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](https://docs.microsoft.com/ja-jp/azure/devops/pipelines/tasks/utility/download-build-artifacts?view=azure-devops)

```yaml
- 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](https://docs.microsoft.com/ja-jp/azure/devops/pipelines/tasks/utility/publish-pipeline-artifact?view=azure-devops)

```yaml

- 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](https://docs.microsoft.com/ja-jp/azure/devops/pipelines/tasks/utility/download-pipeline-artifact?view=azure-devops)

```yaml
- 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](https://docs.microsoft.com/en-us/azure/devops/pipelines/process/variables?view=azure-devops&tabs=yaml%2Cbatch#secret-variables)によると次のように`azure-pipelines.yml`に環境変数の指定が必要で、もしこれが無ければ指定してもValueが空っぽになります。（ハマりました笑汗）

```yaml
- 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](https://circleci.com/ja/pricing/)
※ [Azure DevOps - Pricing](https://azure.microsoft.com/ja-jp/pricing/details/devops/azure-devops-services/)


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

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

- [CircleCI Orb Registry](https://circleci.com/orbs/registry/)
- [Azure Pipelines - Task index](https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/?view=azure-devops)



## まとめ

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


### 所感

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

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