Professional Deployment on Google Cloud: Cloud Run, GCE, Terraform

Google Cloud deployment setup: where version releases break

Releases break not during development, but at the moment changes are transferred to the production environment.

A typical picture: the image is built locally, migrations are run manually, environment variables are copied from notes — and a week later staging and production diverge so much that the same code behaves differently.

Environment drift is rarely visible immediately: it surfaces in the next release, when the cause is already lost in someone else's edit history.

The second source of failures is the order of steps. A migration applied after the new version starts locks tables, while the old container continues serving requests against the new schema and returns errors to some users.

A separate story is secrets and parameters that are edited manually in the console and not committed to the repository: during the next deployment they are silently overwritten with default values.

Rollback is the most expensive part. If the previous build is not saved as a reproducible artifact, the return is guesswork: it is rebuilt from a branch that has already moved ahead, and you get a third version unknown to anyone. Downtime during release stretches not into minutes, but into hours.

Google Cloud deployment setup closes exactly these three classes of failures: deployment follows a single scenario, environments are assembled from a shared description, and the previous version remains ready for one-step rollback.

What a managed release provides: speed, rollbacks, less downtime

Manual release relies on a person: they remember the sequence of actions, edit the configuration on the server manually, and stay available in the evening.

One such release takes hours, and release time grows with the number of services — each change requires going through the entire chain again.

When infrastructure is described in Terraform and deployment runs with a single command, the same release fits into minutes and does not depend on who exactly starts it.

Predictable rollback stops being a separate operation. The previous version remains available, and shifting traffic back to it takes seconds, without deploying a backup and waiting for database restore.

This changes the cost of a mistake: a failed release is rolled back before users have time to notice it.

Multiple environments are described by one set of rules: test, pre-production, and production differ by parameters, not by manual edits “only here.” A change goes through the same path of checks, so the discrepancy “it worked in test” stops being the norm and stops consuming a day of investigation.

Downtime cost is calculated not abstractly, but in minutes of unavailability and lost requests. When a release does not require a night window and manual pauses, unavailability shrinks to the traffic switch time, and some updates happen with no service interruption at all.

The result is a repeatable release: the same output for the same input, version history, and a clear rollback point. Next, we break down what such a process consists of.

Deployment options: containers, machines, orchestrator

Choosing a hosting option determines not only how the application handles load peaks, but also how much engineering time goes into operations.

Managed containers remove server maintenance from the team, a dedicated virtual machine gives full control over the environment, and orchestration is needed where there are many interconnected services. Below is a working comparison of Google Cloud deployment options, which is usually how we choose.

In practice, there is rarely just one scheme: the frontend and API go into managed containers, while the database and heavy processors remain on a dedicated machine or inside the orchestrator.

We describe these boundaries as code so the configuration can be rebuilt from scratch and reproduced in a test environment without manual edits. From there we break down how this is covered further — with builds, environments, and rollbacks.

Infrastructure audit, environment scheme, setup, handover

We move from the current state to the procedures your team applies without us.

We start with an infrastructure audit in the cloud project: inventory of resources, access rights, secret storage locations, and manual operations in the release — these are the first to break when the responsible person changes. We do not touch production until the environment scheme is approved.

1. Infrastructure audit. Map of resources, dependencies, and permissions, list of manual steps and failure points; we mark what is moved into a declarative description and what requires restructuring.
2. Environment scheme. We separate development, pre-production, and production: separate configurations, isolated secrets, dedicated quotas — eliminating the class of errors involving keys and data from the wrong environment.
3. Infrastructure as code. Resources move into configuration with state in secure storage and locking: manual edits in the console stop being the norm, and the environment is brought up repeatably.
4. Deployment setup. Artifact build, image registry with a retention policy, traffic splitting between service revisions, database migrations as a separate step.
5. Pre-release verification. Run in pre-production, rollback rehearsal to the previous revision, metrics and alerts for errors and latency — before production traffic.
6. Handover of procedures. Release and rollback documentation, walkthrough with your engineers, support for the first independent release.

What remains with your team after handover

We hand over not a “working server,” but a complete kit that your team can use to develop and rebuild the environment without us.

The infrastructure is described declaratively, not assembled by hand in the Google Cloud console: the environment can be brought up from scratch and produce the same services, networks, and permissions. Below is exactly what goes into your repository and wiki at acceptance.

