1---
2title: Deployment patterns
3---
4
5import ImageSpotlight from '~/components/plugins/ImageSpotlight';
6
7Once 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.
8We 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.
9
10Depending 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.
11
12There are three parts to consider when designing a EAS Update deployment process:
13
141. **Creating builds**
15   - (a) We can create builds for production use only.
16   - (b) We can create builds for production use and separate builds for pre-production change testing.
172. **Testing changes**
18   - (a) We can test changes with TestFlight and Play Store Internal Track.
19   - (b) We can test changes with an internal distribution build.
20   - (c) We can test changes with Expo Go or a development app.
213. **Publishing updates**
22   - (a) We can publish updates to a single branch.
23   - (b) We can create update branches that are environment-based, like "production" and "staging".
24   - (c) We can create update branches that are version-based, like "version-1.0", which enables us to promote updates from one channel to another.
25
26We 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.
27
28Another 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.
29
30Below, we've outlined four common patterns on how to deploy a project with Expo and EAS.
31
32## Two-command flow
33
34This 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:
35
36**Creating builds:** (a) Create builds for production use only.
37
38**Testing changes:** (c) Test changes with Expo Go or a development app.
39
40**Publishing updates:** (a) Publish to a single branch.
41
42### Diagram of flow
43
44<ImageSpotlight
45  alt="Two command deployment diagram"
46  src="/static/images/eas-update/deployment-two-command.png"
47  style={{ maxWidth: 1200 }}
48/>
49
50### Explanation of flow
51
521. Develop a project locally and test changes in Expo Go.
532. Run `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.
543. When we have updates we'd like to deliver, run `eas update --branch production` to deliver updates to our users immediately.
55
56#### Advantages of this flow
57
58- This flow does not require bookkeeping extra version or environment names, which makes it easy to communicate to others.
59- Delivering updates to builds is very fast.
60
61#### Disadvantages of this flow
62
63- There are no pre-production checks to make sure the code will function as intended. We can test with Expo Go or a development app, but this is less safe than having a dedicated test environment.
64
65## Branch promotion flow
66
67This flow is great for managing versioned releases. Here are the parts of the deployment process above that make up this flow:
68
69**Creating builds:** (b) Create builds for production and separate builds for testing.
70
71**Testing changes:** (a) Test changes on TestFlight and the Play Store Internal Track and/or (b) Test changes with internal distribution builds.
72
73**Publishing updates:** (c) Create update branches that are version based, like "version-1.0".
74
75### Diagram of flow
76
77<ImageSpotlight
78  alt="Branch deployment diagram"
79  src="/static/images/eas-update/deployment-branch.png"
80  style={{ maxWidth: 1200 }}
81/>
82
83### Explanation of flow
84
851. Develop a project locally and test changes in Expo Go.
862. Create builds with channels named "production", which will eventually get reviewed and become available on app stores. Create another set of builds with channels named "staging", which will be used for testing on TestFlight and the Play Store Internal Track.
873. Set up `expo-github-action` to publish updates when merging commits to branches.
884. Merge changes into a branch named "version-1.0".
895. Use the website or EAS CLI to point the "staging" channel at the EAS Update branch "version-1.0". Test the update by opening the apps on TestFlight and the Play Store Internal Track.
906. When ready, use the website or EAS CLI to point the "production" channel at the EAS Update branch "version-1.0".
917. Then, create another GitHub branch named "version-1.1", and merge commits until the new features and fixes are ready. When they are, use the website or EAS CLI to point the "staging" channel at the EAS Update branch "version-1.1".
928. When ready, use the website or EAS CLI to point the "production" channel at the EAS Update branch "version-1.1".
93
94#### Advantages of this flow
95
96- This flow is safer than the other flows. All updates are tested on test builds, and branches are moved between channels, so the exact artifact tested is the one deployed to production builds.
97- This flow creates a direct mapping between GitHub branches and EAS Update branches. It also creates a mapping between GitHub commits and EAS Update updates. If you're keeping track of GitHub branches, you can create EAS Update branches for each GitHub branch and link those branches to a build's channel.
98  In practice, this makes it so you can push to GitHub, then select the same branch name on Expo to link to builds.
99- Previous versions of your deployments are always preserved on GitHub. Once the "version-1.0" branch is deployed, then another version is deployed after it (like "version-1.1"), the "version-1.0" branch is forever preserved, making it easy to checkout a previous version of your project.
100
101#### Disadvantages of this flow
102
103- Bookkeeping of branch names is required for this flow, which will mean communicating with your team which branches are currently pointed at your test builds and your production builds.
104
105## Persistent staging flow
106
107This 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:
108
109**Creating builds:** (b) Create builds for production and separate builds for testing.
110
111**Testing changes:** (a) Test changes on TestFlight and the Play Store Internal Track and/or (b) Test changes with internal distribution builds.
112
113**Publishing updates:** (b) Create update branches that are environment-based, like "staging" and "production".
114
115### Diagram of flow
116
117<ImageSpotlight
118  alt="Staging deployment diagram"
119  src="/static/images/eas-update/deployment-staging.png"
120  style={{ maxWidth: 1200 }}
121/>
122
123### Explanation of flow
124
1251. Develop a project locally and test changes in Expo Go.
1262. Create builds with channels named "production", which will eventually get reviewed and become available on app stores. Create another set of builds with channels named "staging", which will be used for testing on TestFlight and the Play Store Internal Track.
1273. Set up `expo-github-action` to publish updates when merging commits to branches.
1284. Merge changes into a branch named "staging". The GitHub Action will publish an update and make it available on our test builds.
1295. When ready, merge changes into the "production" branch to publish an update to our production builds.
130
131#### Advantages of this flow
132
133- This flow allows you to control the pace of deploying to production independent of the pace of development. This adds an extra chance to test your app and avoids your user having to download a new update every time a PR is landed.
134- It's easy to communicate to your team, since deploying updates occurs when merging into GitHub branches named "staging" and "production".
135
136#### Disadvantages of this flow
137
138- Checking out previous versions of your app is slightly more complex, since we'd need to check out an old commit instead of an old branch.
139- When merging to "production", the update would be re-built and re-published instead of moved from the builds with channel "staging" to the builds with channel "production".
140
141## Platform-specific flow
142
143This 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:
144
145**Creating builds:** (a) Create builds for production only, or (b) create builds for production and separate builds for testing.
146
147**Testing changes:** (a) Test changes on TestFlight and the Play Store Internal Track and/or (b) Test changes with internal distribution builds.
148
149**Publishing updates:** (b) Create update branches that are environment- and platform-based, like "ios-staging", "ios-production", "android-staging", and "android-production".
150
151### Diagram of flow
152
153<ImageSpotlight
154  alt="Platform specific deployment diagram"
155  src="/static/images/eas-update/deployment-platform-specific.png"
156  style={{ maxWidth: 1200 }}
157/>
158
159### Explanation of flow
160
1611. Develop a project locally and test changes in Expo Go.
1622. Create builds with channels named like "ios-staging", "ios-production", "android-staging", and "android-production". Then put the "ios-staging" build on TestFlight and submit the "ios-production" build to the public App Store. Likewise, put the "android-staging" build on the Play Store Internal Track, and submit the "android-production" build to the public Play Store.
1633. Set up `expo-github-action` to publish updates to the required platforms when merging commits to branches.
1644. Then, merge changes for the iOS app into the branch "ios-staging", then when ready merge changes into the "ios-production" branch. Likewise, merge changes for the Android app into the branch "android-staging" and when ready, into the branch named "android-production".
165
166#### Advantages of this flow:
167
168- This flow gives you full control of which updates go to your Android and iOS builds. Updates will never apply to both platforms.
169
170#### Disadvantages of this flow:
171
172- You'll have to run two commands instead of one to fix changes on both platforms.
173