Learn how about different deployment patterns for your project when using EAS Update.
Once we've created features and fixed bugs in our app, we want to deliver those features and bug fixes out to our users as quickly and safely as we can. Often "safe" and "fast" are opposing forces when delivering code to our users. We could push our code directly to production, which would be fast yet less safe since we never tested our code. On the other hand, we could make test builds, share them with a QA team, and release periodically, which would be safer but slower to deliver changes to our users.
Depending on your project, you'll have some tolerance for how "fast" and how "safe" you'll need to be when delivering updates to your users.
There are three parts to consider when designing a EAS Update deployment process:
We can mix and match the parts above to create a process that is the right balance of cadence and safety for our team and users.
Another trade-off to consider is the amount of bookkeeping of versions/names/environments we'll have to do throughout the process. The less bookkeeping we have to do will make it easier to follow a consistent process. It'll also make it easier to communicate with our colleagues. If we need fine-grained control, bookkeeping will be required to get the exact process we want.
Below, we've outlined four common patterns on how to deploy a project with Expo and EAS.
This flow is the simplest and fastest flow, with the fewest amount of safety checks. It's great for trying out Expo and for smaller projects. Here are the parts of the deployment process above that make up this flow:
Creating builds: (a) Create builds for production use only.
Testing changes: (c) Test changes with Expo Go or a development app.
Publishing updates: (a) Publish to a single branch.
eas build
to create builds, then submit them to app stores. These builds are for public use, and should be submitted/reviewed, and released on the app stores.eas update --branch production
to deliver updates to our users immediately.This flow is great for managing versioned releases. Here are the parts of the deployment process above that make up this flow:
Creating builds: (b) Create builds for production and separate builds for testing.
Testing changes: (a) Test changes on TestFlight and the Play Store Internal Track and/or (b) Test changes with internal distribution builds.
Publishing updates: (c) Create update branches that are version based, like "version-1.0".
expo-github-action
to publish updates when merging commits to branches.This flow is like an un-versioned variant of the "branch promotion flow". We do not track release versions with branches. Instead, we'll have persistent "staging" and "production" branches that we can merge into forever. Here are the parts of the deployment process above that make up this flow:
Creating builds: (b) Create builds for production and separate builds for testing.
Testing changes: (a) Test changes on TestFlight and the Play Store Internal Track and/or (b) Test changes with internal distribution builds.
Publishing updates: (b) Create update branches that are environment-based, like "staging" and "production".
expo-github-action
to publish updates when merging commits to branches.This flow is for projects that need to build and update their Android and iOS apps separately all the time. It will result in separate commands for delivering updates to the Android and iOS apps. Here are the parts of the deployment process above that make up this flow:
Creating builds: (a) Create builds for production only, or (b) create builds for production and separate builds for testing.
Testing changes: (a) Test changes on TestFlight and the Play Store Internal Track and/or (b) Test changes with internal distribution builds.
Publishing updates: (b) Create update branches that are environment- and platform-based, like "ios-staging", "ios-production", "android-staging", and "android-production".
expo-github-action
to publish updates to the required platforms when merging commits to branches.