Create the lab resources

Vérifier ma progression

/ 20

Create the Cloud Build Triggers

Vérifier ma progression

/ 20

Deploy the first versions of the application

Vérifier ma progression

/ 20

Deploy the second versions of the application

Vérifier ma progression

/ 20

Roll back the production deployment

Vérifier ma progression

/ 20

Cet atelier peut intégrer des outils d'IA pour vous accompagner dans votre apprentissage.
Ce contenu n'est pas encore optimisé pour les appareils mobiles.
Pour une expérience optimale, veuillez accéder à notre site sur un ordinateur de bureau en utilisant un lien envoyé par e-mail.

GSP330

Google Cloud self-paced labs

Overview

In a challenge lab you’re given a scenario and a set of tasks. Instead of following step-by-step instructions, you will use the skills learned from the labs in the course to figure out how to complete the tasks on your own! An automated scoring system (shown on this page) will provide feedback on whether you have completed your tasks correctly.

When you take a challenge lab, you will not be taught new Google Cloud concepts. You are expected to extend your learned skills, like changing default values and reading and researching error messages to fix your own mistakes.

To score 100% you must successfully complete all tasks within the time period!

This lab is recommended for students enrolled in the Implement DevOps Workflows in Google Cloud course. Are you ready for the challenge?

Before you click the Start Lab button

Read these instructions. Labs are timed and you cannot pause them. The timer, which starts when you click Start Lab, shows how long Google Cloud resources are made available to you.

This hands-on lab lets you do the lab activities in a real cloud environment, not in a simulation or demo environment. It does so by giving you new, temporary credentials you use to sign in and access Google Cloud for the duration of the lab.

To complete this lab, you need:

  • Access to a standard internet browser (Chrome browser recommended).
Note: Use an Incognito (recommended) or private browser window to run this lab. This prevents conflicts between your personal account and the student account, which may cause extra charges incurred to your personal account.
  • Time to complete the lab—remember, once you start, you cannot pause a lab.
Note: Use only the student account for this lab. If you use a different Google Cloud account, you may incur charges to that account.

Challenge scenario

As a recent hire as a DevOps Engineer for Cymbal Superstore a few months ago, you have learned the ins and outs of how the company operates its e-commerce website. Specifically, the DevOps team is working on a large scale CI/CD pipeline that they would like your assistance with building. This allows the company to help developers automate tasks, collaborate more effectively with other teams, and release software more frequently and reliably. Your experience with Git, Artifact Registry, Docker, and Cloud Build is going to be a large help since Cymbal Superstore would like to use native Google Cloud Services and modern DevOps practices for their pipeline.

cymbal superstore logo

Before you start this project, the DevOps team would like you to demonstrate your new skills. As part of this demonstration, they have a list of tasks they would like to see you do in an allotted period of time in a sandbox environment.

Your challenge

Your tasks include the following:

  • Creating a GKE cluster based on a set of configurations provided.
  • Initializing a Git repository on the dedicated Git server to host your Go application code.
  • Creating Cloud Build Triggers that deploy a production and development application.
  • Pushing updates to the app and creating new builds.
  • Rolling back the production application to a previous version.

Overall, you are creating a simple CI/CD pipeline using a Git repository on a dedicated Git server, Artifact Registry, and Cloud Build.

Task 1. Create the lab resources

In this section, you initialize your Google Cloud project for the demo environment. You obtain environment variables, enable the required APIs, configure Git in Cloud Shell, create an Artifact Registry Docker repository, and create a GKE cluster to run your production and development applications on.

  1. In Cloud Shell, run the following command to set your project ID, region, and Git server IP:
