Professional Cloud Developer

Setting up your development environment

A well-configured development environment is the foundation for building applications on Google Cloud. You begin by installing the Google Cloud SDK, which gives you the gcloud command-line tool for managing resources and the gsutil tool for working with Cloud Storage. The SDK also includes client libraries for popular programming languages so your code can call Cloud APIs directly. You authenticate your local environment using a service account key or by logging in with your Google account, and you set a default project so every command knows where to operate.

Beyond the command line, you typically use Cloud Shell, a browser-based terminal that comes with the SDK pre-installed and your project already authenticated. Cloud Shell includes a code editor and provides temporary compute resources, which makes it useful for quick experiments without configuring a local machine. For local development, you can also use Cloud Code, a set of IDE plugins for Visual Studio Code and JetBrains that adds templates, debugging, and a local emulator for services like Cloud Run and Cloud Functions. The emulator lets you test event-driven code without deploying to the cloud, which speeds up the feedback loop.

Building

Building an application on Google Cloud means compiling source code, packaging it, and producing an artifact that can run in a target environment. The build process typically starts from a source repository such as Cloud Source Repositories, GitHub, or GitLab. Cloud Build is the managed service that reads a configuration file (usually cloudbuild.yaml) and executes a series of steps. Each step runs inside a container, and you can define custom build steps using any publicly available image. Cloud Build pulls the source, runs tests, compiles the code, and pushes the resulting artifact to Artifact Registry or Container Registry.

The artifact type depends on where the application will run. For Cloud Run or Google Kubernetes Engine (GKE), the artifact is a container image stored in Artifact Registry. For Compute Engine, the artifact might be a packaged application or a custom machine image. Cloud Build can also deploy the artifact directly after building it, so the pipeline moves from source to deployment in one workflow. You control the build environment by specifying machine type, timeout, and the number of parallel steps. Build triggers automate this process: when a developer pushes code to a branch or creates a pull request, Cloud Build starts a new build automatically, which enforces consistent quality gates before code reaches production.

Testing

Testing on Google Cloud covers unit tests, integration tests, and end-to-end tests, and the environment you choose depends on what you are verifying. For unit tests that do not depend on cloud services, you run them inside your CI pipeline using Cloud Build or your own CI tool. For integration tests that need real Google Cloud services, you can use Cloud Tasks, Pub/Sub, or Cloud Storage emulators that run locally, or you can provision a temporary project that you tear down after the test run. Cloud Build supports running tests in parallel across multiple containers, which reduces the total test time.

For applications that use Cloud Functions or Cloud Run, you write tests that invoke the function or service endpoint and verify the response. The Cloud Functions Framework provides a local server that mimics the production environment, so you can send HTTP requests to your function and inspect the output. For event-driven functions, you simulate the event payload and confirm that the function handles it correctly. Cloud Build can also run Selenium or other browser-based tests inside a container to validate the front end. After tests pass, Cloud Build can fail the build if coverage drops below a threshold you set in the configuration file, which enforces a minimum quality bar before the artifact is promoted.