Hi everyone! I’m getting started on a new project with Expo and am working out the git branching and deployment strategy. I think I have an idea of how it’ll work, but wanted to run it by the community because there are some details I’m still a bit confused about, mostly around how to think of channels and build profiles. This all is focusing just on mobile. Sorry in advance for a long post, but I’m hoping the context comes through.
In terms of git, my plan is to have a base branch called staging
. Feature branches will come off of this one and be merged back after PR review. At arbitrary points, PRs will be made from staging
to production
, which will result in a batched release to our users. This will be shown in a diagram at the bottom of the post.
The EAS side is where I have some more questions. First, I’d like to implement PR previews. We’ll be using a development client locally. My plan was to have a new update pushed to a channel and branch corresponding to the feature branch in git on PR updates. So for example, if I’m working on a branch called update-nav
and make a PR, a GitHub action would run eas update
to create a channel and branch called update-nav
that people could test.
Once PRs are merged to staging
, my thought is to have multiple updates kick off. One would be to a general “development” environment which has the latest approved changes. This is the kind of build a new dev joining the team would install to be up to speed. Since I have a build profile for development and for the local iOS simulator (development and development-simulator), I thought I might need a channel for each, but both pointing to the staging
branch. A big question of mine is whether or not this would be necessary.
The other thing happening on a merge to staging
would be updating an actual “staging” channel, with a build that can be run on TestFlight/the Google Play internal track. This would be easier for stakeholders to review and would more mimic the real thing.
Finally, I plan on having some process to run EAS update on merges to production
, but that seems more straightforward (hopefully). An overview of the channels and branches I’m thinking are below:
So my question is: does this all make sense? Am I overcomplicating the multiple channels attached to the staging
branch or is that necessary since there will be three different build profiles for the two dev versions and staging?