A few simple ideas before we meet the service.

Source code is not yet a product

Developers write source code, which is text that humans can read. A computer cannot simply run that text as a finished product. It usually has to be assembled: libraries are downloaded, the code is compiled into a form a machine understands, tests are run to check it works, and the result is packaged into something that can be installed or started. This whole process is called building.

Why building by hand goes wrong

If one developer builds on a laptop, the result depends on that laptop. A different version of a tool, a forgotten step or a leftover file can produce a different result on a colleague’s machine. This causes the classic problem of “it works on my computer.” Manual building is also slow, and people forget steps, especially under pressure.

Continuous integration and continuous delivery

Teams solve this with automation, often described by the letters CI and CD. Continuous integration means that every time someone adds code, an automated system immediately builds it and runs tests, so problems are found within minutes instead of weeks. Continuous delivery means the tested result is automatically prepared, and often deployed, to the places where it will run. Together they form a pipeline: a repeatable assembly line from a developer’s keyboard to a running application.

Google Cloud’s serverless service for continuous integration and delivery.

Cloud Build is a fully managed service that executes your builds on Google Cloud infrastructure. You describe the steps of your build, and Cloud Build runs them for you, on machines that it creates when needed and removes afterwards. There is no build server to buy, install, patch or keep alive. You pay for the time your builds actually run, and you can run many builds at the same time without queueing behind a single overloaded machine.

Cloud Build can import source code from several places, including repositories on popular hosting services and Google Cloud storage, run your steps in containers, and produce outputs such as container images, packages and deployable files. It then stores them in registries and can start deployments to services such as Cloud Run, Google Kubernetes Engine and others.

A short dictionary of Cloud Build words.

What happens between a developer saving code and a finished package.

sequenceDiagram
    participant Dev as Developer
    participant Repo as Source Repository
    participant CB as Cloud Build
    participant W as Worker
    participant AR as Artifact Registry
    participant RUN as Deployment Target
    Dev->>Repo: Push code change
    Repo->>CB: Event notification
    CB->>CB: Match trigger rules
    CB->>W: Start clean worker with source code
    W->>W: Run steps - install, test, package
    W->>AR: Push built image
    W->>RUN: Deploy new version
    CB-->>Dev: Report success or failure
        

The heart of every Cloud Build pipeline.

The build configuration is a file, kept with your code, that lists the steps. For each step you choose the builder container to use, the command to run and, optionally, settings such as environment variables, the working folder and which steps must finish first. By default steps run in order, but you can declare that some steps depend on others and let independent steps run at the same time, which shortens the total build.

Besides the steps, the file can list the artifacts the build should produce, set a timeout, choose a machine size, define substitutions, which are named placeholders you fill in at run time, and reference secrets. Because the file lives in your repository, changes to the pipeline are reviewed, versioned and reversible just like any other code. This idea is often called pipeline as code.

Three ways to describe a build

Because each step is a container, any tool that can run in a container can be part of your build.

Cloud Build provides official builders for common tasks, such as working with container images, the Google Cloud command-line tool, Git, and popular language toolchains. Community builders extend the list, and you can create your own builder simply by making a container image that contains the tools you need. This design makes Cloud Build very flexible: a single build might use a language compiler in step one, a security scanner in step two, a database migration tool in step three and a deployment tool in step four, each isolated in its own container.

Automation begins with events.

A trigger connects an event to a build. Most teams start with a push trigger, which runs whenever code is pushed to a chosen branch, and a pull request trigger, which runs when someone proposes a change, so tests run before the code is merged. Other triggers fire when a tag or release is created, when a message arrives on a messaging topic, when a webhook is called, or on a schedule.

Triggers can be narrowed with filters, such as only running when files in a certain folder change. This is valuable in repositories that hold many projects, where you do not want every change to rebuild everything. Triggers can also require approval, so that a person must confirm before a sensitive build, such as a production release, begins.

Connecting to your code

Cloud Build can build from repositories hosted on popular code hosting services through repository connections, and from files stored in Google Cloud storage. Availability of source providers evolves, and older Google-hosted source repositories have changed in availability for new users, so check the current documentation to choose the connection type that fits your setup.

flowchart TD
    E1[Push to branch] --> T[Cloud Build Trigger]
    E2[Pull request opened] --> T
    E3[Tag created] --> T
    E4[Schedule or webhook or message] --> T
    T --> F{Filters match? Branch, files changed}
    F -->|No| X[Ignore event]
    F -->|Yes| A{Approval required?}
    A -->|Yes| H[Wait for approver]
    A -->|No| B[Start build]
    H --> B
        

How Cloud Build fits with the rest of Google Cloud.

Cloud Build is usually one station in a longer line. A developer pushes code, Cloud Build builds and tests it, the resulting container image is stored in Artifact Registry, security checks scan and sign the image, and a delivery service rolls it out through test and production environments. Google Cloud Deploy is a managed service designed for the delivery half of the line, promoting a release from one environment to the next with approvals and rollbacks, while Cloud Build handles the build half.

flowchart LR
    DEV[Developer commits code] --> REPO[Source repository]
    REPO --> CB[Cloud Build: build and test]
    CB --> SCAN[Vulnerability scan and signing]
    SCAN --> AR[(Artifact Registry)]
    AR --> CD[Cloud Deploy or deployment step]
    CD --> TEST[Test environment]
    TEST --> APPROVE{Approved?}
    APPROVE -->|Yes| PROD[Production on Cloud Run or GKE]
    APPROVE -->|No| BACK[Fix and rebuild]
    BACK --> DEV
        

