Publishing a specific update to the production channel

Expo Application Services (EAS)
1

Hi

We’re in the process of migrating from “classic” publishing to using EAS Update.

What we used to do was to get our CI to publish our latest candidate code to the “staging” release-channel and then when we were happy with it, point our “default” release-channel (which was in fact production) at the exact same published code. We did it with the command

publish:set --release-channel default --publish-id xxxxxx

The great thing about this is that we knew we were publishing exactly the same code, and because we published a specific publish-id, if we then published new updates to staging, it wouldn’t affect production.

I’m trying to recreate the same thing again with EAS Update. This is where I’ve got to:

  1. When we merge into our “develop” branch, we execute
yarn eas update --branch develop --message "${GIT_COMMIT_MSG}"
  1. We promote this by creating a release/yyyy branch which Jenkins automatically builds and then execute the following two commands:
yarn eas update --branch "${GIT_BRANCH}" --message "${GIT_COMMIT_MSG}"
yarn eas channel:edit staging --branch "${GIT_BRANCH}"

i.e., we create a new branch matching the git release branch

  1. When we want to release to production we point the production channel at the branch above.
yarn eas channel:edit production --branch "${GIT_BRANCH}"

This should work, BUT, if we then create a new update in that branch (e.g. because we found a bug and we want to try out a fix in staging), the new update will be published to staging and production! Because the whole branch has been associated with both channels, not just the individual update.

Have I understood right? Any suggestions on how else to achieve what we want?

Thanks!!

2

I think the “Branch Promotion Flow” we describe here is closest to what you’re trying to achieve. The key is that you would never again publish to that branch once it’s promoted to production. So, you might name these branches based on a version number or something else that would always change when testing new code potentially en-route to test and prod.

There’s some other workflows described in that doc which may be helpful, as well.

3

Thanks @keith-kurak. Unfortunately I can’t access the “Branch Promotion Flow” document you refer to. I’m guessing though that it matches what we’re planning to do. We create release branches with names like release-1.47.6 which match the version in package.json. So it’s unlikely that we’ll make a commit to the branch once it’s been deployed to production, but it’s not impossible.

4

apologies! I must’ve had the wrong thing in my clipboard. The link is updated now.