Using Jenkins and Flagger for Progressive Delivery in Kubernetes

Shipping code straight to production used to feel like a leap of faith. Even with CI/CD pipelines in place, a full rollout can still introduce risk. This is where Jenkins and Flagger come together to make deployments safer, observable, and incremental.

Why Pair Jenkins with Flagger?

Jenkins excels at building, testing, and pushing artifacts. Flagger, on the other hand, specializes in progressive delivery inside Kubernetes. When combined, you get:

• Automated CI pipelines via Jenkins
• Controlled canary releases using Flagger
• Real-time metrics-based promotion or rollback

Instead of blindly deploying, you progressively shift traffic and let metrics decide if the release is healthy.

What Flagger Actually Does

Flagger integrates with service meshes like Istio, Linkerd, or App Mesh. It watches your deployment and gradually shifts traffic while analyzing:

• HTTP success rate
• Latency
• Custom Prometheus metrics

If something goes wrong, it automatically rolls back. No human intervention needed.

Where Jenkins Fits In

Jenkins remains your CI/CD orchestrator. It handles:

• Building Docker images
• Running tests
• Pushing images to registries
• Triggering Kubernetes deployments

The key shift is that Jenkins no longer handles the full rollout. Instead, it hands off control to Flagger after deployment.

A Simple Workflow

Let’s break down a typical flow using Jenkins and Flagger:

1. Developer pushes code
2. Jenkins builds and tests the application
3. Jenkins pushes a new container image
4. Jenkins updates the Kubernetes deployment
5. Flagger detects the new version
6. Flagger starts a canary rollout
7. Metrics determine promotion or rollback

Jenkins Pipeline Example

Here’s a simplified Jenkins pipeline that triggers a deployment:

1pipeline {
2  agent any
3
4  stages {
5    stage('Build') {
6      steps {
7        sh 'docker build -t my-app:${BUILD_NUMBER} .'
8      }
9    }
10
11    stage('Push') {
12      steps {
13        sh 'docker push my-app:${BUILD_NUMBER}'
14      }
15    }
16
17    stage('Deploy') {
18      steps {
19        sh '''
20        kubectl set image deployment/my-app \
21        my-app=my-app:${BUILD_NUMBER}
22        '''
23      }
24    }
25  }
26}

At this point, Jenkins is done. Flagger takes over from here.

Flagger Canary Configuration

Flagger uses a custom resource definition (CRD) to define canary behavior:

1apiVersion: flagger.app/v1beta1
2kind: Canary
3metadata:
4  name: my-app
5spec:
6  targetRef:
7    apiVersion: apps/v1
8    kind: Deployment
9    name: my-app
10  progressDeadlineSeconds: 60
11  service:
12    port: 80
13  analysis:
14    interval: 30s
15    threshold: 5
16    maxWeight: 50
17    stepWeight: 10
18    metrics:
19    - name: request-success-rate
20      thresholdRange:
21        min: 99
22      interval: 1m
23    - name: request-duration
24      thresholdRange:
25        max: 500
26      interval: 1m

This configuration tells Flagger how aggressively to shift traffic and what metrics define success.

Here’s Where Things Get Interesting

Unlike traditional deployments, Flagger doesn’t just “hope” things work. It continuously evaluates live traffic. If error rates spike or latency increases, it halts and rolls back automatically.

This makes your pipeline self-correcting. Jenkins triggers the process, but Flagger ensures reliability.

Common Pitfalls

Teams often run into a few issues when adopting Jenkins and Flagger together:

• No metrics configured: Flagger needs Prometheus or equivalent to function properly
• Too aggressive rollout settings: Large step weights can cause instability
• Ignoring observability: Without dashboards, debugging becomes difficult
• Mixing responsibilities: Jenkins should not try to manage rollout logic

Performance and Reliability Gains

With progressive delivery:

• You reduce blast radius of failures
• Rollback becomes automatic
• User experience improves during deployments
• Confidence in releases increases significantly

When Should You Use This Setup?

Jenkins and Flagger are a strong fit if:

• You already use Jenkins for CI/CD
• You run workloads in Kubernetes
• You want safer deployments without manual approvals
• You have observability tooling like Prometheus

If you’re still doing full rolling updates without metrics-based validation, you’re leaving reliability up to chance.

Final Thoughts

Jenkins and Flagger solve different parts of the delivery pipeline, and that’s exactly why they work well together. Jenkins builds and ships, while Flagger decides how that code reaches users.

Once you adopt this model, deployments stop being risky events and become controlled, measurable processes.