CI/CD pipeline for developing and delivering containerized apps
Stay organized with collections
Save and categorize content based on your preferences.
Last reviewed 2022-11-18 UTC
This document describes an integrated set of Google Cloud tools
to set up a system for development, for continuous integration (CI), and
for continuous delivery (CD) that you can use to develop and deploy applications to
Google Kubernetes Engine (GKE).
This reference architecture document is intended for both software developers
and operators. It assumes that you're familiar with running gcloud commands on
Google Cloud and with deploying application containers to
GKE.
Architecture
The following diagram shows the resources that are used in this architecture:
This architecture includes the following components:
Cloud Code as a development workspace.
As part of this workspace, you can see changes in the development
cluster, which runs on
minikube.
You run Cloud Code and the minikube cluster in
Cloud Shell.
Cloud Shell is an online development environment accessible from
your browser. It has compute resources, memory, an integrated development environment,
(IDE), and it also has Cloud Code installed.
Cloud Build to build and test the application—the "CI"
part of the pipeline
This part of the pipeline includes the following actions:
Cloud Build monitors changes to the source repository,
using a Cloud Build trigger.
When a change is committed into the main branch, the
Cloud Build trigger does the following:
Rebuilds the application container.
Places build artifacts in a Cloud Storage bucket.
Places the application container in Artifact Registry.
Runs tests on the container.
Calls Cloud Deploy to deploy the container to the
staging environment. In this example,
the staging environment is a Google Kubernetes Engine cluster.
If the build and tests are successful, you can then use
Cloud Deploy to promote the container from staging to
production.
Cloud Deploy to manage the deployment—the "CD" part of the
pipeline. In this part of the pipeline, Cloud Deploy does the
following:
Registers a
delivery pipeline
and
targets.
The targets represent the staging and production clusters.
Creates a Cloud Storage bucket and stores the Skaffold rendering
source and rendered manifests in that bucket.
Generates a new release
for each source code change.
Deploys the application to the production environment. For this
deployment to production, an operator (or other designated person)
manually approves the deployment. In this architecture, the production
environment is a Google Kubernetes Engine cluster.
In this architecture, configuration is shared among the development, staging,
and production environments through
Skaffold,
a command-line tool that facilitates continuous development
for Kubernetes-native applications.
Google Cloud stores the application's source code in GitHub.
This architecture uses Google Cloud products for most of the components of
the system, with Skaffold enabling the integration of the system. Because
Skaffold is open source, you can use these principles to create a similar system
using a combination of Google Cloud, in-house, and third-party components.
The modularity of this solution means that you can adopt it incrementally
as part of your development and deployment pipeline.
Use cases
The following are the key features of this integrated system:
Develop and deploy faster.
The development loop is efficient because you can validate
changes in the developer workspace. Deployment is fast because the
automated CI/CD system and increased parity across the environments allow you
to detect more issues when you deploy changes to production.
Benefit from increased parity across development, staging, and production.
The components of this system use a common set of Google Cloud tools.
Reuse configurations across the different environments.
This reuse is done with Skaffold,
which allows a common configuration format for the different environments. It
also allows developers and operators to update and use the same configuration.
Apply governance early in the workflow.
This system applies validation tests for governance at production and in the
CI system and development environment. Applying governance in the development
environment allows problems to be found and fixed earlier.
Let opinionated tooling manage your software delivery.
Continuous delivery is fully managed, separating the stages of your CD
pipeline from the details of rendering and deploying.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2022-11-18 UTC."],[[["\u003cp\u003eThis architecture uses Google Cloud tools (Cloud Code, Cloud Build, Cloud Deploy) to set up a continuous integration and continuous delivery (CI/CD) system for developing and deploying applications to Google Kubernetes Engine (GKE).\u003c/p\u003e\n"],["\u003cp\u003eCloud Code serves as the development workspace, running in Cloud Shell, where developers can see changes in the minikube development cluster.\u003c/p\u003e\n"],["\u003cp\u003eCloud Build automates building and testing, using triggers to monitor source code changes, rebuild the application container, and run tests before deploying to the staging environment.\u003c/p\u003e\n"],["\u003cp\u003eCloud Deploy manages the continuous delivery pipeline, registering delivery pipelines and targets, storing Skaffold rendering source and manifests, and deploying the application to production with manual approval.\u003c/p\u003e\n"],["\u003cp\u003eSkaffold facilitates shared configuration across development, staging, and production environments, enabling a common configuration format and allowing for the reuse of configurations.\u003c/p\u003e\n"]]],[],null,["# CI/CD pipeline for developing and delivering containerized apps\n\nThis document describes an integrated set of Google Cloud tools\nto set up a system for development, for continuous integration (CI), and\nfor continuous delivery (CD) that you can use to develop and deploy applications to\n[Google Kubernetes Engine (GKE)](/kubernetes-engine).\nThis reference architecture document is intended for both software developers\nand operators. It assumes that you're familiar with running `gcloud` commands on\nGoogle Cloud and with deploying application containers to\nGKE.\n\nArchitecture\n------------\n\nThe following diagram shows the resources that are used in this architecture:\n\nThis architecture includes the following components:\n\n1. **Cloud Code** as a development workspace. As part of this workspace, you can see changes in the development cluster, which runs on [minikube](https://minikube.sigs.k8s.io/docs/). You run Cloud Code and the minikube cluster in [Cloud Shell](/shell). Cloud Shell is an online development environment accessible from your browser. It has compute resources, memory, an integrated development environment, (IDE), and it also has Cloud Code installed.\n2. **Cloud Build** to build and test the application---the \"CI\"\n part of the pipeline\n\n This part of the pipeline includes the following actions:\n - Cloud Build monitors changes to the source repository, using a Cloud Build trigger.\n - When a change is committed into the main branch, the Cloud Build trigger does the following:\n - Rebuilds the application container.\n - Places build artifacts in a Cloud Storage bucket.\n - Places the application container in Artifact Registry.\n - Runs tests on the container.\n - Calls Cloud Deploy to deploy the container to the staging environment. In this example, the staging environment is a Google Kubernetes Engine cluster.\n - If the build and tests are successful, you can then use Cloud Deploy to promote the container from staging to production.\n3. **Cloud Deploy** to manage the deployment---the \"CD\" part of the\n pipeline. In this part of the pipeline, Cloud Deploy does the\n following:\n\n - Registers a [delivery pipeline](/deploy/docs/terminology#delivery_pipeline) and [targets](/deploy/docs/terminology#target). The targets represent the staging and production clusters.\n - Creates a Cloud Storage bucket and stores the Skaffold rendering source and rendered manifests in that bucket.\n - Generates a new [release](/deploy/docs/terminology#release) for each source code change.\n - Deploys the application to the production environment. For this deployment to production, an operator (or other designated person) manually approves the deployment. In this architecture, the production environment is a Google Kubernetes Engine cluster.\n\nIn this architecture, configuration is shared among the development, staging,\nand production environments through\n[Skaffold](https://skaffold.dev/),\na command-line tool that facilitates continuous development\nfor Kubernetes-native applications.\n\nGoogle Cloud stores the application's source code in GitHub.\n\nThis architecture uses Google Cloud products for most of the components of\nthe system, with Skaffold enabling the integration of the system. Because\nSkaffold is open source, you can use these principles to create a similar system\nusing a combination of Google Cloud, in-house, and third-party components.\nThe modularity of this solution means that you can adopt it incrementally\nas part of your development and deployment pipeline.\n\nUse cases\n---------\n\nThe following are the key features of this integrated system:\n\n- **Develop and deploy faster**.\n\n The development loop is efficient because you can validate\n changes in the developer workspace. Deployment is fast because the\n automated CI/CD system and increased parity across the environments allow you\n to detect more issues when you deploy changes to production.\n- **Benefit from increased parity** across development, staging, and production.\n\n The components of this system use a common set of Google Cloud tools.\n- **Reuse configurations** across the different environments.\n\n This reuse is done with [Skaffold](https://skaffold.dev/),\n which allows a common configuration format for the different environments. It\n also allows developers and operators to update and use the same configuration.\n- **Apply governance** early in the workflow.\n\n This system applies validation tests for governance at production and in the\n CI system and development environment. Applying governance in the development\n environment allows problems to be found and fixed earlier.\n- Let **opinionated tooling** manage your software delivery.\n\n Continuous delivery is fully managed, separating the stages of your CD\n pipeline from the details of rendering and deploying.\n\nDeployment\n----------\n\nTo deploy this architecture, see\n[Develop and deploy containerized apps using a CI/CD pipeline](/architecture/app-development-and-delivery-with-cloud-code-gcb-cd-and-gke/deployment).\n\nWhat's next\n-----------\n\n- To learn how to deploy into a private GKE instance, see [Deploying to a private cluster on a Virtual Private Cloud network](/deploy/docs/execution-environment#deploying_to_a_private_cluster_on_a_network).\n- For information about how to implement, improve, and measure deployment automation, see [Deployment automation](https://dora.dev/devops-capabilities/technical/deployment-automation/)."]]