In the previous post on our CICD series, we talked about Continuous Delivery and Deployment—safely rolling out code using techniques like Blue/Green and Canary releases.

We also established that managing the underlying AWS or cloud infrastructure with tools like OpenTofu is a prerequisite.

But what software actually pushes the button? What orchestrates the rollout?

If you are coming from a traditional SysAdmin background, your instinct is probably to write a script that connects to a server via SSH and pushes the new code. For a long time, early CD tools did exactly that. But as cloud environments and Kubernetes clusters grew more complex, the industry realized that pushing code from the outside was a security risk and a scaling nightmare.

Today, the CD toolbox is divided into two distinct camps: traditional "Push-based" tools, and modern "Pull-based" GitOps controllers. Here is a breakdown of the tools powering modern deployments.

Push-based Continuous Deployment tools

If your infrastructure is heavily rooted in a single public cloud and utilizes traditional virtual machines (like EC2) or serverless functions (like Lambda), push-based deployment tools are often the easiest starting point.

Most tools in the push-based domain are from the cloud providers. But, there is a limited selection of open-source options too.

1. AWS CodeDeploy: This is a managed service that automates deployments to EC2 instances, on-premises servers, or AWS Lambda. It handles the rolling updates and health checks for you. You configure your CI pipeline (like GitHub Actions) to hand the artifact to CodeDeploy, and it pushes the update out to your fleet.

2. Google Cloud Deploy: Google Cloud Deploy is a fully managed continuous delivery service, but it is distinctly built for a container-first and serverless world. It is designed specifically to deploy applications to Google Kubernetes Engine (GKE), Cloud Run (Google's serverless container platform), and Anthos (for multi-cloud Kubernetes). Still Google Cloud Deploy is also adopts a push-based deployment model.

3. Spinnaker: Originally built by Netflix, Spinnaker is the heavyweight champion of multi-cloud continuous delivery. It connects directly to your cloud providers and provides a single pane of glass for complex deployment pipelines, native Canary analysis, and automated rollbacks. It is incredibly powerful, but requires significant effort to maintain.
   
   If you are operating at a massive scale—perhaps deploying across AWS, Azure, and Google Cloud simultaneously—Spinnaker is your heavy-duty deployment orchestrator.

Pull-Based Continuous Deployment tools (The Modern Standard: GitOps Controllers)

If you are deploying containerized applications into Kubernetes, the industry has fundamentally shifted away from "pushing" code. Instead, we use a paradigm called GitOps which is a pull-based deployment model.

In GitOps, you don't give your CI tool the security credentials to access your production cluster. Instead, you install a CD controller inside the Kubernetes cluster. That controller constantly monitors your Git repository. When it sees that the declarative YAML files in Git have changed (e.g., updating an image tag from v1.0 to v1.1), the controller pulls those changes down and updates the cluster from the inside out.

1. Argo CD: The most popular GitOps tool for Kubernetes today. It provides a beautiful visual dashboard showing the exact state of your applications compared to the state declared in Git. If someone manually changes a configuration on the live cluster, Argo CD immediately detects the "drift" and automatically syncs it back to match what is in Git.

2. Flux: Another highly popular, CNCF-graduated GitOps controller. It is deeply integrated into the Kubernetes ecosystem and focuses heavily on automation and security, operating entirely without a GUI by default.

Why GitOps is the Future of CD

For a transitioning engineer, mastering a tool like Argo CD is a career-defining move.

By using a Pull-based GitOps tool, your Git repository truly becomes the single source of truth for both your application code and your live production environment. If your entire Kubernetes cluster crashes, you don't need to manually rebuild it or run complex restore scripts. You simply spin up a new cluster, install Argo CD, point it at your Git repo, and it will automatically rebuild your entire production environment to the exact state it was in right before the crash.

This completely eliminates the concept of a "pet" server and transforms deployment from a stressful, manual push into a continuous, automated synchronization.