• Configuration as code — description of all environments, services, and networks in repository files with change history. Test and production environments are assembled from one set of descriptions; discrepancies are visible at the verification stage, not in production.
• Infrastructure diagrams — a map of services, load balancers, queues, databases, and the relationships between them, with notes on which elements change together. Needed so an edit to one component does not break a neighboring one.
• Access policies — service account roles, least-privilege permissions, separation of environments from each other, procedure for issuing and rotating keys.
• Rollback procedure — how to return to the previous service revision, how long it takes, who makes the decision, what checks are run after the return.
• Recovery procedure — step-by-step order for bringing up the environment from scratch: what is deployed first, where backups are stored, how data integrity is checked afterward.
• Release instructions — build and deployment sequence, environment variables, working with secrets, what to do if pre-publication checks fail.
• Observability — list of metrics and logs, alert thresholds, and routes they are sent to the on-call engineer.

All of this lives in your repositories and accounts, and access has been handed over to your team. Our engineers remain available, but further work does not require our participation in daily operations.

Case study: manual deployment became a predictable release

The client came with manual deployment: an application on virtual machines, instructions in the wiki, release directly on the server — copying files, building “in place,” editing configuration by hand.

One release took 40–50 minutes of engineering time, and every fifth deployment ended in an incident: a forgotten environment parameter, mismatched dependency versions, an open port.

Recovery was the most expensive: they looked for what exactly had changed, compared the configuration with the previous state, and rebuilt the previous version from scratch. Metrics before: 45 minutes per release, 20% of deployments with rollback, average recovery time 2.5 hours.

What changed

The platform was rebuilt on Google Cloud: the build was moved into a pipeline, environments were described declaratively, state went into a managed service, and secrets into a vault.

Deployment goes to a new instance, traffic switches only after a readiness check, and the previous version remains in the registry as a ready rollback point.

Metrics after: release — 6 minutes without engineer involvement, failures — one deployment out of twenty, rollback to the previous version — 90 seconds, service recovery — 4 minutes instead of 2.5 hours.

A separate effect is release frequency.

Previously changes were accumulated for weeks to avoid risk; now they are released as soon as they are ready, and the smaller the difference between versions, the less frequent the failures and the faster the investigation if something goes wrong.

What to do if the project is already deployed manually?

There is no need to rewrite the application — we describe and automate what already works.

Migration from manual deployment proceeds in stages and service by service, not with a single switch: the old release scheme remains operational until the new one has proven reliable in individual areas.

The first step is inventory. We record the actual state: which services are running, where images come from, where environment variables and secrets are stored, which access rules are exposed externally.

The main risk here is not in the code, but in the discrepancy between documentation and the working environment: some settings are usually applied by hand and recorded nowhere.

Next, we describe the infrastructure as code in Google Cloud, starting with the periphery — network, service account permissions, access rules, image registry.

Applying these descriptions does not restart running containers, so the product continues serving requests without downtime.

Build and automated deployment are migrated last. First, the new process deploys a version in a separate environment, checks run there, and only then is traffic shifted in portions from the current revision, with one-command rollback to the previous one.

We do not recreate the database: schema migrations are executed as a separate step and are reversible.

This order removes manual edits on servers gradually and without rewriting the project.

Common technical concerns before starting work

Concerns at this stage are almost always the same: where secrets will be stored, who will get access to production, whether the previous version can really be restored quickly, and whether the project will have to be rewritten. Below are engineering answers without generalities.

How are permissions and roles separated?

We grant access on the least-privilege principle: the application’s service account can do only what it needs to operate, and the test and production environments are isolated. An engineer receives a role for a specific environment and for the duration of a task. All configuration changes go into the audit log — you can see who changed what and when.

How quickly can a bad version be rolled back?

Each release is an immutable image with a separate tag, so returning to the previous version is switching traffic to the past revision, not rebuilding. It takes less than a minute.

We write schema migrations backward-compatible so the old application version continues to work with the new database.

Is this compatible with the current stack?

There is no need to migrate the entire project: usually it is enough to package the build and run into a container, while the framework, database, and queues remain the same. Services that already run on virtual machines continue to run. We configure routing at the load balancer level and switch it gradually.

Let’s discuss the task: we’ll return with an estimate and work plan

Describe how the release of changes is set up now: what builds the artifacts, who deploys to environments, where configurations and secrets are stored, how long rollback to the previous release takes.

This is enough to understand the bottlenecks — manual steps, discrepancies between environments, lack of deployment history.

In response, we send an implementation plan with stages, scope of work, and interaction procedure. For each item, we specify what we do and what remains on your side — so the work estimate is verifiable, not “turnkey by agreement.”

• Review of the current release scheme: build, environments, access, points of manual intervention.
• Stage-by-stage work estimate with responsibility boundaries and dependencies on your team.
• Implementation plan: order of environment migration, rollback points, windows for changes.
• Infrastructure as code description: configurations, environment variables, scaling rules.
• Interaction procedure: one point of contact, stage reporting, channel for urgent questions.
• Acceptance criteria at each step: what we consider complete and how we verify it.
• Deployment support procedure after launch: how changes are released, how failures are investigated.

Describe the task as it is — we’ll return with an estimate and work plan.