Default pool for simplicity, private pools for control.

The default pool

By default, builds run on a shared pool of workers that Google manages. It is simple, needs no setup and is suitable for most teams. You can choose from several machine sizes to give big builds more processors and memory. The default pool reaches the internet normally but cannot directly reach private resources inside your own virtual network.

Private pools

A private pool is a dedicated set of workers managed by Google but connected to your private network. This lets builds reach private resources such as an internal package server, a private database for integration tests or a private cluster, without exposing them to the internet. Private pools also offer more machine choices, options to disable public internet access for tighter security, and network controls that match strict company policies.

Fast builds mean faster feedback and happier developers.

The build system touches your most valuable asset, your code, so it must be guarded carefully.

Who the build runs as

Every build runs using a service account, which is an identity for software. That account’s permissions decide what the build is allowed to do, such as push images or deploy to a service. Use a dedicated, user-managed service account for each pipeline with only the permissions it needs, rather than relying on a broadly powerful default account. This follows the principle of least privilege and limits damage if a build is ever compromised.

Handling secrets

Builds often need passwords, tokens or keys. Never place them in source code or plain configuration files. Store them in Secret Manager, grant the build identity permission to read only the secrets it needs, and let Cloud Build supply them to specific steps at run time.

Trusted images and provenance

Supply chain attacks try to slip malicious code into software during the build. Cloud Build can generate provenance, a signed record describing how and from what an artifact was built, which supports frameworks such as SLSA. Vulnerability scanning of images in the registry, plus signing and policy enforcement with Binary Authorization, lets you require that only images built by your trusted pipeline are allowed to run. Check the current documentation for the exact provenance levels and features available.

Network and access protection

Use private pools for builds that need to reach private resources or must not touch the public internet. Restrict who can edit build configurations and triggers, since changing a pipeline is as powerful as changing production code. Require reviews for changes to build files and approvals for production releases.

flowchart TD
    A[Reviewed code and build files in version control] --> B[Dedicated least-privilege build service account]
    B --> C[Secrets from Secret Manager, never in code]
    C --> D[Private pool for sensitive builds]
    D --> E[Vulnerability scanning and provenance records]
    E --> F[Signing and Binary Authorization policy]
    F --> G[Audit logs and approvals for production]
        

When a build fails, you need to know why quickly.

Every build records its status, step-by-step timing and complete logs. Logs can be viewed in the console, streamed to Cloud Logging for searching and alerting, and stored in Cloud Storage for longer retention. You can send notifications about build results to messaging or chat tools, so a failed build is noticed in minutes rather than hours.

You pay for build time, so efficient builds cost less.

Cloud Build charges mainly by the minutes your builds run, with different rates for different machine sizes, and Google has offered a monthly allowance of free build minutes on the default machine type. Private pools are priced differently from the default pool. You also pay for related services: storage for images and logs, network traffic out of Google Cloud and the services your steps call. Prices and free allowances change, so always check Google Cloud’s pricing page and calculator.

Choosing the right tool for your team.

Where Cloud Build earns its keep.

A balanced view.

Lessons from teams who ship every day.

Best practices at a glance

Anti-patterns to avoid

No. Its steps run in containers, but they can build and test many kinds of software, such as web applications, libraries and infrastructure definitions, and produce packages or files as well as container images.

No. Cloud Build is serverless. Workers are created for each build and removed afterwards. Even private pools are managed by Google, though you plan their networking.

Through triggers. They watch for events such as code pushes, pull requests, tags, messages, webhooks or schedules, and start builds when the rules match. You can also start builds manually.

Usually in a build configuration file inside your repository, so it is versioned and reviewed with the code. You can also build from a container recipe file or use buildpacks for simpler cases.

Store them in Secret Manager and give the build’s service account permission to read only what it needs. Pass them to specific steps at run time, and never put them in code or logs.

A private pool is a dedicated set of build workers connected to your private network. Use it when builds must reach private resources or must not use the public internet, or when you need larger machines.

Cache dependencies and image layers, run independent steps in parallel, keep images small, build only what changed using trigger filters, and use an appropriately sized machine.

Add deployment steps to the build, or hand the built artifact to a delivery service such as Cloud Deploy that promotes it through environments with approvals and rollbacks.

Yes. Triggers can require manual approval, which is useful for production releases and other sensitive builds.

Jenkins is a server you install and maintain, with a huge plugin ecosystem. Cloud Build is a managed service with no servers to maintain, deeply integrated with Google Cloud. Teams choose based on customization needs, operations effort and where their software runs.

Cloud Build brings reliable, repeatable automation to the journey from source code to running software. You describe your pipeline once as a recipe of container-based steps, attach triggers so builds start on their own, and let Google run the machines. Used well, it gives fast feedback, consistent artifacts and a clear record of every build. The best results come from simple habits: keep pipelines as code, build once and promote the same artifact, use least-privilege identities and Secret Manager, speed builds with caching and parallel steps, add scanning, provenance and approvals, and keep an eye on duration, failures and cost. Treat the pipeline as a real product that serves your developers, and it will quietly help them ship better software every day.