GitOps Full Loop: Deep Dive

Overview

GitOps is an operational framework that uses Git as the single source of truth for infrastructure and application configuration. This document covers the architecture patterns, tool integration, and production considerations for a Tekton + ArgoCD pipeline.

The Two-Repo Model

Source Repository

Contains application code: source files, tests, Containerfile. Tekton watches this repo for changes. When a developer pushes, Tekton runs the CI pipeline: lint, test, build image, push image.

Config Repository

Contains Kubernetes manifests: Deployments, Services, ConfigMaps. ArgoCD watches this repo. When the manifests change (typically because Tekton updated an image tag), ArgoCD syncs the cluster to match.

Why Two Repos?

Separation of concerns: Application developers own the source repo, platform teams own the config repo
Audit trail: Every deployment is a Git commit with author, timestamp, and diff
Rollback: Reverting a deployment is just git revert on the config repo
Security: CI credentials (for building) stay separate from CD credentials (for deploying)

How Tekton and ArgoCD Connect

The handoff point is simple: Tekton’s last pipeline task updates the image tag in the config repo and pushes the commit. ArgoCD detects the new commit and syncs.

Tekton Pipeline
  Task 1: Clone source, run tests
  Task 2: Build image, push to registry
  Task 3: Clone config repo, update image tag, push  <-- handoff
                                                            |
ArgoCD                                                      v
  Detects new commit in config repo
  Compares desired state (Git) vs live state (cluster)
  Applies the diff (kubectl apply)

There is no direct API call between Tekton and ArgoCD. Git is the interface.

ArgoCD Sync Policies

Manual Sync

ArgoCD detects drift but waits for a human to click “Sync”. Good for production environments where you want manual approval gates.

Automated Sync

ArgoCD syncs automatically when it detects drift. This demo uses automated sync for simplicity.

Options:

prune: Delete resources that exist in the cluster but not in Git
selfHeal: Revert manual changes made directly to the cluster

Sync Waves

For ordered deployments (database before app), use sync wave annotations:

metadata:
  annotations:
    argocd.argoproj.io/sync-wave: "1"  # lower numbers sync first

Tekton Triggers

In production, you would add Tekton Triggers to automatically start pipelines on Git events:

EventListener: Receives webhooks from GitHub/GitLab
TriggerBinding: Extracts parameters from the webhook payload (repo URL, commit SHA)
TriggerTemplate: Creates a PipelineRun with those parameters

Image Promotion Strategy

A common pattern for multiple environments:

Source Push -> Build -> dev (auto-deploy)
                    -> staging (auto-deploy after dev passes)
                    -> production (manual approval)

Each environment has its own directory in the config repo with its own image tag. Tekton updates dev first, and promotion to staging/production happens through additional pipeline tasks or manual commits.

Production Considerations

Secrets Management

Use Sealed Secrets or External Secrets Operator to store secrets in Git safely
Never commit plain-text secrets to the config repo

Multi-Cluster

ArgoCD can manage multiple clusters from a single control plane. Define each cluster as a destination in the Application spec.

Notifications

Configure ArgoCD notifications to send Slack/email alerts on sync success, failure, or health degradation.

RBAC

Both Tekton and ArgoCD support fine-grained RBAC. Limit who can create PipelineRuns and who can sync Applications.