Infrastructure as Code & Deployment

Infrastructure as code is the practice of defining servers, networks, and services in version-controlled files instead of configuring them by hand. The files become the source of truth: you change the code, review it, and a tool reconciles the running environment to match. The category spans three related jobs - provisioning the infrastructure, configuring what runs on it, and delivering application changes through a pipeline - and most teams use more than one tool because each job has different leaders.

Provisioning, configuration, and delivery

Provisioning creates the raw resources - virtual machines, networks, managed databases. Cloud-native provisioning tools like Azure Resource Manager and Google Cloud Deployment Manager handle this within a single cloud (Terraform does it across clouds). Configuration management then installs and configures software on those resources - Ansible and Chef live here. Continuous delivery builds, tests, and ships application changes - GitLab CI/CD, CircleCI, and Argo CD cover this end.

Declarative and idempotent

The idea that ties the category together is declarative, idempotent configuration. You describe the desired end state - "this network, these five servers, this package installed" - rather than the steps to get there, and the tool figures out what to change. Running it twice against an already-correct system does nothing. That property is what makes infrastructure code safe to re-apply and lets the same definition rebuild an environment from scratch identically.

GitOps and pull-based delivery

GitOps applies the same principle to deployment: a Git repository holds the desired state of a running system, and a controller continuously reconciles the cluster to match. Argo CD is the canonical example for Kubernetes - instead of a pipeline pushing changes into the cluster, an in-cluster agent pulls the declared state from Git and converges to it, with drift detection and one-click rollback to any previous commit.

Choosing tools

Single cloud, native provisioning? ARM (Azure) or Cloud Deployment Manager (GCP); Terraform for multi-cloud.
Configuring software on servers? Ansible (agentless, push) or Chef (agent, pull).
CI/CD pipeline tied to your repo? GitLab CI/CD if you're on GitLab; CircleCI as a hosted, repo-agnostic option.
Declarative Kubernetes delivery? Argo CD for pull-based GitOps.

The choices that matter are which cloud you're on, whether a tool is push or pull, agent or agentless, and how tightly it integrates with your source control. A typical stack pairs a provisioning tool, a configuration tool, and a delivery pipeline rather than betting on one tool for everything.

In this section

Ansible
An agentless configuration-management tool that uses SSH and idempotent YAML playbooks to install software, change settings, and orchestrate tasks across server fleets from a single control node - push-based and simple to adopt.
Argo CD
A declarative GitOps continuous-delivery tool for Kubernetes that treats a Git repo as the source of truth, continuously reconciling the cluster to match, with drift detection, self-heal, and commit-based rollback.
Azure Resource Manager (ARM)
Azure's native deployment layer and its JSON infrastructure-as-code templates - declarative, idempotent, with incremental and complete modes - plus Bicep, the concise language that compiles to ARM templates.
Chef
A configuration-management tool using a Ruby-based DSL and a pull model - chef-client agents fetch policy from a Chef Server and converge each node to a declared state via resources, recipes, and cookbooks. Suits large, long-lived fleets.
CircleCI
A hosted, repo-agnostic CI/CD platform that runs YAML-defined jobs and workflows in Docker or VM executors on every push, with dependency caching, test-splitting parallelism, and reusable orbs.
GitLab CI/CD
Continuous integration and delivery built into GitLab - pipelines defined in .gitlab-ci.yml with ordered stages, parallel jobs on runners, environments with rollback, artifacts, and an integrated container registry.
Google Cloud Deployment Manager
Google Cloud's native infrastructure-as-code service - declarative YAML configurations (with Jinja2/Python templates) that create and manage GCP resources as a single deployment. Google now steers new work toward Terraform.
Jenkins
A self-hosted automation server that runs build, test, and deploy jobs on infrastructure you own. Covers declarative Jenkinsfile pipelines, the controller-agent split, ephemeral Kubernetes agents, the credentials store, and when self-hosting beats a hosted runner.
Puppet
A pull-based configuration-management system that enforces a declared desired state on servers continuously, reverting drift on every agent run. Covers resources, classes and the roles-and-profiles pattern, per-node catalog compilation, --noop dry runs, and where it fits against Ansible and Chef.
Tekton
A Kubernetes-native CI/CD framework where every pipeline step is a container in a pod and every object is a custom resource. Covers Tasks, Steps and Pipelines, shared workspaces, webhook-driven PipelineRuns, and how it splits build duties with a GitOps deployer like Argo CD.
Terraform
A declarative infrastructure-provisioning tool that diffs your HCL config against a recorded state file and shows a plan before changing any cloud resource. Covers providers and resources, the plan-apply loop, remote locked state, import, modules, and where it hands off to configuration managers.
Travis CI
A hosted continuous-integration service driven by a single .travis.yml that runs your build lifecycle in a fresh VM on every push. Covers the install/script phases, parallel build matrices, sequential build stages, encrypted secrets, and how it stacks up against platform-native runners.