Are you able to test a partial or completed feature before you merge it?
In other words, do you have some way to run your work-in-progress from a feature branch?
This is a huge advantage for a number of reasons. Perhaps most obvious, it reduces cycle time, and lets you work in smaller batches. It’s also a great way to show incomplete or proof-of-concept work to stakeholders, or even customers.
I’ve worked with many companies that don’t. Many have something they call “staging”, which is usually where code goes after being merged, but before being made generally available to customers. There are historical reasons for such an arrangement, but it has limited to no relevance in a modern software delivery.
The gold standard for a prereview environment would be one that’s created on the fly for each pull request. If you have 8 devs, each with an open PR, that means you have 8 running prereview environments. This approach requires a bit of up-front effort, and isn’t always easy for certain legacy applications. But it’s practically always worth the effort, because of the surprising productivity boost it provides.
Another option is to just replicate (or repurpose) your “staging” environment as a “prereview” environment, and push to it willy nilly.
If you need to test something you’re working on, just force-push it to your “prereview” branch. Maybe announce your intention on Slack first, in case a colleague is already using the prereview environment.
If you don’t have a preview environment of some kind, what’s standing in your way? Send me an email and let me know!
Or if you haven’t already, take my free email Lean CD Bootcamp to help you get there sooner.
If you enjoyed this message, subscribe to The Daily Commit to get future messages to your inbox.
Top comments (1)
you can run a batch job, that automatically deletes old temporary environments, powerful breakup spells