2020-04-27

Visual Studio App Centerを使って内部向けに継続的にネイティブアプリを配信する（※追記あり）

はじめに

ネイティブアプリの内部テストを円滑にすすめるために、Visual Studio App Centerを使ってアプリを配信する仕組みを触る機会があったので手順をまとめておきます。

Visual Studio App Centerとは

Microsoftが提供しているネイティ・デスクトップアプリ開発向けの開発プラットフォームです。Azure DevOpsとの連携やアプリのデバイス上でのテスト実行、ストア配信などもサポートしており、ビルドやテストの実行に一定時間の無料枠があります。

visualstudio.microsoft.com

今回はビルド済みのAndroidアプリおよびiOSアプリをテスト端末へ配信する手順をまとめます。

1. Visual Studio App Centerの準備をする

アカウントとプロジェクトを作成する

Visual Studio App Centerは以下のID連携を使ってアカウントを作成することができます。

GitHub
Microsoft Account / Azure Account
Facebook
Google

以前はメールアドレスでのアカウント作成もできたようなのですが、今は上記のアカウントからしか利用できないようです。メールアドレスで作成済みのユーザはメールアドレスにてログインできるようです。

今回はGoogleアカウントで作成します。作成するときにOwner Nameを定義することができ、URLに利用されます。

ログインでの認証でIP制限を用いたいケースは、アカウント管理をAzureのIDアカウント管理に任せ、認証画面にFirewallを設定するとよさそうです。

ログインが完了したら、次にアプリのプロジェクトを作成します。

Android用のプロジェクトは右のAdd New appから作成できます。

f:id:takamii228:20200420214929p:plain

今回はBetaとしました。他にも配信中のアプリや内部テストといったラベルがつけられるようです。

iOSも同様に作成します。

f:id:takamii228:20200420215026p:plain

これで前準備は完了です。アカウントのOwner Name、プロジェクトIDをあとで利用するのでそれぞれ控えておきましょう。

f:id:takamii228:20200420215301p:plain

API トークンを発行する

以後APIにてApp Centerのリソースにアクセスするため、ログインしたユーザのAPI トークンを発行しておきましょう。API トークンはユーザのAccount Settingsのメニューの中で発行できます。

f:id:takamii228:20200420215755p:plain

2. apkファイル・ipaファイルを作成する

Visual Studio App Center上でもアプリのビルドは実施できますが、ここでは別環境にてビルドしたipaファイル・apkファイルを配布するというシナリオを説明します。

それぞれ個別に作成するのが面倒だったので、Flutterのプロジェクトを作成したときに最初に作られるサンプルアプリをベースにipaファイルとapkファイルを作成しておきます。こういうときはクロスプラットフォームは便利ですね。

apkの署名はデバッグプロファイルで、ipaは後でインストールする端末の情報を含んだprovisioning profileファイルで署名したものを用意します。

Flutterを使ってapk・ipaファイルを作成する手順はこちらを参考にしてください。

takamii.hatenablog.com

3. Visual Studio App Centerへapk・ipaファイルをアップロードする

公式のドキュメントを参考にアップロードに必要な処理を確認します。

docs.microsoft.com

ドキュメントにはcurlコマンドを使った手順がのっているので、今回はこれを参考にシェルスクリプトを組んで行きます。

なおnpmコマンド経由でもできるようですが、Node環境の準備が面倒なので今回は使いません。

docs.microsoft.com

追記（2021/10/18）

以下のアップロード方法ではアップロードに失敗するようになりました。代替手段としてappcenter cliを使う方法を記事に起こしましたのでそちらを参照ください。

takamii.hatenablog.com

手順を見ればわかりますが、やることは単純でアップロード用のURLを発行して、その発行したURLを使ってファイルをアップロードするだけです。ただしファイルをアップロードするだけだと配信は完了しないため、追加のAPIリクエストを実行して配信のリクエストも自動化してしまいましょう。

APIの仕様書はOpen APIにて公開されています。

openapi.appcenter.ms

なおVisual Studio App Centerで表示されるバージョンはアプリの組み込まれているバージョンで、プロジェクト上の通番はアップロードごとに自動的にRelease IDとしてインクリメントされます。

各Release IDに対してrelease_noteという説明欄を利用できるのですが、これはファイルアップロードのIFでは利用できません。

