Designing GitOps Pipelines with Helm on OpenShift

A Practical Guide for DevOps & Platform Engineers

Introduction

In the age of Kubernetes-native DevOps, GitOps has emerged as a powerful operational model. It uses Git as a single source of truth for declarative infrastructure and application configurations. Combined with Helm (a powerful package manager for Kubernetes) and OpenShift (an enterprise-ready Kubernetes distribution), GitOps can bring consistency, auditability, and speed to modern DevOps workflows.

In this article, I’ll guide you through designing a GitOps pipeline using Helm on OpenShift , covering real-world implementation strategies, tools, and best practices from my experience managing enterprise CI/CD platforms.

What is GitOps?

GitOps is a methodology where infrastructure and application changes are:

• Defined declaratively (e.g., YAML, Helm)
• Version-controlled in Git
• Automatically applied to clusters using agents/controllers (e.g., ArgoCD or Flux)

With GitOps, you don’t “kubectl apply” manually. Instead, Git changes drive the desired state of the environment.

Why Combine GitOps, Helm, and OpenShift?

ToolRole Git Source of truth for desired cluster/app state Helm Manages complex Kubernetes manifests via charts & templates OpenShift Enterprise Kubernetes platform with robust RBAC, security, and UI ArgoCD/Flux Continuously reconcile Git state with live clusters

Using them together enables:

• Version-controlled deployments
• Template-driven customization
• Multi-environment consistency
• Rollback & auditability

Architecture Overview

Here’s a simplified GitOps architecture with Helm on OpenShift:

Git Repo (Helm Charts + Values.yaml)
        ⬇️
     ArgoCD/Flux
        ⬇️
   OpenShift Cluster
        ⬇️
  Application Deployment

• Helm charts are stored in Git, parameterized via values.yaml.
• ArgoCD watches Git and syncs changes to OpenShift namespaces.
• Changes in Git = changes in the cluster.

Step-by-Step Pipeline Design

1️ Set Up Your Git Repository Structure

Organize your Git repo like this:

gitops/
├── apps/
│ ├── app1/
│ │ ├── Chart.yaml
│ │ ├── templates/
│ │ └── values-dev.yaml
│ │ └── values-prod.yaml
├── base/
│ └── common-resources.yaml
└── argo-project.yaml

• Per-environment values.yaml files help manage custom configs.
• Templatized Helm charts make apps reusable.

2️ Create Helm Charts

Use helm create app1 and define Kubernetes objects inside templates/.

Key best practices:

• Avoid hardcoding — use values.yaml for all configs.
• Use environment-specific overrides.
• Include ingress, configMaps, secrets, and resources.

️3 Install & Configure ArgoCD in OpenShift

Install ArgoCD into your OpenShift cluster:

oc new-project argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

Then:

• Expose ArgoCD via OpenShift route
• Login using admin credentials
• Connect to your Git repository

4️ Define ArgoCD Applications

Use either declarative YAML or ArgoCD UI to define applications:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: app1-dev
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/your-org/gitops
    path: apps/app1
    targetRevision: HEAD
    helm:
      valueFiles:
        - values-dev.yaml
  destination:
    server: https://kubernetes.default.svc
    namespace: dev
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

• Use separate apps for each environment (app1-dev, app1-prod)
• Enable automated sync and self-healing

5️ Automate Sync and Monitoring

• Enable auto-sync so ArgoCD pulls new Git commits
• Enable self-heal so drifted resources get re-applied
• Monitor app health via ArgoCD UI or Prometheus alerts

CI/CD Integration

You can trigger GitOps flows directly from Jenkins or GitHub Actions:

• CI pipeline builds images → pushes to registry
• Then updates a Git tag or Helm values.yaml with new image
• GitOps (ArgoCD) syncs change into OpenShift

This creates a fully automated build → deploy loop, but with Git as the control plane.

Best Practices

1. Use parameterized Helm charts for all apps
2. Separate infrastructure and application layers
3. Restrict manual access to OpenShift — rely on GitOps flow
4. Regularly audit ArgoCD sync logs
5. Add image tags and SHA256 digests in Git for traceability
6. Use secrets management (e.g., Sealed Secrets or Vault)
7. Define reusable base charts for common patterns (e.g., Istio, logging, etc.)

Real-World Example

In a recent engagement, I helped onboard 20+ microservices into a GitOps model using Helm charts on OpenShift. Some lessons learned:

• Centralizing Helm values helps governance
• ArgoCD RBAC + OpenShift RBAC is essential for multitenancy
• Developers can preview PRs using preview environments via ephemeral branches
• Incident rollback was reduced to Git revert + Argo sync

Conclusion

Designing a GitOps pipeline with Helm and OpenShift unifies infrastructure and app delivery under version control. It simplifies audits, improves consistency, and accelerates delivery.

By combining Helm’s templating power with OpenShift’s enterprise-grade Kubernetes and GitOps tools like ArgoCD, platform teams can deliver secure, scalable, and self-healing systems with minimal human intervention.

Let’s Connect

If you’re exploring GitOps, Kubernetes, or Helm adoption in enterprise environments, feel free to connect! I’ve helped large-scale organizations streamline delivery pipelines using these practices.

👉Follow me on LinkedIn | 💬 Reach out for collaboration

Comments

[kazeem mohammed]

Thanks for reading! I’d love to hear your thoughts—please share them in the comments