EASのbuild/branch/channelの関係性
この辺の関係性
EASのbuild
用語の意味については各ページを参照mrsekut.icon
前提
大まかな概念の流れ
一発目のリリースのためにbuildを作成する
buildするためにはchannelの指定が必要
つまり、全てのbuildにはchannelが紐付いている
また、channelには何かしらのbranchが紐付いている
その後、何か修正して、それをpublishしたいとき
その修正を特定のbranchにpublishすることで、
それに紐付いているchannelに影響を与え
更にそのchannelに紐付いているbuildに影響を与える
従って、ユーザのデバイスでも更新が確認される
2回目以降のNative Layerの更新時は、ちゃんとbranchも更新しておかないとしっかりバグりそうmrsekut.icon
さすがに自動でやってくれるのかな
例えば、staging channelは、staging branchと紐付いている
紐付けるためには、互換性がないといけない
例えば、runtime versionが一致しているなど
これは、build時にrelease channelを指定しておいて、
後に修正を反映したいときに、そのrelease channelに対してpublishすれば反映される、というもの
これに更にbranchという概念が加わったことになる
何が嬉しいか
branchを使うことで、
staging branchで確認したものを、production branchに更新、といった運用ができる
例
①version-1.0branchの内容はすでにproductionに配信済み
https://gyazo.com/0feb7e8cb2bbfdde68f4a3f6e5fe6856 https://docs.expo.dev/eas-update/how-eas-update-works/#matching-updates-and-builds
修正したversion-2.0を確認したいので、stagingと紐付ける
これで、stagingにアクセスできる内部の人のみがversion-2.0を確認できる
(この時点では右下のversion-3.0は存在しない。図が紛らわしい)
②version-2.0の確認が終わったら、これを公開したいのでproductionと紐付ける
https://gyazo.com/1c31bb85cd8f1d059f697eafb4b76141 https://docs.expo.dev/eas-update/how-eas-update-works/#matching-updates-and-builds
これでversion-2.0がproductionに公開された
今はproductionもstagingも同じ内容を見ている
(この時点では右下のversion-3.0は存在しない。図が紛らわしい)
③また新たに修正ができたので、それをversion-3.0としてbranchを作成
それをstagingと結びつけて確認
https://gyazo.com/7855b35ea86f915030d29737d47ee0ce https://docs.expo.dev/eas-update/how-eas-update-works/#matching-updates-and-builds
...
といった運用ができる
git branchのdevelopにmergeされると、GitHub ActionsによりEAS branchのdevelopにpublishする
すると、EAS branchのdevelopに紐付いているEASのchannelの全てのbuildに適用できるようになる 参考