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
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?