Goal

I have a similar goal/question to this one (that’s over 6yrs old now), and I’m just checking to see if there has been any changes in the Git/Azure DevOps world that can assist me.

Background

Our current strategy is that we have:

• dev branch where all developers use during the course of a sprint
  • all development done on short-lived “feature” branches + peer-reviewed by pull requests (PR) into dev when development for a given work item is done
  • CI/CD process on updates to dev automatically build & deploy to DEV environment for initial testing to be done.
• main branch which (should) contain all “approve/tested” changes
  • When all code in dev is in a releasable state, a PR/merge is done into main from dev.
  • Similar CI/CD process updates to main automatically create a build ready for auto/manual deployment to TEST, UAT, PROD environments (depending on build passing each stage).

Problem

The main issue we’re experiencing with this process is when there’s a new change that is blocking the next release (either a change fails testing, or a new UAT release needs to be cut before all new changes have been fully tested), and we are unable to proceed until ALL issues have been resolved (or we risk introducing known faults/unapproved changes).

Things we’ve considered

Most recently, I suggested a redesign of the dev process such that no code could be integrated (e.g. PR’d into dev) until it had passed ALL tests/approval.
Unfortunately, the rest of the dev team highlighted that, while this seems good – in practice this means that all changes are tested isolation, which can end up breaking later when finally integrated/PR’d to codebase, rather than finding out sooner.

Does anyone have any alternative suggestions for a solution (that scales well)?

Many thanks in advance
(+please let me know if any of the above needs clarifying)