Google Cloud Deployment Manager: where manual management breaks down
Manual management of GCP resources goes unnoticed until the first environment drift. Someone added a firewall rule in the test environment, someone manually raised a quota or changed a disk size — and staging stops being a copy of production.
Then the release passes in tests and fails in prod, and the cause is not the code but the configuration that no one recorded.
Configuration drift accumulates more slowly than it seems. Changes made through the console leave no trace in the repository, and after a couple of months no one can say why one instance has a different set of labels or tags.
Google Cloud Deployment Manager solves this by keeping the infrastructure description as code: configurations and templates live in a version control system, and deployment reproduces the same environment from a single source.
Rolling back infrastructure without a change history turns into manual untangling.
If the previous state is not recorded anywhere, the only way to restore a working configuration is from memory or from snapshots, and that means hours of downtime and the risk of missing a dependent resource.
When changes go through declarative descriptions, every deployment has a version, and returning to the previous one is re-running a verified description rather than piecing things back together.
Let's break down how this is addressed: how to describe GCP resources declaratively, keep environments identical, and roll back infrastructure predictably.
What declarative infrastructure description provides
Declarative infrastructure description flips the usual logic: an engineer does not execute commands step by step, but describes the target state — which networks, clusters, load balancers, and access rights should exist.
The system itself brings the environment to this state and shows the discrepancy if reality has deviated from it.
Manual edits through the console cease to be the norm: any change goes through a template, enters the version control system, and leaves a trace — who, what, and why they changed it.
Environment reproducibility
The same template deploys identical environments for development, testing, and production.
The difference between them is described by parameters — node size, number of replicas, access policies — rather than separate instructions like "make it like prod, only slightly different." The class of failures "it worked in test, but not in prod" goes away along with manual edits: the configuration stops depending on who pressed the buttons and in what order.
Deployment time and change management
A full environment from scratch is deployed in minutes instead of days, and rolling back to a previous state is a return to the previous version of the template, not a restoration from memory.
Change management becomes predictable: an edit first passes review, then is applied to the test environment, and only then to production. This order removes the main risk of manual administration — an unnoticed deviation that surfaces at the moment of an incident.
Elimination of manual errors
A typo in a resource name, a forgotten firewall rule, an extra account with broad permissions — these are typical causes of incidents during manual configuration.
The declarative approach closes them at the process level: the template is checked before application, and the discrepancy between the described and actual state is visible immediately.
Our engineers build such configurations with reproducible modules and a clear structure so that the infrastructure can be handed over to another team without verbal explanations.
Approaches to GCP automation: comparing options
GCP automation is rarely built on a single tool: a typical landscape consists of declarative templates for the base infrastructure, deployment scripts for one-off operations, and manual actions where automation costs more than a mistake.
The choice between them is determined not by the convenience of writing, but by how the system survives configuration drift and repeated runs.
| Approach | When it fits | Limitations |
|---|---|---|
| Declarative configuration templates | Repeatable environments: network, subnets, firewall rules, IAM, clusters | Requires describing the entire state; changes go through review, not "hands-on right now" |
| Deployment scripts (CLI/SDK) | Data migrations, one-off operations, working around what a template does not describe | Idempotency rests on the author's discipline: a repeated run can create duplicates |
| Manual operations in the console | Diagnostics, emergency fixes, experiments | Not reproducible, not captured in change history, diverges from the environment |
| Hybrid: templates + wrapper scripts | Mature teams that need both state control and flexibility | Requires explicit boundaries: what is described declaratively and what remains imperative |
The key difference lies in the state model. A declarative template stores a description of what the infrastructure should be and brings it to that form on every run; a script executes a sequence of commands and knows nothing about the result of the previous run.
That is why mixing them without rules is dangerous: a manual edit of a resource described in a template will be overwritten on the next apply.
The practical criterion for choosing is the frequency of changes and the cost of a mistake. Anything that is created more than once and survives several releases goes into templates.
One-off operations and emergency interventions remain scripts, but with mandatory recording in the repository. Let's look at how to establish such boundaries so that automation does not turn into a source of drift.
Stages of implementing automation in the cloud
Implementing automation starts with an audit, not with writing templates. First, we inventory what is already deployed: which resources were created manually, what lives outside the declarative description, and where the configuration diverges between environments.
The infrastructure audit reveals which parts are even worth describing as code and which are cheaper to leave as they are — this saves weeks of work rewriting what does not change.
Next, we design templates and lay out the configuration in layers: network and access separately from services, services separately from data. This order yields a predictable change plan — an edit in one layer does not drag along a rebuild of the entire environment.
Google Cloud Deployment Manager works here as the declarative layer: we describe the target state, and the platform takes care of bringing things to it.
- Infrastructure audit. We assemble a resource map, flag manual changes and divergences between environments, and record dependencies.
- Template design. We lay out the configuration into layers and modules, and set parameters for different environments instead of copies of files.
- Pipeline setup. We connect the templates to a version control system; changes go through review and are applied automatically.
- Configuration verification. We run the deployment in an isolated environment and compare the result against the expected state before going to production.
- Migration of existing resources. We move what is already running without downtime — one component at a time with checks at every step.
- Handover of procedures. We give the team a description of the layers, the change order, and rollback rules, and run a walkthrough on a real task.
After the handover, the team changes infrastructure through the description rather than through the console: a change goes through review before being applied, and rolling back to the previous state takes minutes. Describe your task — we will come back with an estimate and a work plan.
Artifacts and documentation after implementation
After implementation, the customer receives not a "set of scripts" but a working infrastructure contour with documentation that can be used to develop it and hand it over to another team.
Everything described below is in the project repository: configurations in version control, changes go through review, and the deployment history is recoverable.
- Configuration templates — parameterized descriptions of resources: networks, subnets, firewall rules, instances, load balancers, storage. Environments (dev/stage/prod) differ by a set of parameters rather than copies of files, so divergence between environments is structurally excluded.
- Dependency diagrams — a graph of relationships between resources: what is created first, what depends on the network, where order is critical. It shows which component a change will affect, and this removes the main source of outages during edits.
- Access policies — roles and permissions on the principle of least privilege: separately for deployment service accounts, separately for engineers, separately for audit. Keys are moved out of configurations into a secure secrets store.
- Deployment instructions — a step-by-step procedure: preparing the environment, validating parameters, launching, verifying the result. With it, a new engineer brings up a stand from scratch without understanding the internals of each template.
- Rollback procedure — what to do in case of a failed deployment: how to roll back to the previous configuration version, which resources are deleted, which remain, how to verify integrity after rollback. The target time to return to a working state is minutes, not hours of manual edits.
- Monitoring map — which metrics and checks are tied to the created resources, where alerts are sent, and who responds.
- Change log — a record of what, when, and why was changed in the infrastructure, linked to tasks.
Documentation is updated together with configurations in a single repository — it does not go stale separately from the code. Describe your task: we will come back with an estimate and a plan for which set of artifacts will cover your processes.
Case: reducing deployment time by three times
What it was before
The client is a product startup with several environments: development, testing, pre-production, and production. Each environment was set up manually by engineers through the console: networks, subnets, firewall rules, instances, load balancer, access rights.
Deploying a single environment took two to three days, and each time the configuration came out slightly different — somewhere a tag was forgotten, somewhere an extra port was opened, somewhere the address ranges did not match.
Errors surfaced during operation: the test environment behaved differently from production, and reproducing a bug was impossible. Rolling back after a failed release turned into a separate project — no one remembered the exact state of the infrastructure before the changes.
What was changed
We described the entire infrastructure declaratively — in templates and configuration files that live in the repository alongside the application code.
Deploying an environment became a single command: the system itself creates resources in the correct order, tracks dependencies between them, and removes anything no longer described in the configuration.
We added a separation into reusable templates and parameters for each environment: the same logic, different values — instance size, network ranges, number of replicas.
Infrastructure changes now go through review like regular code, and the edit history shows who changed the configuration and why.
What it became
Deploying a full environment was reduced from two to three days to a few hours, and typical changes — to minutes. Most importantly, the result is reproducible: the same configuration produces identical infrastructure, so the test environment stopped diverging from production.
The class of errors like "forgot a parameter during manual setup" is gone completely — correctness is the responsibility of the template, not the engineer's attentiveness.
Rollback was simplified to reverting to the previous version of the configuration: the state of the infrastructure is always described and versioned. We work with professional tooling, so the result is stable from environment to environment.
How is Deployment Manager different from manual management?
With manual infrastructure management, an engineer performs a sequence of actions in the console or via a command-line utility: creates a network, subnet, firewall rules, virtual machines, a load balancer. The result exists only in the cloud — as the current state of the resources.
Reproducing it on another project or after a failure is possible only by repeating the same chain of steps, and any deviation (a missed rule, a different address range, a forgotten label) yields an environment that is "almost the same." The discrepancy is discovered only at the moment when something stops working.
Deployment Manager flips the logic: you describe the desired state in declarative configuration files, and the tool itself brings the project to that state. The files are stored in a version control system, go through review, and live alongside the application code.
This is the declarative approach — you record "what should be," not "which commands to run."
The difference shows up in tasks that are poorly solved or not solved at all by manual operations.
Templates with parameters make it possible to deploy an identical set of resources across several projects — the development, test, and production environments are assembled from a single description with different variable values.
A change in the template is applied predictably: the tool computes the difference between the current and target state and makes only the missing edits.
Another difference is change manageability. With the manual approach, a rollback means manually recreating the previous configuration from memory or from an outdated instruction.
With the declarative approach, it is enough to revert to the previous version of the files and apply it again — the project state once again matches the recorded description.
At the same time, the access control task is solved: edits go through review rather than through an engineer's direct access to the console.
Finally, templates remove the problem of "knowledge in one specialist's head." The infrastructure description is a document by which a new engineer deploys the environment from scratch without digging into the history of manual edits.
Manual management remains appropriate for one-off experiments and diagnostics, but for repeatable environments, the declarative approach provides reproducibility, versioning, and predictable rollback.
Technical doubts before starting work
Starting automation from a clean slate is almost never an option — and this is the main concern.
The infrastructure is already deployed, some resources were created manually through the console, some — with scripts, and the question is not whether it "will break," but how to bring it under management without downtime.
The answer: we describe the current state as code, bring the configuration in line with reality, and from then on make changes only through it. Existing resources are not recreated in the process — they stay in place, only the method of management changes.
Will all services have to be migrated at once?
No. The transition is done in parts: we select one isolated contour — for example, the network or the development environment — bring it under management, verify behavior on real changes, and only then move on.
Such a gradual transition provides a clear rollback point at every step: if something goes wrong, we return to the previous configuration state rather than rolling back the entire infrastructure.
What should be done with legacy resources that no one has touched for years?
They do not need to be rewritten to fit a clean template. We describe them as they are, mark them as inherited, and exclude them from automatic changes so that an accidental edit does not affect a running service.
After that, such resources are either gradually replaced with managed ones or remain isolated until planned decommissioning — the decision is made for each one individually, not all at once.
What risks does automation carry and how are they addressed?
The main risk is an uncontrolled change, when the configuration and reality diverge. It is addressed by previewing the change plan: before applying, you can see exactly what will be created, changed, or deleted, and any deletion is confirmed separately.
Plus configuration versioning — every change leaves a trace of who made it and why, and rolling back to a previous version takes minutes rather than hours of manual work.
Describe what you already have deployed and which services must not be touched — we will come back with an assessment and a plan for a gradual transition.
Let's discuss your task and come back with a plan
Describe your current infrastructure: how many projects and environments, how resources are deployed now — manually through the console, with scripts, or partially with templates.
That's enough to understand where automation will have an immediate effect and where you first need order in access and project structure.
Next, we'll analyze the task and come back with a work plan: which resources we move to a declarative description, what we leave as is, in what order we implement it so we don't halt your current releases.
The project estimate is based on the real scope — the number of configurations, the number of environments, rollback and access separation requirements.
What you'll get as a result:
- an analysis of your current infrastructure and growth points — where manual operations eat up time and create risk;
- a GCP automation option tailored to your processes: templates, environment parameters, deployment scheme;
- a phased work plan with priorities and a clear sequence;
- an access and role separation scheme for teams;
- an approach to storing configurations in a repository and validating changes before applying them;
- a rollback strategy if a deployment doesn't go as planned;
- a list of what we do and what stays on your side;
- timeline guidance for the phases, with cost calculated after audit.
An engineer's consultation here is a straight conversation: we ask questions about your environments, limits, and regulations rather than selling a ready-made solution. If automation won't pay for itself right now, we'll say so directly and suggest a narrower step.
You can discuss the task in whatever format is convenient — messaging, a call, or a walkthrough of your scheme. Describe what you have today and where you want to get to — we'll come back with an estimate and a plan.