Expoのdeployのパターン
Expoのdeployのパターン
選択肢が色々ある
各フェーズごとに色々選択肢がある
buildの作成
(a) production用のみのbuildを作成
(b) production用とtest用のbuildを作成
変更のテスト
本番環境を見る
プラットフォームの審査を待つ必要がある
ユーザに配信されるのものに最も近い
修正のたびにbuildが必要
基本的に本番環境を見る
審査の時間がかからない
修正のたびにbuildが必要
基本的に開発環境を見る
審査の時間がかからない
buildを一発しておけば、その後はコードの修正をリアルタイムに反映できる
アップデートの公開
(c) 「version-1.0」のようにversionを付したEAS branchを使用してpublishする 従来
毎回別のchannelにpublishしていた
EAS時代において、これのデメリットはなんだっけ？
↓に移行しても良いが、懸念点は
rolloutできるかどうか、
runtimeとのversionが異なるときにおかしくならないか
a → c → a
OTAで配信しつつ、storeにも申請
testは開発環境で行う
全ての選択肢で、最速になるものを選択してる感じ
Persistent staging flow ref b → a/b → b
branch名に、versionを含めないということ
初回は2個のbuildを作る
1つはproduction branch。これは配信する
1つはstaging branch。これはTestflightで使う
以降は、
テスト時はstaging github branchにmergeする
GitHub Actionsにより、TestFlight環境が更新される
テストできたら、production github branchにmergeする
GitHub Actionsにより、本番環境が更新される
懸念
rolloutできる？
Platform-specific flow ref a/b → a/b → b
Andoird/iOSを別々に更新する運用の場合に有用
Branch promotion flow ref b → a/b → c
安全なフロー
また読もうmrsekut.icon
関連
参考