1---
2title: Deployment patterns
3description: Learn how about different deployment patterns for your project when using EAS Update.
4---
5
6import ImageSpotlight from '~/components/plugins/ImageSpotlight';
7
8Once 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.
9We 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.
10
11Depending 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.
12
13There are three parts to consider when designing a EAS Update deployment process:
14
151. **Creating builds**
16   - (a) We can create builds for production use only.
17   - (b) We can create builds for production use and separate builds for pre-production change testing.
182. **Testing changes**
19   - (a) We can test changes with TestFlight and Play Store Internal Track.
20   - (b) We can test changes with an internal distribution build.
21   - (c) We can test changes with Expo Go or a development app.
223. **Publishing updates**
23   - (a) We can publish updates to a single branch.
24   - (b) We can create update branches that are environment-based, like "production" and "staging".
25   - (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.
26
27We 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.
28
29Another 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.
30
31Below, we've outlined four common patterns on how to deploy a project with Expo and EAS.
32
33## Two-command flow
34
35This 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:
36
37**Creating builds:** (a) Create builds for production use only.
38
39**Testing changes:** (c) Test changes with Expo Go or a development app.
40
41**Publishing updates:** (a) Publish to a single branch.
42
43### Diagram of flow
44
45<ImageSpotlight
46  alt="Two command deployment diagram"
47  src="/static/images/eas-update/deployment-two-command.png"
48  style={{ maxWidth: 1200 }}
49/>
50
51### Explanation of flow
52
531. Develop a project locally and test changes in Expo Go.
542. 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.
553. When we have updates we'd like to deliver, run `eas update --branch production` to deliver updates to our users immediately.
56
57#### Advantages of this flow
58
59- This flow does not require bookkeeping extra version or environment names, which makes it easy to communicate to others.
60- Delivering updates to builds is very fast.
61
62#### Disadvantages of this flow
63
64- 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.
65
66## Branch promotion flow
67
68This flow is great for managing versioned releases. Here are the parts of the deployment process above that make up this flow:
69
70**Creating builds:** (b) Create builds for production and separate builds for testing.
71
72**Testing changes:** (a) Test changes on TestFlight and the Play Store Internal Track and/or (b) Test changes with internal distribution builds.
73
74**Publishing updates:** (c) Create update branches that are version based, like "version-1.0".
75
76### Diagram of flow
77
78<ImageSpotlight
79  alt="Branch deployment diagram"
80  src="/static/images/eas-update/deployment-branch.png"
81  style={{ maxWidth: 1200 }}
82/>
83
84### Explanation of flow
85
861. Develop a project locally and test changes in Expo Go.
872. 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.
883. Set up `expo-github-action` to publish updates when merging commits to branches.
894. Merge changes into a branch named "version-1.0".
905. 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.
916. When ready, use the website or EAS CLI to point the "production" channel at the EAS Update branch "version-1.0".
927. 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".
938. When ready, use the website or EAS CLI to point the "production" channel at the EAS Update branch "version-1.1".
94
95#### Advantages of this flow
96
97- 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.
98- 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.
99  In practice, this makes it so you can push to GitHub, then select the same branch name on Expo to link to builds.
100- 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.
101
102#### Disadvantages of this flow
103
104- 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.
105
106## Persistent staging flow
107
108This 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:
109
110**Creating builds:** (b) Create builds for production and separate builds for testing.
111
112**Testing changes:** (a) Test changes on TestFlight and the Play Store Internal Track and/or (b) Test changes with internal distribution builds.
113
114**Publishing updates:** (b) Create update branches that are environment-based, like "staging" and "production".
115
116### Diagram of flow
117
118<ImageSpotlight
119  alt="Staging deployment diagram"
120  src="/static/images/eas-update/deployment-staging.png"
121  style={{ maxWidth: 1200 }}
122/>
123
124### Explanation of flow
125
1261. Develop a project locally and test changes in Expo Go.
1272. 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.
1283. Set up `expo-github-action` to publish updates when merging commits to branches.
1294. Merge changes into a branch named "staging". The GitHub Action will publish an update and make it available on our test builds.
1305. When ready, merge changes into the "production" branch to publish an update to our production builds.
131
132#### Advantages of this flow
133
134- 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.
135- It's easy to communicate to your team, since deploying updates occurs when merging into GitHub branches named "staging" and "production".
136
137#### Disadvantages of this flow
138
139- 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.
140- 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".
141
142## Platform-specific flow
143
144This 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:
145
146**Creating builds:** (a) Create builds for production only, or (b) create builds for production and separate builds for testing.
147
148**Testing changes:** (a) Test changes on TestFlight and the Play Store Internal Track and/or (b) Test changes with internal distribution builds.
149
150**Publishing updates:** (b) Create update branches that are environment- and platform-based, like "ios-staging", "ios-production", "android-staging", and "android-production".
151
152### Diagram of flow
153
154<ImageSpotlight
155  alt="Platform specific deployment diagram"
156  src="/static/images/eas-update/deployment-platform-specific.png"
157  style={{ maxWidth: 1200 }}
158/>
159
160### Explanation of flow
161
1621. Develop a project locally and test changes in Expo Go.
1632. 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.
1643. Set up `expo-github-action` to publish updates to the required platforms when merging commits to branches.
1654. 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".
166
167#### Advantages of this flow:
168
169- This flow gives you full control of which updates go to your Android and iOS builds. Updates will never apply to both platforms.
170
171#### Disadvantages of this flow:
172
173- You'll have to run two commands instead of one to fix changes on both platforms.
174