Module 7: Gitops Beyond Terraform
1. Module 7 introduction: what this guide is not
Description
The six previous modules built something real and complete: a GitHub Actions pipeline that runs fmt, validate, and plan on every Pull Request, automatically applies when that PR merges to main, detects drift with a scheduled job, and stops on its own if a change tries to destroy the Shipments table. At this point, it's tempting to feel like "you already know CI/CD" — no scare quotes, in general, for any project. This module exists to correct that feeling before it settles in, not after. You're going to meet, by contrast and without building anything new, three real market tools (GitLab CI, CircleCI, Jenkins), the pull-based GitOps Kubernetes uses (ArgoCD, Flux), an application's deployment strategies (blue/green, canary, rolling), and the exact boundary between infrastructure CI/CD —what you built— and application code CI/CD. You're going to genuinely run exactly one new thing: a minimal, three-step pipeline over a trivial Python script, just so the difference from the infrastructure pipeline stops being a prose claim and becomes something you saw run with your own eyes.
Connection to the module
This module has a structure different from the six before it, and it's worth noticing right away: instead of building one more piece of andes-cargo-infra/, it locates everything you already built within a bigger picture. Lessons 2 through 6 are comparison and boundary honesty —alternative tools, the other GitOps, deployment strategies, the exact line between infrastructure and application—; none of them build anything. Lesson 7 is the module's only genuine hands-on: a three-step application pipeline, really run with act, deliberately brief, so the contrast with ci.yml/apply.yml is tangible, not just read. Lesson 8, the project, turns the whole module into a real document: an ADR (Architecture Decision Record) where Andes Cargo justifies its tool choice in writing, exactly the kind of document a real team produces when they make this decision at a job.
Why "I already know CI/CD" is the exact trap this module corrects
Think of what you learned as a city map, loaded on your phone, with every street walked on foot. You know every block, every traffic light, every shortcut. The map is real and the knowledge is real — but a city map, however complete, has an edge. On the other side of that edge there isn't "nothing" — there's an entire province, with its own routes, its own traffic, its own rules of the road, that your current map doesn't even attempt to draw. The mistake isn't not knowing the neighboring province. The mistake is looking at the edge of the map and assuming the world ends there, instead of assuming your map ends there.
This guide's six previous modules are the map of one real, complete city: infrastructure CI/CD, with GitHub Actions, over Terraform, with act and LocalStack. You walked every street of that city yourself — it's not a simplification or a summary. But that city has an edge, and on the other side there are, at minimum, four entire territories this module is going to show you on the map, without walking them:
- Another CI tool, same city. GitLab CI, CircleCI, Jenkins solve the same problem (
plan/applyon a reviewed change) with different syntax. It's, literally, the same city, with the streets named differently — not a new province. Lesson 2. - Another GitOps mechanism, a different city. ArgoCD and Flux aren't "GitHub Actions but for Kubernetes" — they're a fundamentally different kind of system (an operator that runs inside the cluster and pulls changes, instead of an external pipeline that pushes them). Lessons 3 and 4.
- Application deployment, a territory you never visited. Blue/green, canary, rolling deploys solve a problem this guide never had, because
terraform applydoesn't have "versions running in parallel" — everyapplyleaves the infrastructure in a single new state, not two coexisting while a decision gets made about which one stays. Lesson 5. - Code CI/CD, the most important boundary of the four. Everything you built runs on declarative HCL. A pipeline that compiles, tests, and deploys an application artifact (a Python API, a container) has a different shape, with its own characteristic steps. Lesson 6, with a tangible test in lesson 7.
Knowing where your map's edge is —and what's there, even if only by name, on the other side— is a skill just as real as knowing how to read a terraform plan. It's the difference between someone who says "I know CI/CD" without being able to explain what they're missing, and someone who says "I know infrastructure CI/CD with GitHub Actions; for Kubernetes I'd need ArgoCD, and for the app's backend I'd need a different test/build/deploy pipeline" — the second person sounds, in a real interview, exactly like someone who understands the whole landscape, not just their own corner.
This module's map: the 8 lessons
MODULE 7 — GITOPS BEYOND TERRAFORM
L1 Introduction (this one) the map's edge, why it matters to know it
L2 GitLab CI/CircleCI/Jenkins same city, different syntax — NAMED
L3 ArgoCD and Flux another GitOps mechanism — NAMED
L4 Push-based vs. pull-based the real technical distinction, closes M1.4
L5 Blue/green, canary, rolling app deployment — NAMED
L6 App CI/CD vs. infrastructure explicit contrast, short
L7 Hands-on: app pipeline EXECUTED — 3 steps, trivial Python, act
L8 Project: Andes Cargo's ADR EXECUTED (document) — the decision, in writing| # | Lesson | What gets executed/practiced |
|---|---|---|
| 1 | Introduction (this one) | The module's map; why it matters to know where this guide ends |
| 2 | GitLab CI, CircleCI, and Jenkins by contrast | Syntax and model comparison; the complete market evidence (Jenkins 5/13) revisited from Module 1 |
| 3 | GitOps for Kubernetes: ArgoCD and Flux, named | What they are — NAMED, hard boundary to kubernetes-and-eks-in-production-guide |
| 4 | Push-based vs. pull-based | The real technical distinction, closes the thread Module 1 opened |
| 5 | Application deployment strategies, named | Blue/green, canary, rolling — NAMED, boundary to kubernetes-and-eks-in-production-guide/aws-serverless-and-containers-guide |
| 6 | Application code CI/CD vs. infrastructure | Explicit, short contrast |
| 7 | Hands-on: a minimal application pipeline | EXECUTED: checkout/lint/test on a trivial Python script, with act |
| 8 | Project: Andes Cargo's tooling decision | EXECUTED (the document): a short ADR |
Notice the progression: first tools that solve the same problem you already solved (lesson 2), then mechanisms that solve a different problem with the same underlying principle (lessons 3-4), then a domain you never touched (lessons 5-6), and you close with a concrete test (lesson 7) and a documented decision (lesson 8).
What gets executed and what gets named, with no ambiguity
This guide held, since Module 1, to the rule that nothing gets simulated in prose: if something appears as executed, it really ran. This module adds a new layer to that honesty, because for the first time most lessons are, on purpose, named, not executed — and the reason isn't a limitation of act (like Module 1's five exceptions), it's that building ArgoCD, Flux, or a real blue/green pipeline is, by design, outside this specific guide's scope.
| Lesson | Executed? | Why |
|---|---|---|
| L2 — GitLab CI/CircleCI/Jenkins | No | Installing and running all three tools is outside a $0, single-guide scope — their real syntax is shown, verified against their official documentation, without installing them |
| L3 — ArgoCD/Flux | No | They require a Kubernetes cluster — hard boundary to kubernetes-and-eks-in-production-guide |
| L4 — Push vs. pull | Partial | Push was already executed in Modules 3 and 5 (ci.yml, apply.yml); pull is explained with ArgoCD/Flux's mechanism, without building it |
| L5 — Blue/green/canary/rolling | No | They require an application with multiple replicas running — boundary to kubernetes-and-eks-in-production-guide/aws-serverless-and-containers-guide |
| L6 — App vs. infra CI/CD | No (conceptual contrast) | Lesson 7 does execute this contrast's "app" half |
| L7 — Minimal app pipeline | Yes | Three steps (checkout, lint, test) on a trivial Python script, run with act — the only new code execution in the whole module |
| L8 — Andes Cargo's ADR | Yes (as a document) | The ADR itself is the executed deliverable — it doesn't run code, but it's a real artifact, not an abstract description |
Naming without building isn't, in this module, a gap — it's this entire guide's declared design boundary, the same logic you already saw with OIDC in Module 4 and with conftest in Module 6. The difference is scale: there, they were specific pieces within the same domain (Terraform on AWS); here, they're entire domains (Kubernetes, application CI/CD) that have their own complete guides in this same ecosystem.
Common mistakes
Thinking this module "doesn't count" because it doesn't build anything new (expectation-based). What happens: someone arrives at this module expecting another GitHub Actions workflow with new steps, and seeing most lessons are prose comparison, skims or skips them. Why it happens: the six previous modules trained the habit of "every lesson adds a piece to the pipeline" — this module breaks that pattern on purpose. How to spot it: if your question opening a lesson in this module is "what new YAML am I going to write?" instead of "what do I need to know exists, even if I don't build it here?". How to fix it: this module's value is exactly what this lesson describes — knowing the map's edge. Someone who can name ArgoCD, explain push vs. pull, and locate where this guide ends versus kubernetes-and-eks-in-production-guide demonstrates a level of understanding "I know how to write YAML" alone doesn't demonstrate.
Concluding that, because this module names ArgoCD and blue/green, "you already know" how to use them (the inverse mistake, more dangerous). What happens: someone reads lessons 3 and 5, sees ArgoCD's example YAML or the blue/green diagram, and in a real interview claims to have experience with those tools. Why it happens: reading about something and being able to name it precisely feels similar to knowing how to use it, especially when the rest of the guide really was genuine hands-on. How to spot it: if you couldn't, today, install ArgoCD against a cluster and get it to sync a repository — that's "not built," no matter how clear the explanation you read was. How to fix it: every lesson in this module marked NAMED says so explicitly, right at the point it appears, precisely so this confusion doesn't happen. Naming a tool precisely prepares you to recognize it and learn it fast when you genuinely need it — it doesn't replace building with it.
Assuming "GitOps" has one correct form, the one you learned in Modules 1-6 (conceptual). What happens: someone, after six modules building a push-based pipeline, concludes that's "the" GitOps, and that Kubernetes's pull-based is a minor or incorrect variant. Why it happens: it's natural to generalize from the only implementation you lived up close. How to spot it: if you're surprised, in lesson 4, that ArgoCD's mechanism is genuinely different —not a "with more steps" version of what you already know. How to fix it: Module 1, lesson 4, already flagged that GitOps is defined by four properties (declarative, Git as source of truth, automatic application, continuous reconciliation), not by a specific mechanism. This module's lessons 3 and 4 complete that idea with the exact technical detail of the two dominant ways to fulfill them.
Exercises
Exercise 1 — Name the four territories off the map. Without looking at this lesson, write from memory the four domains this module is going to name without building, and which ecosystem guide covers each in depth.
See solution
1. Other CI tools (GitLab CI, CircleCI, Jenkins) — they don't have a dedicated guide in this ecosystem; they get named by contrast within this same guide. 2. Kubernetes's pull-based GitOps (ArgoCD, Flux) — kubernetes-and-eks-in-production-guide. 3. Application deployment strategies (blue/green, canary, rolling) — kubernetes-and-eks-in-production-guide and aws-serverless-and-containers-guide. 4. Application code CI/CD (test, build, deploy of an artifact) — cicd-python-backend-guide and testing-in-cicd-guide. If you named all four territories and at least three of the four guides, you have a clear picture of the boundary this module draws.
Exercise 2 — Distinguish "same problem" from "different problem." Of exercise 1's four tools/domains, which one solves exactly the same problem you already solved (with different syntax), and which ones solve a genuinely different problem? Justify each case in one sentence.
See solution
Same problem, different syntax: GitLab CI, CircleCI, Jenkins — all three implement the plan-on-every-change / review / automatic-apply pattern, only the configuration file and who maintains it changes. Different problem: Kubernetes's pull-based GitOps solves "how do you keep a cluster's state synced" with a mechanism (internal operator, continuous watch) that has no equivalent in this guide's pipeline. Application deployment strategies solve "how do you go from one running artifact version to another with no downtime," a problem Terraform doesn't even pose, because apply doesn't have the concept of "two versions coexisting while a decision gets made." Application CI/CD solves "how do you build, test, and package source code before deploying it," a step (compiling/testing an artifact) Terraform doesn't have, because HCL doesn't "compile" in the same sense.
Exercise 3 — Apply the map metaphor to your own knowledge. Before continuing with this module, write (for yourself, there's no single right answer) a sentence describing your own map's edge: something you know how to do precisely, and something related you know exists but don't know how to build yet. Keep that sentence — you'll be able to compare it against the same question when you close Module 8.
See solution
There's no single correct answer — it's an honest self-assessment exercise, the same kind of question a real technical interviewer might ask you. One example of a complete answer, in this guide's spirit: "I know how to write a GitHub Actions pipeline that runs plan on every PR and apply on every merge against Terraform, with managed secrets and a guardrail that protects a specific resource. I know ArgoCD exists to do something similar inside a Kubernetes cluster, but I wouldn't know, today, how to install it or configure a real Application." What matters isn't the specific answer, it's the honesty of being able to draw the exact line between the sentence's two parts — exactly the skill this whole module practices.
Summary and next step
In this lesson you understood Module 7's complete purpose: not adding one more piece to Andes Cargo's pipeline, but locating that pipeline —complete and real— within a broader landscape of tools and domains this guide, by design, doesn't build. You saw the 8-lesson map, the exact table of what gets executed (only lesson 7) and what gets named (everything else), and why "knowing the map's edge" is a skill just as real as any of the ones you already practiced.
Before moving on you should be able to: name the four territories off this guide's map and their corresponding guide in the ecosystem; explain why GitLab CI/CircleCI/Jenkins are "the same city" while ArgoCD/Flux are "a different city"; and distinguish, unaided, between "I can name it precisely" and "I can build it."
Lesson 2 opens the comparison starting with the territory closest to what you already know: other CI tools that solve the same problem as ci.yml and apply.yml, with different syntax — and revisits, in full, the Jenkins market evidence you already saw in Module 1.
Resources
- GitHub Docs — GitHub Actions — official documentation for the tool you used in Modules 1 through 6, this entire module's point of comparison.
- nektosact.com — User Guide — official
actdocumentation, the only tool this module runs again (lesson 7). terraform-and-iac-guide(NIEVA) — the completeandes-cargo-infra/project this module contrasts against other domains, without rewriting it.src/paths/aws-cloud-ecosystem/VALIDACION.md(NIEVA, market audit, jul-2026) — the source for the Jenkins evidence lesson 2 revisits in full.