export PROJECT_ID=$(gcloud config get-value project) export PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID --format='value(projectNumber)') export REGION={{{ project_0.default_region }}} export ZONE={{{ project_0.default_zone }}} gcloud config set compute/region $REGION gcloud config set compute/zone $ZONE export GIT_SERVER_IP=$(gcloud compute instances describe git-server --zone=$ZONE --format='get(networkInterfaces[0].accessConfigs[0].natIP)') echo "Git Server IP is: ${GIT_SERVER_IP}"
  1. Run the following command to enable the APIs for GKE and Cloud Build:
gcloud services enable container.googleapis.com \ cloudbuild.googleapis.com
  1. Add the Kubernetes Developer role for the Cloud Build service account:
export PROJECT_ID=$(gcloud config get-value project) gcloud projects add-iam-policy-binding $PROJECT_ID \ --member=serviceAccount:$(gcloud projects describe $PROJECT_ID \ --format="value(projectNumber)")@cloudbuild.gserviceaccount.com --role="roles/container.developer"
  1. In Cloud Shell, configure Git with your user name and email:
git config --global user.name "Student" git config --global user.email "student@qwiklabs.net"
  1. Create an Artifact Registry Docker repository named my-repository in the region to store your container images.

  2. Create a GKE Standard cluster named hello-cluster with the following configuration:

Setting Value
Zone
Release channel Regular
Cluster version 1.29 or newer
Cluster autoscaler Enabled
Number of nodes 3
Minimum nodes 2
Maximum nodes 6
  1. Create the prod and dev namespaces on your cluster.

Click Check my progress to verify the objective. Create the lab resources

Task 2. Connect to the Git repository on the Git server

In this task, you initialize the repository sample-app on your dedicated Git server (git-server) and push the initial sample code. This repository holds your Go application code and is the primary source for builds.

  1. Use the following command to copy the sample code into your sample-app directory:
cd ~ gcloud storage cp -r gs://spls/gsp330/sample-app/* sample-app
  1. Run the following command, which will automatically replace the <your-region> and <your-zone> placeholders with the assigned region and zone of your project, and initialize the container image version to v1.0 in the cloudbuild-dev.yaml and cloudbuild.yaml files:
export REGION="{{{project_0.default_region | REGION}}}" export ZONE="{{{project_0.default_zone | ZONE}}}" for file in sample-app/cloudbuild-dev.yaml sample-app/cloudbuild.yaml; do sed -i "s//${REGION}/g" "$file" sed -i "s//${ZONE}/g" "$file" sed -i "s//v1.0/g" "$file" done
  1. Initialize the Git repository in the sample-app directory, make your first commit with the sample code, and push the changes to the master branch of your Git server:
cd ~/sample-app git init git remote add origin http://${GIT_SERVER_IP}:3000/giteaadmin/sample-app.git git branch -m master git add . && git commit -m "initial commit" git push -u http://giteaadmin:GiteaPassword123@${GIT_SERVER_IP}:3000/giteaadmin/sample-app.git master
  1. Create a branch named dev, make a commit with the sample code added to your sample-app directory, and push the changes to the dev branch:
cd ~/sample-app git checkout -b dev git push -u http://giteaadmin:GiteaPassword123@${GIT_SERVER_IP}:3000/giteaadmin/sample-app.git dev
  1. Verify you have the sample code and branches stored in the Git repository.

The code you just cloned contains a simple Go application that has two entry points: Red and Blue. Each displays a simple colored square on the web page depending on the entry point you go to.

Task 3. Create the Cloud Build Triggers

In this section, you create two Cloud Build Triggers.

  • The first trigger named sample-app-prod-deploy builds your application container image using the cloudbuild.yaml configuration file and deploys it to the prod namespace in your GKE cluster.

  • The second trigger named sample-app-dev-deploy builds your application container image using the cloudbuild-dev.yaml configuration file and deploys it to the dev namespace in your GKE cluster.

  1. Create a Cloud Build Trigger named sample-app-prod-deploy:
