Technically I don’t use TBD. That would involve commiting directly to the main branch. However I do work with very small PRs. If it makes sense to deploy a small slice then it gets a PR and is merged.
Typically the way to make this safe is to use feature flags, so that production can behave differently to staging. If you are downstream of other changes you can use real data as the switch. Effectively you are live with a feature that won’t be available until someone else relases their part.
For example if there is a new type of product that will be sold by another team you can use the existence of the purchased product as the feature flag. This means that there are no coordination dances with the upstream team (other than don’t release until we have some minimal version ready).
Working this way only works in environments where you can deploy to production many times per day. Heavily regulated environments will limit this to staging.
One of the downsides of working this way is that you may have two or three parallel flows active at one time. You need to aggressivly cull the explicit feature flags or the combantorial number of test paths will explode.
Its also important to name feature flags in the positive and for them to be on the behaviour enabled not the customer or the project. I have seen crazy complexity when you want to give part of customer A’s feature to customer B.
Developer Rants 