Building and Testing Applications
The build pipeline
Cloud Build executes a config file of steps, each running in a container. Triggers fire on branch pushes, tags, or pull requests, so the same config can build pull-request previews and release images. Built-in substitutions such as $PROJECT_ID, $COMMIT_SHA, and $SHORT_SHA are provided; custom substitutions must start with an underscore (_ENV) and be supplied with --substitutions=_ENV=prod or declared in the trigger. Every artifact should land in Artifact Registry, which replaces the legacy Container Registry.
Traps in build configuration
Default build timeout is 10 minutes, extendable to 24 hours. A build that must reach a private IP, an on-prem host, or a VPC-SC perimeter needs a private pool, not the default pool. Steps that are slow but not CPU-heavy should not trigger a machine-type change; steps that compile large codebases might. The Cloud Build service account needs explicit roles such as Artifact Registry Writer and Logs Writer, and cross-project pushes require granting it in the target project.
Testing strategy
Run fast unit tests inside the build. For integration tests, use the provided emulators (Pub/Sub, Firestore, Datastore, Spanner) or short-lived test projects rather than shared long-lived environments. Test the container contract locally before deploying: it must listen on $PORT and bind 0.0.0.0. After deployment, run smoke tests against a tagged Cloud Run revision that receives no production traffic.
Supply chain
Enable vulnerability scanning on the repository, and use Binary Authorization attestations so only images built by your pipeline can deploy. Cloud Deploy models promotion pipelines with distinct stages and can require manual approval between them.
Rule of thumb: build the image once, tag it with the commit SHA, and promote that identical digest through every environment. Rebuilding per environment makes "it worked in staging" meaningless and breaks attestation.