Cloud Build for CI/CD in GCP - Step-by-Step Execution

Process Flow - Cloud Build for CI/CD

Code Commit to Repo

↓

Trigger Cloud Build

↓

Cloud Build Executes Steps

↓

Build, Test, Deploy

↓

Notify Success/Failure

↓

Code Deployed to Environment

Code is pushed to a repository, which triggers Cloud Build to run build, test, and deploy steps automatically, then notifies the result.

Execution Sample

GCP

steps:
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'gcr.io/my-project/my-app', '.']
- name: 'gcr.io/cloud-builders/docker'
  args: ['push', 'gcr.io/my-project/my-app']
images:
- 'gcr.io/my-project/my-app'

This Cloud Build config builds a Docker image and pushes it to Google Container Registry.

Process Table

Step	Action	Command/Args	Result	Status
1	Start Build	Trigger received from repo commit	Build started	Success
2	Build Docker Image	docker build -t gcr.io/my-project/my-app .	Image built locally	Success
3	Push Docker Image	docker push gcr.io/my-project/my-app	Image pushed to registry	Success
4	Publish Image	images: gcr.io/my-project/my-app	Image available for deploy	Success
5	Build Complete	All steps finished	Build finished successfully	Success

💡 All build steps completed successfully, image ready for deployment

Status Tracker

Variable	Start	After Step 2	After Step 3	Final
Build Status	Not started	Image built	Image pushed	Success
Docker Image	None	Built locally	Pushed to registry	Available
Trigger	No	Yes	Yes	Yes

Key Moments - 3 Insights

Why does Cloud Build start automatically after code commit?

Because a trigger is set up to listen to repository changes, as shown in Step 1 of the execution_table.

What happens if the docker build fails?

The build stops immediately and reports failure; subsequent steps like push won't run, which is why each step's status is important.

Why do we push the image after building it?

Pushing uploads the image to a registry so deployment systems can access it, as shown in Step 3 and Step 4.

Visual Quiz - 3 Questions

Look at the execution_table, what is the status after Step 2?

A Success

B Failure

C Pending

D Skipped

💡 Hint

Check the 'Status' column for Step 2 in the execution_table.

At which step is the Docker image pushed to the registry?

A Step 1

B Step 2

C Step 3

D Step 4

💡 Hint

Look at the 'Action' and 'Command/Args' columns in the execution_table.

If the trigger was not set, what would happen?

A Build would start automatically

B Build would not start after commit

C Build would fail at Step 2

D Image would not be pushed

💡 Hint

Refer to the 'Trigger' variable in variable_tracker and Step 1 in execution_table.

Concept Snapshot

Cloud Build automates CI/CD by running build steps on code commits.
Use triggers to start builds automatically.
Define steps in cloudbuild.yaml (build, test, deploy).
Images are built and pushed to registries.
Build status shows success or failure of each step.

Full Transcript

Cloud Build for CI/CD works by triggering a build when code is committed to a repository. The build runs defined steps such as building a Docker image and pushing it to a container registry. Each step's status is tracked to ensure success. If any step fails, the build stops. This automation helps deploy code changes quickly and reliably.

Practice

1. What is the primary purpose of Google Cloud Build in a CI/CD pipeline?

easy

A. To store large amounts of data

B. To automate building, testing, and deploying code

C. To monitor network traffic

D. To manage user permissions

Solution

1. Step 1: Understand Cloud Build's role

   Cloud Build automates the process of building, testing, and deploying code, which is essential in CI/CD pipelines.

2. Step 2: Eliminate unrelated options

   Storing data, monitoring network traffic, and managing permissions are not primary functions of Cloud Build.

3. Final Answer:

   To automate building, testing, and deploying code -> Option B

4. Quick Check:

   Cloud Build = Automate build/test/deploy [OK]

Hint: Remember: Cloud Build automates code delivery steps [OK]

Common Mistakes:

• Confusing Cloud Build with storage services
• Thinking Cloud Build manages network or permissions
• Assuming Cloud Build only builds code without testing or deploying

2. Which of the following is the correct way to specify a build step in a Cloud Build YAML file?

easy

A. actions:
- image: 'docker'
run: ['build', '-t', 'image', '.']

B. build_steps:
- container: 'gcr.io/cloud-builders/docker'
commands: ['build', '-t', 'image', '.']

C. steps:
- name: 'gcr.io/cloud-builders/docker'
args: ['build', '-t', 'gcr.io/my-project/my-image', '.']

D. commands:
- use: 'docker'
execute: ['build', '-t', 'image', '.']

Solution

1. Step 1: Review Cloud Build YAML syntax

   The correct key for build steps is 'steps', and each step uses 'name' for the builder image and 'args' for commands.

2. Step 2: Compare options to syntax

   steps: - name: 'gcr.io/cloud-builders/docker' args: ['build', '-t', 'gcr.io/my-project/my-image', '.'] matches the correct syntax. Other options use incorrect keys like 'build_steps', 'actions', or 'commands'.

3. Final Answer:

   steps: - name: 'gcr.io/cloud-builders/docker' args: ['build', '-t', 'gcr.io/my-project/my-image', '.'] -> Option C

4. Quick Check:

   Use 'steps' with 'name' and 'args' in Cloud Build YAML [OK]

Hint: Look for 'steps' with 'name' and 'args' keys in YAML [OK]

Common Mistakes:

