Advice on deployment strategy with dev, staging, and production environments

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?

I also asked about this on the Discord server and think I got a good answer. Someone mentioned to me that I could use one channel with multiple build profiles, so it might make sense to do something like this instead for the channels and branches:

That way, I can share a staging channel that’s built for Testflight/Google Play internal testing as well as for a common “development” environment.

Re: git branching:

One downside to not having persistent git branches for releases (branches called release-1.0, release-2.0, … cut from the development branch) is reduced ability for hotfixing or to browse/checkout the release branch to repro bugs only happening in release.

That being said, there are a ton of options/opinions/methods for branching for developing/releasing software, and no one method is necessarily strictly more sound than another. Really just depends on things like team size, release complexity, dev flows, PR flows (rebase vs merge), QA, dogfooding, etc.

2 Likes