Building and testing applications

Local development environment

Emulators and local testing

Develop and unit test without touching real, billable resources.

• The Google Cloud CLI ships emulators for Pub/Sub, Firestore (and Datastore mode), Bigtable and Spanner. Start one (for example gcloud emulators firestore start), then point your code at it. Client libraries detect an emulator through environment variables such as PUBSUB_EMULATOR_HOST and FIRESTORE_EMULATOR_HOST; gcloud emulators ... env-init prints the exports to set. Credentials are not needed.
• Cloud Storage has no official emulator; use a local fake or a test bucket. Cloud SQL and AlloyDB are tested locally against a PostgreSQL or MySQL container.
• The Functions Framework runs Cloud Run functions locally (HTTP and CloudEvents) in your language. A Cloud Run container runs locally with Docker, setting PORT.
• Use Application Default Credentials locally with gcloud auth application-default login; impersonate a service account (--impersonate-service-account) to test with the same permissions as production. Do not download keys to your laptop.

Tools

Rule of thumb: laptop IDE plus emulators and Cloud Code for daily work; Cloud Workstations when a team needs identical, centrally governed environments; Cloud Shell for ad hoc commands.

IDE integrations and AI tooling

• Configure the IDE with the Cloud SDK, Cloud Code, language plugins and debuggers, and the credentials the app needs through ADC.
• AI coding assistants (Gemini Code Assist in the IDE and Gemini CLI) provide code completion, chat, code generation, explanation, refactoring and test generation, and can work as agents on multi-step tasks.
• Context engineering means giving the assistant the right context: project files, repository indexing, rules or context files that describe conventions, and clear prompts with acceptance criteria. Better context gives better, safer output.
• MCP (Model Context Protocol) servers let assistants call tools and read data from systems such as Google Cloud services, databases and documentation. You register MCP servers in the IDE or CLI settings. Treat them as privileged: scope credentials and review actions.
• Always review generated code; assistants speed delivery but do not replace tests, code review or security scans.

Building: Cloud Build and Artifact Registry

Cloud Build

Cloud Build is the serverless CI service. A build runs a sequence of steps, each in a container (a builder image), sharing the /workspace directory.

steps:
- id: build
  name: gcr.io/cloud-builders/docker
  args: ['build', '-t', 'us-docker.pkg.dev/$PROJECT_ID/app/web:$SHORT_SHA', '.']
- id: test
  name: us-docker.pkg.dev/$PROJECT_ID/app/web:$SHORT_SHA
  entrypoint: npm
  args: ['test']
images: ['us-docker.pkg.dev/$PROJECT_ID/app/web:$SHORT_SHA']
options:
  logging: CLOUD_LOGGING_ONLY

Key facts:

• Config: cloudbuild.yaml (or JSON), or a Dockerfile, or buildpacks (gcloud builds submit --pack image=... and gcloud run deploy --source). gcloud builds submit --tag IMAGE . is the quick Docker path.
• Steps run in order unless you set waitFor; waitFor: ['-'] starts a step immediately, enabling parallel steps. id names a step so others can wait for it.
• A step that exits non-zero fails the build, which stops later steps. This is how tests gate a release.
• images lists images to push after all steps succeed; artifacts copies files to Cloud Storage or packages to Artifact Registry.
• Substitutions: built-in $PROJECT_ID, $BUILD_ID, $COMMIT_SHA, $SHORT_SHA, $BRANCH_NAME, $TAG_NAME, $REPO_NAME; user-defined ones must start with an underscore ($_ENV) and can be set in the trigger.
• Triggers start builds on a push to a branch, a pull request, a tag, a Pub/Sub message, a webhook or a manual run. Connect repositories from GitHub, GitLab, Bitbucket or Cloud Source Repositories through Cloud Build repositories (2nd gen). Comment control and approvals protect builds from untrusted pull requests.
• Secrets: use availableSecrets with Secret Manager and reference them with secretEnv; never put secrets in substitutions or image layers.
• Service account: builds run as a service account; best practice is a user-specified one with only the roles needed (Artifact Registry writer, log writer, deploy permissions), not a broad default.
• Worker pools: the default pool is Google-hosted (machine type via options.machineType, for example E2_HIGHCPU_8). Private pools run in your VPC to reach private resources and to control networking.
• Timeout defaults to 60 minutes (timeout field adjusts it). Caching: reuse layers with --cache-from, Kaniko cache, or cache directories in Cloud Storage to speed builds.
• Logs go to Cloud Logging (and optionally a bucket). Set logging option when using a custom service account.
• Deploy steps: use the gcloud builder to gcloud run deploy or kubectl/Cloud Deploy gcloud deploy releases create to hand over to Cloud Deploy for staged delivery.

