11-8 · Chapter 11 · 6 min read

When Your Pipeline Decides Who Approves a Deployment

Imagine this: a developer fixes a typo in a documentation page. The change is one line, no logic affected, no database touched. But the deployment process

When Your Pipeline Decides Who Approves a Deployment

Imagine this: a developer fixes a typo in a documentation page. The change is one line, no logic affected, no database touched. But the deployment process still requires two approvals, a 30-minute wait in staging, and a sign-off from the engineering manager. The fix that should take five minutes to reach users ends up taking half a day.

Now imagine the opposite: a developer changes a database migration script that could lock a production table. The same pipeline treats it exactly the same way as the typo fix. No extra review, no additional checks. The change sails through, and the team only discovers the problem when queries start timing out.

Both scenarios are broken, but for opposite reasons. The first one slows down safe changes. The second one lets dangerous changes slip through. The problem is that most deployment pipelines apply the same rules to every change, regardless of what actually changed.

Why One-Size-Fits-All Approval Doesn't Work

Most teams start with a simple approval model: every deployment needs a review. That works when the team is small and every change is significant. But as the codebase grows, the model breaks down. A CSS tweak and a payment module refactor both require the same sign-off. Developers start gaming the system, batching changes together to reduce the number of deployments, or worse, skipping reviews entirely because the process feels like bureaucracy.

The real issue is that risk is not uniform. A change to a README file carries almost zero operational risk. A change to a database migration or an authentication module carries significant risk. Treating them the same means you are either too strict for safe changes or too loose for risky ones.

How a Pipeline Can Assess Risk Automatically

Instead of relying on humans to judge every change, you can teach your pipeline to assess risk based on what files were modified. This is called risk scoring, and it works by defining rules that assign points to changes based on their scope.

A simple set of rules might look like this:

Here is how that logic translates into a GitLab CI pipeline configuration:

stages:
  - test
  - deploy

deploy:
  stage: deploy
  script:
    - echo "Deploying to production..."
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
      changes:
        - "db/**/*"
        - "config/**/*"
      when: manual
      allow_failure: false
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
      changes:
        - "docs/**/*"
        - "README.md"
      when: on_success
    - when: on_success

Changes to files in docs/ or README.md: 0 points
Changes to configuration files (.env, config/): 3 points
Changes to business logic in src/: 7 points
Changes to payment or authentication modules: 20 points
Changes to database migration files: 25 points

The pipeline scans the pull request or commit, checks every changed file against these rules, and sums up the total score. That score then determines what happens next.

Mapping Risk Scores to Deployment Policies

Once the pipeline has a risk score, it can apply different policies based on the result. A typical setup might have three tiers:

The following flowchart illustrates how the pipeline maps risk scores to deployment policies:

flowchart TD A[Change Submitted] --> B{Scan Changed Files} B --> C[Assign Risk Score] C --> D{Score <= 5?} D -->|Yes| E[Low Risk] E --> F[Auto-Approve] F --> G[Deploy to Production] D -->|No| H{Score 6-15?} H -->|Yes| I[Medium Risk] I --> J[Require One Peer Approval] J --> G H -->|No| K[High Risk] K --> L[Require Two Approvals] L --> M[Deploy to Staging] M --> N[Run Smoke Tests & Monitor] N --> O{Checks Pass?} O -->|Yes| G O -->|No| P[Block Deployment]

Low risk (score 0-5): The change can go straight to production without any manual approval. The pipeline runs automated tests, and if they pass, the deployment proceeds. This covers documentation fixes, minor config changes, or refactors that don't touch critical paths.

Medium risk (score 6-15): The change needs one approval from a peer or senior engineer. The pipeline pauses after tests pass and waits for a manual sign-off before continuing to production.

High risk (score 16+): The change needs two approvals and must spend at least one hour in staging with monitoring checks passing. The pipeline deploys to staging first, runs smoke tests, checks error rates and latency, and only then allows the final promotion to production.

These thresholds are not fixed. Different environments can have different rules. In a development environment, you might treat everything as low risk because there are no real users. In staging, you might raise the thresholds slightly. In production, you apply the strictest rules.

The Real Benefit Is Consistency, Not Perfect Accuracy

Risk scoring will never be perfectly accurate. A single-line change in a utility function could break something unexpected if that function is called in many places. A large refactor that touches many files might actually be safe if it only renames variables.

But perfect accuracy is not the goal. The goal is to replace ad-hoc human judgment with a consistent, transparent process. Without risk scoring, every deployment starts a debate: "Does this need approval? Who should review it? Is this risky enough to warrant staging time?" Those debates waste time and create inconsistency. One week a small change gets waved through, the next week the same type of change gets blocked.

With risk scoring, the rules are written down and applied automatically. The team can argue about the rules once, when they set them up, instead of arguing about every single deployment. And because the rules are transparent, the team can review and adjust them over time as they learn what kinds of changes actually cause problems.

How This Changes Team Behavior

Risk-based deployment control does more than just automate approvals. It changes how developers think about code structure. When the team knows that any change to db/migrations/ automatically triggers high-risk policy, they become more careful about what goes into that folder. They might separate database schema changes from data migration scripts, so that a simple data backfill doesn't trigger the same scrutiny as a schema alteration.

It also encourages better modularization. If a team notices that changes to a particular module always score high risk, they might refactor that module to isolate the truly sensitive parts from the routine updates. Over time, the codebase becomes more consciously structured around risk boundaries.

Practical Checklist for Setting Up Risk Scoring

If you want to implement this approach, here is a starting checklist:

Identify which folders and file patterns represent different risk levels in your codebase
Define a scoring system with clear point values for each pattern
Set thresholds for low, medium, and high risk in each environment
Define the deployment policy for each risk level (approvals needed, staging time, monitoring checks)
Implement the risk scoring logic in your CI/CD pipeline configuration
Run the scoring on every pull request and log the results for visibility
Review the scoring rules after one month and adjust based on what you learn

The Pipeline Becomes a Decision Maker

When you add risk-based deployment control, your pipeline stops being just a tool that runs commands. It becomes a decision-making system that evaluates changes, applies rules, and determines the appropriate path to production. The pipeline does not replace human judgment entirely, but it reserves human attention for the changes that actually need it.

This is not about removing control. It is about applying the right level of control to the right change. Small, safe changes move fast. Large, risky changes get the scrutiny they deserve. And the team stops wasting energy debating what should be obvious.