Teams end up on two clouds for good reasons: a customer requirement, an acquisition, a service only one provider offers. The mistake is letting each cloud grow its own way of deploying. The fix is one delivery model, expressed in GitHub, that both clouds follow.

1pipeline definition pattern across both clouds
< 15 minfrom merge to production for a healthy small-team pipeline
3 gatestests, security scan, and a human approval for production

GitHub as the control plane

Source, pull requests, CI/CD, secrets and environments all live in GitHub. Azure and GCP become deployment targets, not places where process lives. Reusable workflows mean a new service gets the same quality gates on day one.

Environments that do not drift

Infrastructure as code for both clouds, reviewed like application code. Ephemeral preview environments per pull request where practical. Production changes only through the pipeline. Drift is the root of most “it works in staging” incidents.

  • Infrastructure as code, reviewed in PRs
  • Consistent environment naming and promotion
  • Secrets in GitHub or cloud vaults, never in repos
  • Observability wired in from the first deploy

Ownership makes it stick

Someone owns releases, someone owns incidents, and the team reviews both weekly. Tooling without ownership decays within a quarter.

Real-world example

Cloud product team on Azure and GCP

Before

Fragile releases, drifting environments, incidents hard to trace across clouds.

After

GitHub Actions pipelines with quality gates, IaC for both clouds, observability and release ownership. Dependable releases and faster diagnosis.

Key takeaway

One delivery model, expressed in GitHub, with both clouds as targets. Add gates, kill drift, name owners.