そのため、リリースとタグ名を紐付けるためにはアップロードが完了したあとに最新のRelease IDを取得し、そのReleaseに対してリリースのタグ名を紐付けるようなPATCHリクエストを投げるとよいでしょう。

最後に配信対象のグループを指定して配信APIを実行すれば配信が開始されます。

以上をまとめると、以下のようなAPIリクエストを順番に実行すればよいです。

ファイルアップロード用のURLを発行する
ファイルをアップロードする
最新のRelease ID（2で作成されたRelease）を取得する
3のRelease IDに対応するRelease Noteを更新する
3のRelease IDの配信を対象のグループに対して開始する

シェルスクリプトでまとめると以下のようになります。

#!/bin/sh

set -x
set -e

# タグ名
RELEASE_TAG_NAME=${1}

# APK ファイルパス
ANDROID_APK_FILE_PATH=${2}

# ipa ファイルパス
IOS_IPA_FILE_PATH=${3}

# Visual Studio App Centerのパラメータ
AZURE_APPCENTER_API_TOKEN='xxxxxxxx'
AZURE_APPCENTER_API_BASE_URL='https://api.appcenter.ms/v0.1/apps'
AZURE_APPCENTER_OWNER_NAME='takamii228'
AZURE_APPCENTER_ANDROID_PROJECT_NAME='AndroidSample'
AZURE_APPCENTER_IOS_PROJECT_NAME='iOSSample'
AZURE_APPCENTER_DISTRIBUTE_GROUP_ID='00000000-0000-0000-0000-000000000000'

# AppCenterにアップロードする一連の処理をまとめた関数
#
# $1: AppCenterのプロジェクト名
# $2: アップロードファイルパス 
# $3: タグ名
#
function upload_file_to_appcenter () {
  UPLOAD_API_BASE_URL=${AZURE_APPCENTER_API_BASE_URL}'/'${AZURE_APPCENTER_OWNER_NAME}'/'${1}

  # アップロード用のURLを発行する
  APP_CENTER_UPLOAD_URL=`curl -v -X POST -H 'Content-Type: application/json' \
    -H 'Accept: application/json' \
    -H 'X-API-Token: '${AZURE_APPCENTER_API_TOKEN} \
    ${UPLOAD_API_BASE_URL}'/release_uploads' | jq -r .upload_url`

  # ファイルをアップロードする
  curl -v -F "ipa=@${2}" ${APP_CENTER_UPLOAD_URL}

  # アップロードしたアプリのリリースIDを取得する
  RELEASE_ID=`curl -v -X GET -H 'Content-Type: application/json' \
  -H 'Accept: application/json' \
  -H 'X-API-Token: '${AZURE_APPCENTER_API_TOKEN} \
  ${UPLOAD_API_BASE_URL}'/releases' | jq 'max_by(.id) | .id'`

  # アップロードの中でRelease Noteは更新できないため、作成されたリリースIDに対してPATCHリクエストを投げる
  curl -v -X PATCH -H 'Content-Type: application/json' \
    -H 'Accept: application/json' \
    -H 'X-API-Token: '${AZURE_APPCENTER_API_TOKEN} \
    -d '{ "release_notes": "'"${3}"'" }' \
    ${UPLOAD_API_BASE_URL}'/releases/'${RELEASE_ID}

  # アップロードしたアプリをCollaboratorsに配信する
  curl -v -X POST -H 'Content-Type: application/json' \
    -H 'Accept: application/json' \
    -H 'X-API-Token: '${AZURE_APPCENTER_API_TOKEN} \
    -d '{ "id": "'"${AZURE_APPCENTER_DISTRIBUTE_GROUP_ID}"'", "mandatory_update": false, "notify_testers": true }' \
    ${UPLOAD_API_BASE_URL}'/releases/'${RELEASE_ID}'/groups'

  echo "App file ${2} was released in Visual Studio App Center in Project: ${1} for TAG: ${3}, Release ID: ${RELEASE_ID}"
}

# apkファイルをアップロードする
upload_file_to_appcenter ${AZURE_APPCENTER_ANDROID_PROJECT_NAME} ${ANDROID_APK_FILE_PATH} ${RELEASE_TAG_NAME}