gcloud builds triggers create manual \ --name="sample-app-prod-deploy" \ --inline-config="cloudbuild.yaml" \ --service-account="projects/${PROJECT_ID}/serviceAccounts/${PROJECT_NUMBER}-compute@developer.gserviceaccount.com" \ --region={{{ project_0.default_region }}}
  1. Create a Cloud Build Trigger named sample-app-dev-deploy:
gcloud builds triggers create manual \ --name="sample-app-dev-deploy" \ --inline-config="cloudbuild-dev.yaml" \ --service-account="projects/${PROJECT_ID}/serviceAccounts/${PROJECT_NUMBER}-compute@developer.gserviceaccount.com" \ --region={{{ project_0.default_region }}}

After setting up the triggers, you can run the corresponding Cloud Build pipeline, which builds and deploys the application as specified in the cloudbuild.yaml and cloudbuild-dev.yaml files.

Click Check my progress to verify the objective. Create the Cloud Build Triggers

Task 4. Deploy the first versions of the application

In this section, you build the first version of the production application and the development application.

Build the first development deployment

  1. In Cloud Shell, inspect the cloudbuild-dev.yaml file located in the sample-app directory to see the steps in the build process, and confirm that the image version is set to v1.0.

  2. Navigate to the dev/deployment.yaml file and update the <todo> on line 17 with the correct container image name. Also, replace the PROJECT_ID variable with actual project ID in the container image name.

Note: Make sure you have same container image name in dev/deployment.yaml and cloudbuild-dev.yaml file.
  1. Make a commit with your changes on the dev branch and push changes to the Git server:
cd ~/sample-app git checkout dev git add . git commit -m "Deploy v1.0 on dev" git push http://giteaadmin:GiteaPassword123@${GIT_SERVER_IP}:3000/giteaadmin/sample-app.git dev
  1. Run the sample-app-dev-deploy build job:
