You need to build a CI/CD pipeline on GCP using Cloud Build that builds a container image, runs integration tests against a staging database, deploys to a staging GKE cluster, runs smoke tests, and promotes to production with approval. Walk through the cloudbuild.yaml design and security considerations.

Cloud Build Pipeline Architecture

Cloud Build executes steps as containers sequentially or in parallel within a build. Each step shares a /workspace volume for artifact passing. For production CI/CD, you should use Cloud Build triggers connected to your Git repository (Cloud Source Repositories, GitHub, or GitLab), with separate triggers for PR validation, staging deployment, and production promotion. The build runs on a worker pool—either the default shared pool or a private pool inside your VPC for accessing internal resources like staging databases.

Security and Secret Management

Never store secrets in cloudbuild.yaml or substitution variables. Use Secret Manager with availableSecrets to inject credentials as environment variables. The Cloud Build service account needs roles/secretmanager.secretAccessor. For GKE deployments, use Workload Identity Federation so Cloud Build authenticates to the cluster without long-lived service account keys. Private worker pools ensure build traffic stays within your VPC, enabling access to Cloud SQL instances via private IP and preventing data exfiltration.

Integration Testing Strategy

Spin up ephemeral test infrastructure using Cloud Build steps. For database tests, either use a Cloud SQL clone (fast, uses disk snapshots) or a containerized PostgreSQL in the build itself. Run migrations, seed test data, execute integration tests, then tear down. Cloud Build supports test result reporting via testResults field for build insights.

Production Promotion with Cloud Deploy

Cloud Deploy provides a managed continuous delivery pipeline with approval gates. Define a delivery pipeline with staging and production targets. Cloud Build publishes a release to Cloud Deploy, which handles the rollout strategy (canary, blue-green, or rolling). Production targets can require manual approval from specific IAM principals before deployment proceeds.

Cost and Performance Optimization

Use kaniko for layer-cached Docker builds instead of docker-in-docker. Cache Go/Node/Python dependencies in Cloud Storage buckets. Run independent steps in parallel using waitFor: ['-']. Use machineType: E2_HIGHCPU_32 for CPU-intensive builds. Set timeout at both step and build level to prevent runaway builds from burning budget.