# ipaファイルをアップロードする
upload_file_to_appcenter ${AZURE_APPCENTER_IOS_PROJECT_NAME} ${IOS_IPA_FILE_PATH} ${RELEASE_TAG_NAME}

上記のシェルスクリプトをtag push契機で実行するようにCDパイプラインを組むとアップロードと配信を自動で実行できるようになります。

$ ./upload-app-to-appcenter.sh 1.0.0-dev app-release.apk Runner.ipa

4. Visual Studio App Centerからアプリをダウンロードする

配信が開始されると対象者にメール通知が飛んできます。インストールしたい端末にてそのURLを開き、ログインをするとダウロードリンクを取得することができます。

ダウンロード画面のブラウザでの表示はデフォルトではビルド番号・バージョン番号順になっているため、開発中は固定にしている場合はファイルの識別が難しいです。なので3で説明したとおり、release_noteにタグ名を書いておくと識別しやすいでしょう。

Android上でapkファイルをインストールする

Androidの場合はそのままapkファイルをダウンロードすることでアプリを端末にインストールすることができます。

iOS上でipaファイルをインストールする

iOSの場合はprovisioning profileやiPhoneのApple IDのアカウントの設定にもよりますが、appcenterの構成プロファイルのインストールを端末上で求められるケースがあるようです。

まとめ

以上がVisual Studio App Center経由でapk/ipaファイルを配信する手順になります。

ipaファイル・apkファイルを作成するCDパイプラインとシームレスに繋げば、tag push契機でテスト用アプリを配信することができるようになりますね。

以前紹介したFlutterのCDパイプラインと合わせてみると以下のようなイメージになります。便利〜！

f:id:takamii228:20200427110819p:plain

内部で手軽にアプリを配信できるような仕組みを用意しておくことで、モバイルアプリでもサーバサイドと同等レベルのよりEnd-to-Endの継続的デリバリーが実現でき、QAやUI確認等の開発のフィードバックライフサイクルをより短縮することができるでしょう。

余談

AppCenter便利やわ〜と思ってた矢先に、配信済みの資材が一斉に消えるという場面に遭遇しました。

え、やっぱ課金必要だったの！？とか焦ってたら公式から障害の連絡が出てました。

[Status] Investigating: App Center is experiencing issues in the Build service with GitHub repositories. We apologize for the inconvenience while we work to resolve this issue. https://t.co/eofRpcv64K
— VSAppCenter Status (@AppCenterStatus) 2020年4月23日

何があったかは書いてないですが、Distributeの部分に障害があったとのこと。焦りました。

App Center Status - Distribute is Experiencing Issues

サービスのステータスはこちらで確認できるようです。「あれ？」と思ったときはまずこちらを見てみるようにしましょう。

status.appcenter.ms

2020-04-26

Flutterを使ったAndroid・iOSアプリ開発のCDパイプラインを構築する #flutter

はじめに

前回はCIパイプラインについて前半・後半に分けて説明を行いました。

takamii.hatenablog.com

今回はCDパイプラインについて説明します。

CDとは継続的デリバリー（Continuouse Delivery）の略で、アプリケーションを継続的に短いサイクルでリリース可能な状態にするプラクティスのことを指します。

Android / iOSアプリにおけるCDパイプラインとは、ソースコードからアプリを端末にインストールしたりストア申請可能な状態であるapkファイル・ipaファイルをいつでも作成できる状態にする、ということになります。

今回の検証に利用したFlutter環境は以下の通りです。

$ flutter doctor
Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel unknown, v1.12.13+hotfix.9, on Mac OS X 10.15.4 19E266, locale en-JP)
[✓] Android toolchain - develop for Android devices (Android SDK version 28.0.3)
[✓] Xcode - develop for iOS and macOS (Xcode 11.4.1)
[✓] Android Studio (version 3.6)

また今回はapk/ipaファイル作成のみについて触れるのですが、実際の開発現場では検証環境や内部テスト向けのアプリと実際の配信するアプリを環境差分で分けて管理する必要があると思います。

Flutterの場合はflavorを独自に定義することで、それらについても対応することができるのですが今回はそこの説明はスコープ外とします。

軽く触れると、Androidは通常のAndroidと同様のやり方でできます。iOSについては命名規則に従ってSchemeを定義すればよいです。こちらが参考になります。

