Versioned templates that teams pin and upgrade on their own schedule is the part I would underline. Most standardisation efforts I have seen fail because the shared pipeline changes under people, and after one bad week teams fork it and never come back.
Putting the policy checks inside the template is also right. A gate that depends on a reviewer remembering to look is not really a gate.
At Ascendra Ventures we did a longer version of this for an equipment manufacturing group with three business units on outdated Jenkins and manual deployments. Over fifteen months, middleware moved to Azure DevOps pipelines as code, Java work went onto one workflow with code reviews, unit tests and SonarQube quality gates, and releases moved to Helm charts on Kubernetes, so a rollback became a chart version. The case study title says what the goal was: retire the legacy pipeline, not run a second one beside it.
How does the guild model handle a team that stays pinned to an old template version for months?
Ascendra Ventures
Versioned templates that teams pin and upgrade on their own schedule is the part I would underline. Most standardisation efforts I have seen fail because the shared pipeline changes under people, and after one bad week teams fork it and never come back.
Putting the policy checks inside the template is also right. A gate that depends on a reviewer remembering to look is not really a gate.
At Ascendra Ventures we did a longer version of this for an equipment manufacturing group with three business units on outdated Jenkins and manual deployments. Over fifteen months, middleware moved to Azure DevOps pipelines as code, Java work went onto one workflow with code reviews, unit tests and SonarQube quality gates, and releases moved to Helm charts on Kubernetes, so a rollback became a chart version. The case study title says what the goal was: retire the legacy pipeline, not run a second one beside it.
How does the guild model handle a team that stays pinned to an old template version for months?