In this lesson, you will learn how to decouple your deployment logic from your continuous integration (CI) pipeline to transition from "push-based" deployments to a more robust, decoupled architecture.
The Problem with Tightly Coupled Pipelines
In a standard CI/CD model, your pipeline is responsible for two distinct phases: building artifacts (CI) and pushing those artifacts to a cluster (CD). When these are linked, your CI tool (like Jenkins or GitHub Actions) must hold the credentials to your production Kubernetes cluster. This creates a security risk—if your CI runner is compromised, the attacker gains direct access to your production environment. Furthermore, if your deployment step fails, it can block the completion of your build, making it difficult to isolate build failures from environmental configuration issues.
Moving to a Decoupled Architecture
Decoupling means your CI pipeline finishes as soon as the artifact (e.g., a Docker image) is built and pushed to your container registry. The pipeline essentially says, "I have produced a valid version of the software," and stops there.
Deployment, by contrast, becomes an independent process that "pulls" the new version into the environment. By utilizing a GitOps approach, you treat your cluster state as the source of truth. Your CI pipeline simply updates a manifest repository with the new image tag:
# Update the deployment manifest via CI
- name: Update Kubernetes Manifest
run: |
sed -i "s|image:.*|image: my-registry/app:${GITHUB_SHA}|" k8s/deployment.yaml
git commit -am "Update image to ${GITHUB_SHA}"
git push
Once the manifest is updated, an agent inside your cluster (like ArgoCD or Flux) notices the drift between the Git repository and the current cluster state. It then triggers the reconciliation loop to pull the new image and deploy it.
By separating these concerns, your CI runners no longer need cluster-admin access, and your deployments become asynchronous. If your cluster is temporarily unreachable, your CI build doesn't fail; the deployment will simply reconcile once connectivity is restored. This isolation increases both the security of your supply chain and the overall stability of your release lifecycle.
Key Takeaway: By offloading deployment to a reconciliation-based agent, you remove sensitive credentials from your CI environment and ensure that the build process remains purely focused on artifact creation.