medium.com

Flutterを使ったAndroidアプリでapkファイルを作成する

Flutterで構築したアプリケーションからapkファイルを作成する方法は基本的には公式のガイドに従えばよいです。

flutter.dev

Android固有の設定

FlutterのAndroid側のプロジェクトにはandroid pluginを内包しているため、基本的には通常のAndroidと同じビルド設定で問題ありません。　

公式のガイド通りに以下をbuild.gradleに設定していけばよいでしょう。

apkの署名設定
R8によるアプリ圧縮設定
R8（proguard）による難読化設定
バージョン番号とバージョンコードの設定

Flutterにはデフォルトでdebug、profile、releaseの3種類のbuildTypeが用意されていますが、apkを作るときにはreleaseのところに設定を記述しましょう。

ビルドスクリプトを構築する

公式ガイド通りにflutter build apk --releaseコマンドを実行すればよいです。

引数でtarget-platformやビルド番号・バージョン番号が指定できるので、32bitと64bitを分けてビルドする場合は指定するようにしましょう。

FlutterはAppBundleにも対応しているようなのでそれを利用しても良いかもしれません。

今回はバージョン番号を引数に受け取って32bit/64bit別々にビルドするシェルスクリプトを作ってみました。

ストア申請のときに32bitと64bitを分けて申請する場合は32bitのバージョン番号より64bitのバージョン番号を大きくしておく必要があるので、シェルの中で+1するようにしました。

developer.android.com

build-android-apk.sh

#!/bin/sh
set -x
set -e

# TARGET_APP_VERSION
TARGET_APP_VERSION=${1}

# TARGET_VERSION_CODE
TARGET_VERSION_CODE_ARM=${2}
TARGET_VERSION_CODE_ARM64=$(expr ${2} + 1)

# Artifacts Path
OUTPUT_APK_PATH="./artifacts/android"

# cleanを実行
flutter clean

# 依存関係を解決
flutter pub get

# arm用のapkを作成
flutter build apk --release --target-platform=android-arm \
  --build-name=${TARGET_APP_VERSION} --build-number=${TARGET_VERSION_CODE_ARM}

# 成果物をコピー
cp build/app/outputs/apk/release/app-release.apk \
  ${OUTPUT_APK_PATH}/app-release-arm-${TARGET_APP_VERSION}.${TARGET_VERSION_CODE_ARM}.apk

# cleanを実行
flutter clean

# arm64用のapkを作成
flutter build apk --release --target-platform=android-arm64 \
  --build-name=${TARGET_APP_VERSION} --build-number=${TARGET_VERSION_CODE_ARM64}

# 成果物をコピー
cp build/app/outputs/apk/release/app-release.apk \
  ${OUTPUT_APK_PATH}/app-release-arm64-${TARGET_APP_VERSION}.${TARGET_VERSION_CODE_ARM}.apk

実行ログは以下のようになります。

$ ./build-android-apk.sh 1.0.0 100
+ set -e
+ TARGET_APP_VERSION=1.0.0
+ TARGET_VERSION_CODE_ARM=100
++ expr 100 + 1
+ TARGET_VERSION_CODE_ARM64=101
+ OUTPUT_APK_PATH=./artifacts/android
+ flutter pub get
Running "flutter pub get" in appcenter_sample...                    0.3s
+ flutter clean
Cleaning Xcode workspace...                                         3.0s
Deleting build...                                                  105ms
Deleting .dart_tool...                                               1ms
+ flutter build apk --release --target-platform=android-arm --build-name=1.0.0 --build-number=100
Removed unused resources: Binary resource data reduced from 44KB to 35KB: Removed 20%
Running Gradle task 'assembleRelease'...                                
Running Gradle task 'assembleRelease'... Done                      39.4s
✓ Built build/app/outputs/apk/release/app-release.apk (5.1MB).
+ cp build/app/outputs/apk/release/app-release.apk ./artifacts/android/app-release-arm-1.0.0.100.apk
+ flutter clean
Cleaning Xcode workspace...                                         2.0s
Deleting build...                                                   82ms
Deleting .dart_tool...                                               2ms
+ flutter build apk --release --target-platform=android-arm64 --build-name=1.0.0 --build-number=101
Removed unused resources: Binary resource data reduced from 44KB to 35KB: Removed 20%
Running Gradle task 'assembleRelease'...                                
Running Gradle task 'assembleRelease'... Done                      35.3s
✓ Built build/app/outputs/apk/release/app-release.apk (5.4MB).
+ cp build/app/outputs/apk/release/app-release.apk ./artifacts/android/app-release-arm64-1.0.0.101.apk

Flutterを使ったiOSアプリでipaファイルを作成する

Android同様、iOSでもFlutterの公式ドキュメント通りに実行すればよいです。

flutter.dev

iOS固有の設定

通常のiOS アプリ開発と同様、ipaファイル作成に必要な証明書とprovisioning profileを準備してビルドを実行するマシンにインストールしておきます。

Android同様、FlutterにはデフォルトでDebug、Profile、Releaseの3種類のSchemeが定義されていて、ipa作成時にはReleaseのスキームを利用します。Androidと異なって頭文字が大文字な点に注意が必要です。

追加でビルド時に実行したいものがあればReleaseのスキームの設定の中に追記しておくとよいでしょう。

ビルドスクリプトを構築する

公式ガイドを読むと以下を順番に実行せよと書いてあります。

flutter build ios --releaseを実行する
XCode上でバージョン番号とビルド番号を設定し、Generic iOS DevicesでArchiveビルドを実行する
Archiveファイルをビルドしてipaファイルを作成する

要はflutterコマンドを実行した後にxcodebuildコマンドを実行すればよいのです。

Archiveファイルからipaファイルを作成するときにExportOptions.plistファイルが必要なので、環境に応じて準備しておきましょう。

iOSもバージョン番号は外から注入できるようにしてスクリプトを組みましょう。

build-ios-ipa.sh

#!/bin/sh
set -x
set -e

# TARGET_APP_VERSION
TARGET_APP_VERSION=${1}

# TARGET_BUILD_NO
TARGET_BUILD_NO=${2}

# Artifacts Path
OUTPUT_APK_PATH="./artifacts/ios"

# cleanを実行
flutter clean

# 依存関係を解決
flutter pub get

# flutter buildを実行
flutter build ios --release \
  --build-name=${TARGET_APP_VERSION} --build-number=${TARGET_BUILD_NO}

cd ios

# archiveを作成
EXPORT_OPTION_PLIST="ExportOptions.plist"

xcodebuild -workspace Runner.xcworkspace -scheme Runner -sdk iphoneos \
  -configuration Release archive -archivePath ../build/Runner.xcarchive

# ipa ファイルを作成
xcodebuild -allowProvisioningUpdates -exportArchive \
  -archivePath ../build/Runner.xcarchive \
  -exportOptionsPlist ${EXPORT_OPTION_PLIST} -exportPath ../build/ios-release

cd ..

# 成果物をコピー
cp ./build/ios-release/Runner.ipa ${OUTPUT_APK_PATH}/app-release-${TARGET_APP_VERSION}.${TARGET_BUILD_NO}.ipa

実行ログは途中は省略しますが以下のようになります。

$ ./build-ios-ipa.sh 1.0.0 100
+ set -e
+ TARGET_APP_VERSION=1.0.0
+ TARGET_BUILD_NO=100
+ OUTPUT_APK_PATH=./artifacts/ios
+ flutter clean
Cleaning Xcode workspace...                                         2.0s
Deleting build...                                                   34ms
Deleting .dart_tool...                                               0ms
+ flutter build ios --release --build-name=1.0.0 --build-number=100
Building com.takamiii.appcentersample for device (ios-release)...
Automatically signing iOS for device deployment using specified development team in Xcode project: xxxxxxxx
Running Xcode build...                                                  
                                                   
 ├─Building Dart code...                                    13.9s
 ├─Generating dSYM file...                                   0.1s
 ├─Stripping debug symbols...                                0.0s
 ├─Assembling Flutter resources...                           0.7s
 └─Compiling, linking and signing...                         9.0s