Artifact Registry

Artifact Registry stores container images and language packages, and is the successor to Container Registry (shut down; gcr.io addresses now map to Artifact Registry).

• Formats: Docker/OCI images, Maven, npm, Python, Go, NuGet, apt, yum, Helm charts, generic.
• Repository modes: standard (your own artifacts), remote (a proxy cache of an upstream such as Docker Hub or PyPI), virtual (one endpoint combining several repositories with priorities, which also guards against dependency confusion).
• Repositories are regional or multi-regional; keep them near where builds and deployments run to cut latency and egress.
• Address format: LOCATION-docker.pkg.dev/PROJECT/REPOSITORY/IMAGE:TAG. Prefer digests (@sha256:...) for deploys.
• IAM: roles/artifactregistry.reader to pull, writer to push, repoAdmin, admin. Grant the runtime service account (or the GKE node/Workload identity) reader on the repository.
• Cleanup policies delete or keep versions by age, count or tag; tag immutability on Docker repositories stops tags being overwritten.
• Vulnerability scanning is done by Artifact Analysis: automatic scanning on push (and continuous updates as new CVEs appear), plus on-demand scanning for local images. Results can gate deployment through Binary Authorization.
• Configure Docker with gcloud auth configure-docker LOCATION-docker.pkg.dev.

Build provenance and Binary Authorization

Provenance is verifiable metadata about how an artifact was built: who built it, from what source, by which builder.

• Cloud Build can generate SLSA build provenance for container images automatically (enabled by build option or by default for supported builds). It is a signed attestation stored in Artifact Analysis, covering source repo and commit, build steps, builder and image digest.
• View it with gcloud artifacts docker images describe IMAGE --show-provenance.
• Binary Authorization checks that an image deployed to GKE or Cloud Run satisfies a policy. A rule can require an attestation from an attestor, for example the built-in “built by Cloud Build” attestor, so only images built in your pipeline (not pushed from a laptop) can run. Attestors rely on Cloud KMS signing keys and the policy can be set per cluster or service, with a default rule, exempt images and a dry-run mode that logs violations without blocking. Break-glass lets an authorised user override with auditing.
• Typical secure supply chain: source in a repo, Cloud Build builds and signs provenance, Artifact Analysis scans, a pipeline step adds a “passed vulnerability scan” or “passed tests” attestation, Binary Authorization admits only attested digests.

Testing

Unit tests and AI assistance

• Unit tests are fast, isolated and run on every commit. Mock or fake cloud clients (or use emulators) so they need no network or credentials. Design code with dependency injection so clients can be swapped.
• AI coding assistants can write unit tests: ask them to generate cases for a function, include edge cases, error paths and boundary values, and mock external calls. Then review and run the tests: confirm they assert real behaviour, fail when the code is wrong, and do not simply mirror the implementation. Assistants can also explain failing tests and suggest fixes.
• Keep a test pyramid: many unit tests, fewer integration tests, few end-to-end tests. Add contract tests where services call each other.

Automated integration tests in Cloud Build

Integration tests prove components work together: the service with a real database, queue or another service.

• Run them as steps in cloudbuild.yaml after unit tests and the image build.
• Options for dependencies: start emulators or database containers inside the build (Docker Compose or background steps), use a Cloud SQL Auth Proxy step to reach a real test instance, or deploy to a test Cloud Run service or GKE namespace and call it with a test suite.
• Use a build service account with just enough access to test resources; use separate test projects or data so tests never touch production.
• Make tests repeatable and idempotent: create unique resources per run, clean up in a final step, and tear down even on failure (use a cleanup approach that does not depend on earlier steps succeeding).
• A failing test step stops the build, so the image is never pushed or deployed. Gate promotion further with Cloud Deploy approvals and deployment verification (a post-deploy test container).
• Trigger tests on pull requests with a trigger on PRs so problems surface before merge; keep long end-to-end tests in a later pipeline stage.

Putting it together

A typical pipeline: developer commits, Cloud Build trigger fires, steps run unit tests, build the image, run integration tests, push to Artifact Registry, Artifact Analysis scans, provenance and attestations are created, Cloud Deploy releases to staging, tests verify, a manual approval promotes to production, and Binary Authorization admits the signed digest.