• Using wrong keys like 'build_steps' or 'actions'
• Confusing 'args' with 'commands'
• Omitting the builder image name

3. Given this Cloud Build YAML snippet, what will be the output of the build step?

steps:
- name: 'ubuntu'
  args: ['echo', 'Hello, Cloud Build!']

medium

A. Build fails due to missing Docker image

B. Syntax error in YAML file

C. No output is produced

D. Hello, Cloud Build!

Solution

1. Step 1: Analyze the build step

   The step uses the 'ubuntu' image and runs the command 'echo Hello, Cloud Build!'. This command prints the message to the output.

2. Step 2: Determine expected output

   Since 'echo' prints text, the output will be 'Hello, Cloud Build!'. There is no syntax error or missing image because 'ubuntu' is a valid public image.

3. Final Answer:

   Hello, Cloud Build! -> Option D

4. Quick Check:

   Echo command prints text output [OK]

Hint: Echo commands print their arguments as output [OK]

Common Mistakes:

• Assuming build fails due to image name
• Thinking no output is produced by echo
• Confusing YAML syntax errors with valid syntax

4. You wrote this Cloud Build YAML but the build fails immediately. What is the error?

steps:
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'gcr.io/my-project/my-image']

medium

A. Missing the build context (dot) at the end of args

B. Incorrect builder image name

C. YAML indentation error

D. args should be a string, not a list

Solution

1. Step 1: Check Docker build command syntax

   The Docker build command requires a build context, usually '.' at the end, to specify where to find the Dockerfile.

2. Step 2: Identify missing argument

   The args list misses the '.' context argument, causing the build to fail immediately.

3. Final Answer:

   Missing the build context (dot) at the end of args -> Option A

4. Quick Check:

   Docker build needs context path '.' [OK]

Hint: Always end docker build args with '.' for context [OK]

Common Mistakes:

• Assuming image name is wrong
• Thinking YAML indentation is the issue
• Using string instead of list for args

5. You want to create a Cloud Build pipeline that builds a Docker image, runs tests, and then deploys only if tests pass. Which YAML structure correctly represents this workflow?

hard

A. steps:
- name: 'gcr.io/cloud-builders/docker'
args: ['build', '-t', 'gcr.io/my-project/my-image', '.']
- name: 'gcr.io/cloud-builders/docker'
args: ['run', 'my-image', 'test']
waitFor: ['-']
- name: 'gcr.io/cloud-builders/gcloud'
args: ['app', 'deploy']
waitFor: ['-']

B. steps:
- name: 'gcr.io/cloud-builders/docker'
args: ['build', '-t', 'gcr.io/my-project/my-image', '.']
waitFor: ['-']
- name: 'gcr.io/cloud-builders/docker'
args: ['run', 'my-image', 'test']
waitFor: ['-']
- name: 'gcr.io/cloud-builders/gcloud'
args: ['app', 'deploy']

C. steps:
- name: 'gcr.io/cloud-builders/docker'
args: ['build', '-t', 'gcr.io/my-project/my-image', '.']
- name: 'gcr.io/cloud-builders/docker'
args: ['run', 'my-image', 'test']
- name: 'gcr.io/cloud-builders/gcloud'
args: ['app', 'deploy']

D. steps:
- name: 'gcr.io/cloud-builders/docker'
args: ['build', '-t', 'gcr.io/my-project/my-image', '.']
- name: 'gcr.io/cloud-builders/docker'
args: ['run', 'my-image', 'test']
- name: 'gcr.io/cloud-builders/gcloud'
args: ['app', 'deploy']
waitFor: ['-']

Solution

1. Step 1: Understand step dependencies in Cloud Build

   Cloud Build starts steps in parallel by default. Use 'waitFor: ["-"]' to make a step wait for all previous steps to succeed.

2. Step 2: Analyze options for correct workflow

   steps: - name: 'gcr.io/cloud-builders/docker' args: ['build', '-t', 'gcr.io/my-project/my-image', '.'] - name: 'gcr.io/cloud-builders/docker' args: ['run', 'my-image', 'test'] waitFor: ['-'] - name: 'gcr.io/cloud-builders/gcloud' args: ['app', 'deploy'] waitFor: ['-'] in steps: - name: 'gcr.io/cloud-builders/docker' args: ['build', '-t', 'gcr.io/my-project/my-image', '.'] - name: 'gcr.io/cloud-builders/docker' args: ['run', 'my-image', 'test'] waitFor: ['-'] - name: 'gcr.io/cloud-builders/gcloud' args: ['app', 'deploy'] waitFor: ['-'] ensures tests wait for build, and deploy waits for both.

3. Final Answer:

   steps: - name: 'gcr.io/cloud-builders/docker' args: ['build', '-t', 'gcr.io/my-project/my-image', '.'] - name: 'gcr.io/cloud-builders/docker' args: ['run', 'my-image', 'test'] waitFor: ['-'] - name: 'gcr.io/cloud-builders/gcloud' args: ['app', 'deploy'] waitFor: ['-'] -> Option A

4. Quick Check:

   waitFor ['-'] on test and deploy enforces build -> test -> deploy [OK]

Hint: Use waitFor: ['-'] on test and deploy steps for sequential workflow [OK]

Common Mistakes:

• Adding 'waitFor' incorrectly on all steps
• Omitting 'waitFor' causing deploy to run too early
• Misplacing 'waitFor' inside wrong steps