Module 7 takes the agent you built in Module 6 and turns it into a production cloud service. You'll containerize the stack, orchestrate it on Kubernetes, automate delivery, and operate it with observability, security, and cost controls. The goal: a reliable Digital FTE that runs 24/7 for real users.
Prerequisites: Modules 4-6. You need a working agent service to deploy.
You've been managing deployments manually: commit code, build a container, test locally, push to registry, run kubectl commands. This works for one person learning Kubernetes. At scale, manual deployments become a bottleneck. A single typo in a deployment command can take down production. Without automated testing, bugs make it to users. Without audit trails, nobody knows who deployed what, when, or why.
CI/CD (Continuous Integration/Continuous Deployment) solves this by automating the entire path from code commit to running service. Every change automatically triggers a pipeline: tests validate quality, builds produce artifacts, registries store versions, and deployments propagate to clusters. The pipeline becomes your quality guarantee.
This lesson teaches the conceptual foundations of CI/CD pipelines—the stages, the flow, the artifacts, and why each stage matters. You'll understand pipeline design before GitHub Actions syntax, and deployment principles before ArgoCD configuration.
Every production pipeline has the same conceptual structure, regardless of tools. Think of it like assembly line manufacturing:
Let's walk through each stage:
What happens: A developer commits to main branch. A webhook fires. The pipeline wakes up.
Why this matters: The trigger determines when automation starts. Without it, deployments stay manual. Common triggers:
Example trigger context: Your FastAPI agent lives in fistasolutions-agents/agent-task-service on GitHub. When you push to main, GitHub Actions receives a webhook event. The pipeline is triggered.
Artifact at this stage: A Git event (commit hash, branch name, author).
What happens: The pipeline checks out your code, compiles/packages it, produces a deliverable. For Python projects, this might be a wheel file or Docker image.
Why this matters: Compilation catches syntax errors early. Packaging ensures deployments are consistent (same code, same dependencies).
Example build context: Your FastAPI agent Dockerfile has dependencies pinned:
Output:
The build stage produces a container image artifact—a complete, self-contained package that runs anywhere (local machine, CI runner, Kubernetes cluster).
Artifact at this stage: A container image (or compiled binary, or wheel file—the thing to deploy).
What happens: The pipeline runs automated tests. Unit tests validate individual functions. Integration tests validate components work together. The pipeline only proceeds if tests pass.
Why this matters: Manual testing is unreliable (testers get tired, forget cases). Automated tests catch regressions before they reach users.
Example test context: Your FastAPI agent has tests:
Output:
If ANY test fails, the pipeline stops here. No deployment proceeds with broken code. This is the quality gate—the automated checkpoint that prevents bad code from reaching production.
Artifact at this stage: Test results and coverage reports (proof that code works as expected).
What happens: The tested, built artifact is published to a registry where it can be deployed from. For container images, this means pushing to Docker Hub, GitHub Container Registry (GHCR), or similar.
Why this matters: Registries are the source of truth for deployments. They version artifacts, store metadata, and make images available to clusters worldwide.
Example push context: After tests pass, the pipeline tags the image with the commit hash and version:
Output:
Now any cluster with registry access can pull and run that image.
Artifact at this stage: Published artifact in a registry (versioned, immutable copy).
What happens: The pipeline instructs Kubernetes (or another orchestration system) to pull the image and run it. In GitOps (which you'll see in later chapters), this means committing a configuration file to Git, and a GitOps controller automatically reconciles the cluster to match.
Why this matters: Deployment automation ensures consistency across environments (dev, staging, production all follow the same process). With versioning, you can rollback to previous versions if something breaks.
Example deploy context: A Kubernetes Deployment manifest specifies which image to run:
Output:
The service is live, handling requests.
Artifact at this stage: A running service in production (validated, versioned, auditable).
CI and CD are separate concepts, often confused:
Definition: Automatically integrate code changes into a shared repository, run tests, and report results. Where it happens: Stages 1-3 (Trigger, Build, Test). Purpose: Catch integration problems early. If your code works alone but breaks when combined with teammate's changes, CI detects it immediately. What "continuous" means: Every commit runs the pipeline, not weekly integration sessions.
Definition: Automatically deploy validated code to production after successful tests. Where it happens: Stages 4-5 (Push, Deploy). Purpose: Get working code to users immediately, without waiting for manual deployment windows. What "continuous" means: Every merge to main deploys to production (in high-trust teams).
A CI/CD pipeline produces and consumes artifacts—concrete outputs that move through stages.
A quality gate is a decision point in the pipeline: "Is this artifact good enough to proceed?"
Without gates, broken code reaches production:
You built a gitops-deployment skill in Chapter 1. Test and improve it based on what you learned.
Ask yourself:
If you found gaps:
Ask Claude: "I have a Python FastAPI application with unit tests stored in a GitHub repository. What would a CI/CD pipeline look like for this project? Walk me through the stages—what happens at each one?"
As Claude responds, evaluate: