Deployment automation
What it is
Deployment automation turns the act of publishing a validated build artifact to a target environment from a manual, error-prone ritual into a programmatic, repeatable pipeline step. It pairs CI/CD pipeline orchestration (Azure Pipelines, GitHub Actions) with configuration-as-code / IaC (ARM, Bicep, ansible-style templates) so every environment is deployed the same way, every time.
Why it exists
Repeatable, audited deployments make releases fast, deterministic, and reversible. Automation removes the “release engineer” bottleneck and the drift that appears when humans click-and-configure. It is the executable engine of continuous delivery.
Key ideas
- Declarative > imperative — describe the desired deployed state (a template, a spec) and let tooling converge to it, rather than hand-running steps.
- Config-driven / orchestration — automation engines (ansible-style) drive the deploy to PaaS/container/VM targets from a defined config (image, region, role, settings).
- Idempotent + observable — a deploy can be re-run safely and only reports what changed (see pipeline-reliability).
- Staging parity — automate the same path to dev/test/staging/production so “works in staging” means “works in prod.”
How it fits
CI → deploy job → IaC provisions/updates target → post-deploy smoke → promotion / rollback — automation sits in the deploy steps of a release definition.
Exam notes
- Automation ≠ CI: CI builds/tests; deployment automation is the release/deploy half, run off pipeline triggers.
- Recognize ARM/Bicep declarative provisioning and ansible-style orchestrators as deployment automation.
- It ships the release; gates and rollback supply the safety.
Related
release-definition · cd · github-actions · bicep · arm-template · deployment-ring · service-connections-for-deploys
📘 Source: Microsoft Learn — Azure DevOps · GitHub Docs — Deployment · Ansible docs