Xcode build done.                                           26.1s
Built /Users/takami228/Documents/flutter-dev/flutter_sample/build/ios/iphoneos/Runner.app.
+ cd ios
+ EXPORT_OPTION_PLIST=ExportOptions.plist
+ xcodebuild -workspace Runner.xcworkspace -scheme Runner -sdk iphoneos -configuration Release archive -archivePath ../build/Runner.xcarchive
...
** ARCHIVE SUCCEEDED **

+ xcodebuild -allowProvisioningUpdates -exportArchive -archivePath ../build/Runner.xcarchive -exportOptionsPlist ExportOptions.plist -exportPath ../build/ios-release
2020-04-26 17:29:59.502 xcodebuild[34691:937911] [MT] IDEDistribution: -[IDEDistributionLogging _createLoggingBundleAtPath:]: Created bundle at path '/var/folders/6n/llxh8m296896rymtgjfbkmxw0000gn/T/Runner_2020-04-26_17-29-59.501.xcdistributionlogs'.
Exported Runner to: /Users/takami228/Documents/flutter-dev/flutter_sample/build/ios-release
** EXPORT SUCCEEDED **

+ cd ..
+ cp ./build/ios-release/Runner.ipa ./artifacts/ios/app-release-1.0.0.100.ipa

クラッシュレポートやFirebase Crashlyticsでクラッシュを解析するためにビルド時のdSYMファイルが必要になるケースがあるので、忘れないようにここでアップロードしたり退避させるのがよいでしょう。

CD環境と統合する

あとはbuild-android-apk.sh および build-ios-ipa.sh を署名情報や証明書がインストールされたマシンやCI環境でtagプッシュ契機で実行するようにすればCDパイプラインの完成です。

下の図はGitLab CIでの実行の流れを表した図になります。

f:id:takamii228:20200426175707p:plain

GitLab CIでは以下のように.gitlab-ci.ymlを定義すればよいでしょう。

...
release:
  stagie: build
  tags:
    - release-ci-runner
  only:
    - tags
  script:
    - ./build-android-apk.sh ${TARGET_APP_VERSION} ${TARGET_VERSION_CODE} 
    - ./build-ios-ipa.sh ${TARGET_APP_VERSION} ${TARGET_BUILD_NO}

まとめ

CI編と合わせてapk、ipaの作成を自動化するCDパイプラインを構築する例を説明しました。

CDパイプラインを自動化しておくことでリリース作業のハードルが下がり、リリース作業の属人化を防ぎ、結果としてリリース頻度を増やすことができます。

リリース頻度を増やすことはサービスの競争力を強化する大きなポイントとなるので、ぜひ参考にしてみてください。

またCIパイプラインと同様に、CDパイプラインも一度作って終わりではなく、アプリケーションを提供し続ける限り同様にメンテナンスが必要です。

Flutterはまだまだ変化が激しい技術領域なので、これから破壊的な変更が発生する可能性は0ではないので、前のめりで追従していく気持ちで頑張ってついていきましょう。

2021/7/2 追記

ipaを作成する flutter build ipaコマンドがflutter 2.0から利用できます。xcodebuildコマンドが省略できるのでぜひ利用してみてください。

takamii.hatenablog.com

2020-04-26

Flutterを使ったAndoird・iOSアプリ開発のCIパイプラインを構築する（後半） #flutter

はじめに

前半ではFlutterのCIパイプラインで実行する内容について説明しました。

takamii.hatenablog.com

後半では実際の開発におけるパイプラインの使い分けについて説明します。

CIパイプラインが開発のボトルネックに！？

CIパイプラインは重厚にすればするほど変更に対しての影響が早期に分かり、ソースの安定性を保つことができる一方で、開発が進んでテストケースが増えてくるとそれに比例してビルド時間も長くなってしまいます。

特にFlutterはAndroidとiOS両方のレポジトリを1つで管理するプロジェクト構成になるため、前半で説明したCIを毎回実行しているとあっという間にビルド時間が30分を超えてしまいます。

こうなってしまうとせっかくバグの早期発見やデグレ防止のために導入したCIパイプラインが足かせとなってしまい、機能追加・修正プロセスが重くなり、結果として開発のアジリティを下げてしまいます。

開発者がビルドに待てる時間は体感的にだいたい5分〜15分程度だと言われているので、定期的に実行時間を計測してビルドパイプラインを見直す必要があります。

ビルド時間を短縮する方法としては

