The first thing to do is have very thorough automated offline regression tests. Make passing those tests a minimum requirement for what you officially use.

Second, you need a dead simple way to fall back to the previous working version, for problems that your automated tests don’t catch.

For example, my Linux kernel was custom patched for a while. I would patch and compile my kernel on the same computer I intended to use it on, which meant I could lose my development environment if I created a faulty kernel. So I made sure to always keep a known good kernel in my GRUB menu, so if I made a mistake, I was back to a good development environment with a simple reboot.

Coordinating that with a team is tricky, but I suppose it’s mostly a matter of allowing anyone to initiate a fallback and communicate the reasons. In version control, one way to designate that would be with something like a last_known_good branch, somewhere between develop and master in your workflow. Nothing gets pushed there until you have successfully dogfooded a build.

If this tool is being used to produce production-quality software (especially if it is being used recursively, i.e. to develop itself), I would increase your up-front testing efforts, and wait on dogfooding until the release is stable enough that you are fairly confident you won’t be breaking production code by using it.

If you have to wait for the master version to have that level of confidence, then so be it.

Git is also such tool and obviously also does dogfooding. But it does it to different extent in different environments. The public servers are only running release while developers usually work with either next (that’s git project’s name for “develop”) or pu (even more develop than develop). Any developer that is blocked by some problem can go back to next or master or last release whenever they are blocked by something and the main repository is not affected, so problems can be cleaned by referring to it.

The branching model is similar to the above with slightly different names. master is what big releases are done from, maint is release branch for next point release, next is similar to develop with slight difference that features may be merged to master separately after being in next already instead of whole next being merged.

There is an extra branch, pu. This is created by merging all feature branches that are considered for integration together to next (the branch is discarded and recreated each time). IIRC it is only published if it passes the test suite. Last I looked Junio, the maintainer, was running the scripts to build it regularly by hand, but such scripts could be run by continuous integration nightly and I believe Gerrit even creates it automatically.

So that kind of is the answer. You dogfood the most development version you have in development environments, but use previous release for building releases.

Based on the accepted answer, I’m going to expand on the branching workflow to maintain branches similar to the following:

• master: merges with release-* upon closure
• dogfood: branches from master; includes fixes identified while dogfooding; merges from develop when the software is deemed “stable” for internal use; the head of this branch can be moved back in time if needed
• develop: branches from master; includes ongoing changes, bugfixes, and merges from dogfood and feature-* branches
• feature-*: branches from develop; includes changes for a particular new feature
• release-*: branches from dogfood when the software is deemded “stable” for external use; includes documentation updates and minor bugfixes prior to merging with master