The process called pull request, one of the most popular forms of peer review that span Dev and Ops. Pull requests are also the mechanism used to deploy code into production through a collective set of practices they call "GitHub Flow"
In these cases, creating approval steps from people who are located further and further away from the work may actually reduce the likelihood of success. As has been proven time and again, the further the distance between the person doing the work (i.e., the change implementer) and the person deciding to do the work (i.e., the change authorizer), the worse the outcome.
High-performing organizations relied more on peer review and less on external approval of changes. The more organizations rely on change approvals, the worse their IT performance in terms of both stability and throughput.
We need to create effective control practices that resemble peer review.
The more loosely coupled our architecture, the less we need to communicate and coordinate with other component teams-when the architecture is truly service-oriented, teams can make changes with a high degree of autonomy, where local changes are unlikely to create global disruptions.
Even in a loosely coupled architecture, there may be a risk of changes interfering with each other. To mitigate these risks, we may use chat rooms to announce changes and proactively find collisions that may exist.
Organizations with more tightly-coupled architectures, deliberately schedule and sequence their changes in order to minimize accidents.
Global infrastructure changes will always have a higher risk associated with them. These changes will always require technical countermeasures, such as redundancy, failover, comprehensive testing, and simulation.