ビルドの実行内容は固定し、ビルド環境を強化する
ビルドの実行内容は固定し、実行方法を見直す（ジョブ並列化、キャッシュ活用など）
ビルドの実行内容を見直す

の3つが考えられますが、今回は3番目について考えてみます。

3つのビルドパイプラインに分割する

前半で紹介した内容を並べると以下のようになります。

Flutterレイヤ（flutter-ci.sh）
Androidレイヤ (android-ci.sh)
iOSレイヤ (ios-ci.sh)
Androidの結合・E2Eテストレイヤ（android-e2e-test.sh）
iOSの結合・E2Eテストレイヤ（ios-e2e-test.sh）

さて、毎回のPull Request / Merge Requestで本当に毎回重厚なE2Eテストは実施する必要があるでしょうか。もちろんそれを確認できるに越したことはないですが、網羅的なE2Eテストは1OSに対しても10分以上かかってしまうためここを省略するように工夫します。

E2Eテストを全くやらなくしてもよいのですが、アプリが起動しなくなるような破壊的な変更がないかは即座に検知したいため、網羅的なE2Eテストの代わりにアプリの起動と主要導線に限った簡易的なE2Eテストをsmoke-testとして定義します。網羅的なE2Eテストは数時間置き、あるいは日時で最新のmasterからチェックアウトして実行するようにします。

つまり、以下の3つのビルドパイプラインを定義してそれぞれ適切なタイミングで実行するようにします。

PR / MRを出す前のコードPush時に実行されるブランチビルドパイプライン
PR / MRの発行・修正時に本当にマージして大丈夫かチェックするPR/MRパイプライン
現在のmasterに対して定期的にE2Eテストを実行するデイリーE2Eテストパイプライン

それぞれ説明していきます。

1. ブランチビルドパイプライン

ブランチビルドパイプラインは毎回のPushで実行される一番小さな単位のCIなので、静的解析とユニットテストのみを実行するようにします。10分程度で終わるとよいですね。

f:id:takamii228:20200426142048p:plain

2. PR/MRパイプライン

ここではブランチビルドの内容に加えて簡易的なE2Eテストを実行します。

E2Eテストも網羅的にすべて実行すると時間がかかってしまうため、アプリの起動と主要導線に限った簡易的なE2Eテストを用意し、それを実行するようにして時間を短縮します。通常の機能開発時では最低限アプリが起動することが確認できればよいでしょう。

f:id:takamii228:20200426142229p:plain

3. デイリーE2Eテストパイプライン

2のPR/MRパイプラインでは時間や計算リソース的な制約で簡易的な起動確認までしかチェックできていないため、定期的にmasterからチェックアウトして網羅的なE2Eテストを実行させ、既存の機能が壊れていないかを確認します。こうすることで仮にマージ時にバグを作り込んでしまったとしても、定期的に異常に気づくことができます。

この定期的なE2Eテストでスクリーンショットを撮るようにして、簡単なビュワーと連携させて日時での変更を視覚的に追ったり、簡易的なスナップショットテストみたいなことをやってみてもよいでしょう。

f:id:takamii228:20200426142535p:plain

各ブランチビルドパイプラインで実行する内容

各ブランチビルドパイプラインと実行する内容の対応は以下の表になります。

実行シェル	1.ブランチビルドパイプライン	2.PR/MRビルドパイプライン	3.デイリーE2Eテストパイプライン
flutter-ci.sh	○	○*	○*
android-ci.sh	○	○*	○*
iOS-ci.sh	○	○*	○*
android-smoke-test.sh	-	○	-
ios-smoke-test.sh	-	○	-
android-e2e-test.sh	-	-	○
ios-e2e-test.sh	-	-	○

*マークを付けましたが、PR/MRビルドパイプラインはブランチPush時に各CIが実行済みのためsmoke-testのみの実行でもよいでしょう。これについてはGitHubやGitLab等実行するレポジトリによって挙動が異なるため省略可能かどうかは実際に試してみるとよいです。

各ビルドパイプラインを.gitlab-ci.ymlに定義した例が以下になります。

...
branchBuild:
  stage: build
  tags:
    - ci-runner
  except:
    - merge_requests
  script
    - ./flutter-ci.sh
    - ./android-ci.sh
    - ./ios-ci.sh

