We've covered Tekton for CI and Argo CD for CD separately. Now let's bring them together. This final article shows how Tekton and Argo CD complement each other to form a complete, end-to-end GitOps pipeline.
1. The Core Idea: Split CI and CD at the Git Boundary
The key architectural insight is this: Tekton and Argo CD each own a clearly defined half of the pipeline, with a Git repository as the handoff point between them.
┌─────────────────────────────┐ ┌──────────────────────────────┐
│ CI (Tekton) │ │ CD (Argo CD) │
│ │ │ │
│ Code Repo │ │ Infra Repo │
│ ↓ │ │ ↓ │
│ Image Build (Tekton) │ ──► │ Argo CD watches Git │
│ ↓ │ │ ↓ │
│ Git Update (push new tag) │ │ Sync to Cluster │
│ ↓ │ │ ↓ │
│ Image Registry │ │ Application Running │
└─────────────────────────────┘ └──────────────────────────────┘
A typical pipeline covers these stages:
| Stage | Tool | Responsibility |
|---|---|---|
clone |
Tekton | Pull source code from Code Repository |
test |
Tekton | Run unit tests and code quality checks |
build |
Tekton | Compile application (e.g. Maven, Go build) |
docker |
Tekton | Build container image and push to Image Registry |
git-update |
Tekton | Update image tag in Infra Repository manifest |
deploy |
Argo CD | Detect Git change, sync to target cluster |
rollback |
Argo CD | Roll back to previous Git revision on failure |
The last two stages — deploy and rollback — belong to the CD domain. Only these need to be handled by Argo CD. Tekton's job ends the moment it pushes the updated manifest to Git.
2. The 8-Step GitOps Workflow
Here is the complete end-to-end flow when a developer pushes new code:
┌─────────────────────────────────────────────────────────────────┐
│ Tekton + Argo CD GitOps Flow │
│ │
│ 1. Developer pushes code to Code Repository │
│ ↓ │
│ 2. Developer kicks off Tekton pipeline │
│ ↓ │
│ 3. Tekton pulls source code from Code Repository │
│ ↓ │
│ 4. Tekton builds and pushes image to Image Registry │
│ ↓ │
│ 5. Tekton creates updated manifest files │
│ and pushes them to Infra Repository (Git) │
│ ↓ │
│ 6. Argo CD pulls state from Infra Repository │
│ (detects new image tag → OutOfSync) │
│ ↓ │
│ 7. Argo CD deploys workload to cluster │
│ (Pod · Deployment · Service · Ingress) │
│ Supports canary rollout manifests │
│ ↓ │
│ 8. User accesses the updated application ✅ │
└─────────────────────────────────────────────────────────────────┘
Let's walk through each step in detail.
Steps 1–2: Developer triggers the pipeline
The developer pushes code to the Code Repository and kicks off the Tekton pipeline — either manually or via a Git webhook trigger.
Steps 3–4: Tekton handles CI
Tekton pulls the source code, runs tests, compiles the application, builds the container image, and pushes it to the Image Registry with a new version tag (e.g. a timestamp or commit SHA, as covered in Part 6).
Step 5: The CI/CD handoff — Tekton updates Git
This is the critical step that connects Tekton to Argo CD. Tekton does not deploy directly to the cluster. Instead, it:
- Updates the image tag in the Kubernetes manifest (e.g.
values.yaml) - Commits and pushes the change to the Infra Repository
Git is now the source of truth for the new desired state.
Step 6: Argo CD detects the change
Argo CD continuously watches the Infra Repository. When it detects the new commit, it compares the updated manifest against the live cluster state and marks the application as OutOfSync.
Step 7: Argo CD deploys to the cluster
Argo CD syncs the new manifest to the cluster — creating or updating Pods, Deployments, Services, and Ingress resources. This step also supports advanced delivery strategies like canary rollout, where the manifest includes traffic-splitting configuration.
Step 8: User accesses the application
The updated application is live. The entire process — from code push to running deployment — is automated, auditable, and fully driven through Git.
3. Why This Split Works
| Concern | Tekton | Argo CD |
|---|---|---|
| Trigger | Git push / webhook | Git state change (poll or webhook) |
| Scope | Build, test, package | Deploy, sync, rollback |
| Cluster access | Needs push access to Image Registry | Needs apply access to target cluster |
| Rollback mechanism | Re-run pipeline with old tag | One-click Git revision rollback |
| Audit trail | Tekton PipelineRun logs | Git history + Argo CD sync history |
| Drift detection | ❌ None | ✅ Continuous |
By keeping these responsibilities separate:
- Tekton stays focused on what it does best: fast, modular, container-native CI
- Argo CD stays focused on what it does best: continuous reconciliation and GitOps-driven delivery
- Git acts as the contract between them — immutable, auditable, and the single source of truth
4. Series Wrap-Up
This article completes the series. Here's what we've covered end-to-end:
| Part | Topic |
|---|---|
| 1 | What is GitOps? Principles and core concepts |
| 2 | GitOps vs DevOps: How they differ and complement each other |
| 3 | GitOps CD model: Push vs Pull, and why Pull wins |
| 4 | Tekton architecture: Tasks, Pipelines, and the execution model |
| 5 | Tekton core concepts: PipelineResources, Workspaces, Results |
| 6 | Tekton in practice: Building a Java CI pipeline with Maven + Kaniko |
| 7 | Argo CD core concepts and architecture |
| 8 | Argo CD installation and configuration |
| 9 | Argo CD application management: multi-cluster deployments |
| 10 | Argo CD updates and rollbacks: GitOps-driven version control |
| 11 | Tekton + Argo CD: Complete GitOps pipeline end-to-end |
Together, these tools form a production-grade GitOps stack:
Developer → Git → Tekton (CI) → Git → Argo CD (CD) → Kubernetes
Every change is traceable. Every deployment is reversible. Every environment is reproducible from Git.
Thanks for following the series. If you found it useful, consider sharing it with your team — and explore the official Tekton and Argo CD documentation for deeper production configurations.
Top comments (0)