Can we use a staging environment with trunk-based development?
July 1, 2022Push to your staging branch as needed, but don't make it a mandatory step toward production.
Of course, in an ideal world, testing in a staging environment is rarely, if ever needed. But most of us aren’t there yet. So how can we use a testing or staging environment, without that trusty
staging branch you’re so familiar with?
The approach I advocate in my free Lean CD Bootcamp is to just pull the
staging environment out of your workflow. That is, it’s no longer a step toward promotion to your mainline branch (usually called
What this means is that you can still push to your
staging branch, when testing is necessary. But you never promote code from
staging to anywhere else… instead, when you’re done with your feature, you merge it straight from your feature branch into mainline.
On paper, it looks almost the same. And perhaps more important, you don’t need to update your deployment automation scripts. Any push to the
staging branch can still auto-deplo to your Staging environment, with no changes.
With this change in place, the
staging branch becomes a throw-away, temporary sand box. You can force push to it at will (assuming nobody else is using it, anyway).
So let’s walk through a typical scenario.
You’ve recently started a new feature branch, off of
master, made a few changes, and now you want to test it on Staging.
git checkout master git checkout -b my-new-feature # Do some work git add . git commit -m "My awesome new code!" git push -f origin my-new-feature:staging # <--- Force push your changes to staging
Now you, or your QA team, or whomever, does some testing of your code on Staging, and they ask you to make some changes. Meanwhile, one of your colleagues has pushed new changes to
main, which you also want to included. So you rebase your branch on top of master, make your changes, then once again force push everything to staging.
git checkout main git pull # Pull down your colleague's changes git checkout my-new-feature git rebase main # Rebase your changes on top of the new main # Make the changes discovered during testing git add . git commit -m "My awesome new changes" git push -f origin my-new-feature:staging # <-- once again, staging has all of your changes
Notice there’s no ugly mess of merging things into
staging then later into
main, and trying to resolve conflicts multiple times, etc.