mergeRequestBuild:
  stage: build
  tags:
    - ci-runner
  only:
    - merge_requests
  script
    - ./flutter-ci.sh //省略可
    - ./android-ci.sh //省略可
    - ./ios-ci.sh //省略可
    - ./android-smoke-test.sh
    - ./ios-smoke-test.sh

dailyE2ETest:
  stage: build
  tags: ci-runner
  only:
    - schedules
  script
    - ./flutter-ci.sh //省略可
    - ./android-ci.sh //省略可
    - ./ios-ci.sh //省略可
    - ./android-e2e-test.sh
    - ./ios-e2e-test.sh

dailyE2ETestはGitLabのCI/CD設定のスケジュールジョブで数時間置きor日時で実行するように設定すればよいです。

Pipeline schedules | GitLab

まとめ

前半と後半の2つに分けてFlutterのCIパイプラインについてまとめました。

説明の中ではCIパイプラインで実行する中身に関してのみ説明したので、Circle CI / CodeMagic / Bitrise / Travis CI / GitLab CI / Jenkinsなどなど、様々なCIプラットフォームで利用可能な内容だと思います。

CIパイプラインは一度作って終わりではなく、アプリケーションをメンテナンスし続ける限りアプリケーション同様のメンテナンスが必要です。定期的に実行時間を計測し、実行内容を見直さないとアプリケーションと同様にあっという間に負債化してしまうので注意しましょう。

そんなCIパイプラインをメンテナンスするビルドおじさんにぜひ相応のお賃金をください(おい）。

次はFlutterを使ったCDパイプラインについてまとめようと思います。

takamii.hatenablog.com

つばくろぐ @takamii228

知は力なり

Visual Studio App Centerを使って内部向けに継続的にネイティブアプリを配信する（※追記あり）

はじめに

Visual Studio App Centerとは

1. Visual Studio App Centerの準備をする

アカウントとプロジェクトを作成する

API トークンを発行する

2. apkファイル・ipaファイルを作成する

3. Visual Studio App Centerへapk・ipaファイルをアップロードする

追記（2021/10/18）

4. Visual Studio App Centerからアプリをダウンロードする

Android上でapkファイルをインストールする

iOS上でipaファイルをインストールする

まとめ

余談

Flutterを使ったAndroid・iOSアプリ開発のCDパイプラインを構築する #flutter

はじめに

Flutterを使ったAndroidアプリでapkファイルを作成する

Android固有の設定

ビルドスクリプトを構築する

build-android-apk.sh

Flutterを使ったiOSアプリでipaファイルを作成する

iOS固有の設定

ビルドスクリプトを構築する

build-ios-ipa.sh

CD環境と統合する

まとめ

2021/7/2 追記

Flutterを使ったAndoird・iOSアプリ開発のCIパイプラインを構築する（後半） #flutter

はじめに

CIパイプラインが開発のボトルネックに！？

3つのビルドパイプラインに分割する

1. ブランチビルドパイプライン

2. PR/MRパイプライン

3. デイリーE2Eテストパイプライン

各ブランチビルドパイプラインで実行する内容

まとめ

はじめに

Visual Studio App Centerとは

1. Visual Studio App Centerの準備をする

アカウントとプロジェクトを作成する

APIトークンを発行する

2. apkファイル・ipaファイルを作成する

3. Visual Studio App Centerへapk・ipaファイルをアップロードする

追記（2021/10/18）

4. Visual Studio App Centerからアプリをダウンロードする

Android上でapkファイルをインストールする

iOS上でipaファイルをインストールする

まとめ

余談

はじめに

Flutterを使ったAndroidアプリでapkファイルを作成する

Android固有の設定

ビルドスクリプトを構築する

build-android-apk.sh

Flutterを使ったiOSアプリでipaファイルを作成する

iOS固有の設定

ビルドスクリプトを構築する

build-ios-ipa.sh

CD環境と統合する

まとめ

2021/7/2 追記

はじめに

CIパイプラインが開発のボトルネックに！？

3つのビルドパイプラインに分割する

1. ブランチビルドパイプライン

2. PR/MRパイプライン

3. デイリーE2Eテストパイプライン

各ブランチビルドパイプラインで実行する内容

まとめ

API トークンを発行する