Flexible Governance: Solving the "All or Nothing" Problem in Pipeline Templates

As a platform engineer, your goal is to create reliable "golden paths" that make it easy for development teams to do the right thing. Harness Templates are a cornerstone of this effort, allowing you to codify best practices for building and deploying software.

But this model has a classic failure point. What happens when a team’s needs diverge, even slightly, from your standardized template?

It’s a depressingly common story. A team needs to use a specific security scanner or a niche testing tool not included in your golden path. Faced with a rigid template, they have one option: detach. They copy the pipeline YAML, make their changes, and move on.

While this solves their immediate need, it quietly dismantles your governance strategy. The moment they detach, they stop receiving critical updates you make to the central template. The result is pipeline sprawl - a collection of slightly different pipelines that are difficult to manage, secure, and improve over time. Your golden path becomes a dead end. 

We see the end result of this over and over again. Companies come to us after years of this and they have hundreds, if not thousands of pipeline configurations and its completely unmanageable. After moving to Harness Continuous Delivery and adopting proper templating, they reduce their management overhead dramatically - Ancestry.com reported an 80-to-1 improvement.

Templates are great, but will one point of variance derail adoption? It shouldn’t.

A Point of Compromise: The insert Block

This "all or nothing" scenario forces a false choice between standardization and developer autonomy. The solution is to find a point of compromise. In Harness, this is the insert block.

An insert block is a designated location within a template where a consumer can inject their own steps or stages. It allows you to keep the 90% of the template that is truly standard locked down, while providing controlled flexibility for the 10% that requires variance.

You define the core process, and teams fill in the blanks where it makes sense. We aren’t weakening standards; we are making them practical enough to be adopted universally.

A Practical Example: Mandating Scans Without Mandating Tools

Let’s apply this to a real-world scenario. Your platform policy requires a security scan, but different teams use different tools.

1. Define the Template: You build your pipeline template with all the standard stages for build, test, and deployment. You add an insert block at the appropriate point, which acts as a placeholder.
2. Apply Governance: You use the Harness Policy Engine, powered by OPA, to apply a policy to that insert block. The policy can state that any steps injected must be of an approved type, such as a security scan. You can define the list of approved steps (e.g., Snyk, SonarQube, etc.).
3. Consume the Template: A development team consumes your template. When they reach the insert block, they are free to add a Snyk step. The Harness platform validates this against the OPA policy. If they were to add a step that is not an approved security scanner, the policy would fail, and they wouldn't be able to save the pipeline.

‍

The outcome is efficient. Your governance objective, ensuring a security scan always runs, is met. The development team retains autonomy over its choice of tooling. Most importantly, they remain linked to the template, automatically inheriting all future improvements you make.

This model works for any point of known variance in your software delivery lifecycle:

• Quality Gates: Mandate that a linter runs, but allow teams to use the appropriate one for their language (ESLint, RuboCop, etc.).
• Artifact Analysis: Enforce a standard artifact build process but allow for specialized post-build analysis or testing.
• Custom Verification: Provide a standard deployment strategy but allow teams to inject their own specific post-deployment health checks.

A Note on Prudent Use

This flexibility is a powerful tool, but it should be used with intention. Full standardization is still the most efficient model if you can achieve it. The goal isn't to create countless variations.

The insert block is a strategic solution for managing known, high-variance points in your delivery process. It’s for those specific scenarios where being too rigid causes more problems than it solves. It’s a pragmatic compromise to prevent fragmentation. 

From Brittle to Flexible

Ultimately, platform teams succeed when their tools are willingly adopted. By offering controlled points of flexibility, you eliminate the primary reason teams abandon your golden paths. You can build templates that are both robust and practical, achieving a state of flexible governance that actually works.

If you’re tired of watching your templates fragment, it’s time to explore a more flexible approach.

You can learn more about configuring Insert Blocks in the Harness documentation here.

‍