cd ~/sample-app gcloud builds submit --config=cloudbuild-dev.yaml .
  1. Verify your build executed successfully in Cloud Build History page, and verify the development-deployment application was deployed onto the dev namespace of the cluster.

  2. Expose the development-deployment deployment to a LoadBalancer service named dev-deployment-service on port 8080, and set the target port of the container to the one specified in the Dockerfile.

  3. Navigate to the Load Balancer IP of the service and add the /blue entry point at the end of the URL (or run curl -I http://${DEV_LB_IP}:8080/blue in Cloud Shell) to verify the application is up and running with a 200 OK response. It should resemble something like the following: http://34.135.97.199:8080/blue.

Build the first production deployment

  1. Switch to the master branch. Inspect the cloudbuild.yaml file located in the sample-app directory to see the steps in the build process, and confirm that the image version is set to v1.0.

  2. Navigate to the prod/deployment.yaml file and update the <todo> on line 17 with the correct container image name. Also, replace the PROJECT_ID variable with actual project ID in the container image name.

Note: Make sure you have same container image name in prod/deployment.yaml and cloudbuild.yaml file.
  1. Make a commit with your changes on the master branch and push changes to the Git server:
cd ~/sample-app git checkout master git add . git commit -m "Deploy v1.0 on master" git push http://giteaadmin:GiteaPassword123@${GIT_SERVER_IP}:3000/giteaadmin/sample-app.git master
  1. Run the sample-app-prod-deploy build job:
cd ~/sample-app gcloud builds submit --config=cloudbuild.yaml .
  1. Verify your build executed successfully in Cloud Build History page, and verify the production-deployment application was deployed onto the prod namespace of the cluster.

  2. Expose the production-deployment deployment on the prod namespace to a LoadBalancer service named prod-deployment-service on port 8080, and set the target port of the container to the one specified in the Dockerfile.

  3. Navigate to the Load Balancer IP of the service and add the /blue entry point at the end of the URL (or run curl -I http://${PROD_LB_IP}:8080/blue in Cloud Shell) to verify the application is up and running with a 200 OK response. It should resemble something like the following: http://34.135.245.19:8080/blue.

Click Check my progress to verify the objective. Deploy the first versions of the application

Task 5. Deploy the second versions of the application

In this section, you build the second version of the production application and the development application.

Build the second development deployment

  1. Switch back to the dev branch.
Note: Before proceeding, make sure you are on dev branch to create deployment for dev environment.
  1. In the main.go file, update the main() function to the following:
func main() { http.HandleFunc("/blue", blueHandler) http.HandleFunc("/red", redHandler) http.ListenAndServe(":8080", nil) }
  1. Add the following function inside of the main.go file:
func redHandler(w http.ResponseWriter, r *http.Request) { img := image.NewRGBA(image.Rect(0, 0, 100, 100)) draw.Draw(img, img.Bounds(), &image.Uniform{color.RGBA{255, 0, 0, 255}}, image.ZP, draw.Src) w.Header().Set("Content-Type", "image/png") png.Encode(w, img) }
  1. Inspect the cloudbuild-dev.yaml file to see the steps in the build process. Update the version of the Docker image to v2.0.

  2. Navigate to the dev/deployment.yaml file and update the container image name to the new version (v2.0).

  3. Make a commit with your changes on the dev branch and push changes to the Git server:

cd ~/sample-app git checkout dev git add . git commit -m "Deploy v2.0 on dev" git push http://giteaadmin:GiteaPassword123@${GIT_SERVER_IP}:3000/giteaadmin/sample-app.git dev
  1. Run the sample-app-dev-deploy build job:
cd ~/sample-app gcloud builds submit --config=cloudbuild-dev.yaml .
  1. Verify your build executed successfully in Cloud Build History page, and verify the development-deployment application was deployed onto the dev namespace of the cluster and is using the v2.0 image.

  2. Navigate to the Load Balancer IP of the service and add the /red entry point at the end of the URL (or run curl -I http://${DEV_LB_IP}:8080/red in Cloud Shell) to verify the application is up and running with a 200 OK response. It should resemble something like the following: http://34.135.97.199:8080/red.

Note: It may take a couple of minutes for the updates to propagate to your load balancer.

Build the second production deployment

  1. Switch to the master branch.
Note: Before proceeding, make sure you are on master branch to create deployment for master environment.
  1. In the main.go file, update the main() function to the following:
func main() { http.HandleFunc("/blue", blueHandler) http.HandleFunc("/red", redHandler) http.ListenAndServe(":8080", nil) }
  1. Add the following function inside of the main.go file:
func redHandler(w http.ResponseWriter, r *http.Request) { img := image.NewRGBA(image.Rect(0, 0, 100, 100)) draw.Draw(img, img.Bounds(), &image.Uniform{color.RGBA{255, 0, 0, 255}}, image.ZP, draw.Src) w.Header().Set("Content-Type", "image/png") png.Encode(w, img) }
  1. Inspect the cloudbuild.yaml file to see the steps in the build process. Update the version of the Docker image to v2.0.

  2. Navigate to the prod/deployment.yaml file and update the container image name to the new version (v2.0).

  3. Make a commit with your changes on the master branch and push changes to the Git server:

cd ~/sample-app git checkout master git add . git commit -m "Deploy v2.0 on master" git push http://giteaadmin:GiteaPassword123@${GIT_SERVER_IP}:3000/giteaadmin/sample-app.git master
  1. Run the sample-app-prod-deploy build job:
cd ~/sample-app gcloud builds submit --config=cloudbuild.yaml .
  1. Verify your build executed successfully in Cloud Build History page, and verify the production-deployment application was deployed onto the prod namespace of the cluster and is using the v2.0 image.

  2. Navigate to the Load Balancer IP of the service and add the /red entry point at the end of the URL (or run curl -I http://${PROD_LB_IP}:8080/red in Cloud Shell) to verify the application is up and running with a 200 OK response. It should resemble something like the following: http://34.135.245.19:8080/red.

Note: It may take a couple of minutes for the updates to propagate to your load balancer.

Great! You have successfully created fully functioning production and development CI/CD pipelines.

Click Check my progress to verify the objective. Deploy the second versions of the application

Task 6. Roll back the production deployment

In this section, you roll back the production deployment to a previous version.

  1. Roll back the production-deployment to use the v1.0 version of the application.
Hint: Using Cloud Build history, you can easily rollback/rebuild the deployments with the previous versions.
  1. Navigate to the Load Balancer IP of the service and add the /red entry point at the end of the URL of the production deployment (or run curl -I http://${PROD_LB_IP}:8080/red in Cloud Shell) and the response should be 404 Not Found.

Click Check my progress to verify the objective. Roll back the production deployment

Congratulations!

Congratulations! In this lab you verified your skills on implementing DevOps workflows in Google Cloud. You first created a GKE cluster to run your application and a Git repository on your dedicated Git server to host your code base. You then created Cloud Build Triggers, modified the code and the templates, and pushed updates to the repo that created your first development and production application builds. You then pushed updates to the application to create new builds, and rolled back the production application to a previous version. You are now ready to start DevOps work in your own environment!

Implement Devops Workflows skill badge

Earn your next skill badge

This self-paced lab is part of the Implement DevOps Workflows in Google Cloud course. Completing this skill badge course earns you the badge above, to recognize your achievement. Share your badge on your resume and social platforms, and announce your accomplishment using #GoogleCloudBadge.

This skill badge is part of Google Cloud’s Cloud Devops Engineer learning path. Continue your learning journey by enrolling in the Monitor and Log with Google Cloud Observability course.

Google Cloud training and certification

...helps you make the most of Google Cloud technologies. Our classes include technical skills and best practices to help you get up to speed quickly and continue your learning journey. We offer fundamental to advanced level training, with on-demand, live, and virtual options to suit your busy schedule. Certifications help you validate and prove your skill and expertise in Google Cloud technologies.

Manual Last Updated September 3, 2026

Lab Last Tested September 3, 2026

Copyright 2026 Google LLC. All rights reserved. Google and the Google logo are trademarks of Google LLC. All other company and product names may be trademarks of the respective companies with which they are associated.

Avant de commencer

  1. Les ateliers créent un projet Google Cloud et des ressources pour une durée déterminée.
  2. Les ateliers doivent être effectués dans le délai imparti et ne peuvent pas être mis en pause. Si vous quittez l'atelier, vous devrez le recommencer depuis le début.
  3. En haut à gauche de l'écran, cliquez sur Démarrer l'atelier pour commencer.

Utilisez la navigation privée

  1. Copiez le nom d'utilisateur et le mot de passe fournis pour l'atelier
  2. Cliquez sur Ouvrir la console en navigation privée

Connectez-vous à la console

  1. Connectez-vous à l'aide des identifiants qui vous ont été attribués pour l'atelier. L'utilisation d'autres identifiants peut entraîner des erreurs ou des frais.
  2. Acceptez les conditions d'utilisation et ignorez la page concernant les ressources de récupération des données.
  3. Ne cliquez pas sur Terminer l'atelier, à moins que vous n'ayez terminé l'atelier ou que vous ne vouliez le recommencer, car cela effacera votre travail et supprimera le projet.

Ce contenu n'est pas disponible pour le moment

Nous pouvons vous prévenir par e-mail lorsqu'il sera disponible

Parfait !

Nous pouvons vous contacter par e-mail s'il devient disponible

Un atelier à la fois

Confirmez pour mettre fin à tous les ateliers existants et démarrer celui-ci

Utilisez la navigation privée pour effectuer l'atelier

Le meilleur moyen d'exécuter cet atelier consiste à utiliser une fenêtre de navigation privée. Vous éviterez ainsi les conflits entre votre compte personnel et le compte temporaire de participant, qui pourraient entraîner des frais supplémentaires facturés sur votre compte personnel.