How We Built a GitOps Deployment Pipeline with ArgoCD, Jenkins, Helm & Harbor

Overview

At Syntektra Solutions, we believe deployment should be invisible — a natural outcome of pushing good code. To achieve this, we designed and implemented a fully automated GitOps-based deployment pipeline using industry-leading tools: Jenkins, Docker, Helm OCI, Harbor, and ArgoCD.

This post walks through our architecture, the decisions we made, and how everything fits together to deliver continuous deployment with confidence.

The Problem We Were Solving

Before this pipeline, deployments were manual, error-prone, and stressful. Developers had to SSH into servers, pull images, restart services, and pray nothing broke. There was no audit trail, no rollback strategy, and no consistency between environments.

We needed a system where a Git commit is the single source of truth — and the infrastructure automatically converges to match it.

The Architecture

1. Jenkins — Build & Package

Every commit to the main branch triggers a Jenkins pipeline. Jenkins is responsible for:

• Pulling the latest source code
• Running tests and quality checks
• Building a Docker image with a versioned tag (e.g., v1.0.42-abc1234)
• Pushing the image to our Harbor private registry
• Building the Helm chart as an OCI artifact and pushing it to Harbor

Using OCI for Helm charts means our charts are versioned, immutable, and stored alongside our Docker images in the same registry — clean and consistent.

2. Harbor — Private Registry

Harbor serves as our central artifact store. It holds:

• Docker images for all our services
• Helm OCI charts for each application

Harbor gives us vulnerability scanning, role-based access control, and replication policies — critical for a production-grade setup. Every image pushed by Jenkins is immediately scanned before ArgoCD is allowed to deploy it.

3. ArgoCD — GitOps Controller

We deployed ArgoCD on a dedicated server. ArgoCD watches our Git repository for changes to the Helm values files. When a change is detected — such as a new image tag committed by Jenkins — ArgoCD automatically syncs the application state on the target server.

Our ArgoCD Application manifest includes:

• Source: Git repo with Helm values
• Destination: Target Kubernetes/server namespace
• Sync Policy: Automated with self-healing enabled
• Helm chart source: OCI registry on Harbor

4. The GitOps Loop

Here is the full flow on every commit:

1. Developer pushes code to Git
2. Jenkins detects the push via webhook
3. Jenkins builds Docker image → pushes to Harbor
4. Jenkins builds Helm OCI chart → pushes to Harbor
5. Jenkins updates the image tag in the Git values file and commits it
6. ArgoCD detects the values file change in Git
7. ArgoCD pulls the new Helm chart from Harbor OCI registry
8. ArgoCD deploys the updated application to the target server
9. Target server is now running the latest version — automatically

Why This Stack?

• Jenkins — battle-tested, highly customizable CI engine with rich plugin ecosystem
• Harbor — enterprise-grade private registry with security scanning built in
• Helm OCI — treats charts as first-class artifacts, versioned and immutable
• ArgoCD — declarative GitOps, every deployment is traceable to a Git commit

Benefits We Gained

• ✅ Zero-touch deployments — no manual SSH, no human error
• ✅ Full audit trail — every deployment is a Git commit
• ✅ Instant rollback — revert a Git commit, ArgoCD rolls back automatically
• ✅ Environment consistency — dev, staging, and prod all use the same Helm chart
• ✅ Self-healing — if someone manually changes the server state, ArgoCD corrects it

Lessons Learned

Setting up OCI-based Helm charts with Harbor required careful attention to authentication — Harbor uses a different credential flow for OCI vs traditional Helm repos. We also learned to keep the values files lean and let the chart handle defaults, making environment-specific overrides minimal and readable.

ArgoCD's self-healing feature is powerful but needs thoughtful configuration — you don't want it fighting with legitimate manual interventions during an incident.

Conclusion

This pipeline transformed how our team ships software. What used to take 30 minutes of careful manual work now happens in under 5 minutes, automatically, on every commit. The confidence it gives the team is invaluable.

If you are looking to implement a similar GitOps pipeline for your infrastructure, reach out to us — we would love to help.