[MUSIC PLAYING]
VALERIYA SHIN: Hi, everyone.
I'm Valeriya Shin, a customer engineer at Google Cloud.
ERICA CHUONG: And I'm Erica Chuong, a partner engineer
at Google Cloud.
Welcome back to another segment of "Google Cloud Technical
Guides for Startups."
In this video, we'll be focusing on Continuous Integration
and Continuous Deployment, also known as CI/CD,
using Google Cloud.
In this episode, we're going to cover,
what is CI/CD, CI/CD in practice,
setting up CI/CD, as well as a Google Cloud Console demo.
So without any further ado, let's
get right into exploring the Google Cloud platform together.
Continuous Integration, or CI, is the process
of automating the building and testing of changes
to code in order to detect problems early.
Continuous Delivery, or CD, is the process
of automating deployments across multiple environments
in a safe, low-risk, and quick manner.
Let's take a deeper look into each.
CI-- again, Continuous Integration--
is the process where code changes undergo
a series of automated processes to ensure that the application
or system is still working.
Part of the CI pipeline may be to build or compile
an application once the code changes have
been made in order to validate and ensure that there
are no breaking changes.
This can be achieved through a shared repository where
developers commit and merge code that is then saved, reviewed,
and tested.
Additional steps could be included and automated,
such as unit tests, integration tests, and deployment
of the same artifact.
You should have some sort of tool for source code
management, such as Cloud Source Repositories, GitHub,
or Bitbucket.
You can also have a CI server for building and testing code,
such as Cloud Build, Jenkins, or circleCI.
With continuous delivery, deploying artifacts
from your CI server must be done manually.
With CD, or Continuous Deployment, on the other hand,
this is the practice of delivering new software
features through an automated deployment process.
Usually right after CI, CD may take the build artifact and use
one of the many different deployment paradigms
to deploy the artifact.
Everything is fully automated, and having
every single commit to your source code management system
built into the artifacts and then deployed to production.
Some common tools for continuous deployment
include Puppet, Jenkins, and bash scripts.
Now that we've gone through what continuous integration
and continuous deployment are, you
may be wondering why they're such important concepts
to apply.
First, they ensure that all changes to code
are tracked, tested, and built. Documentation
is key so there are no questions as to what
features are in each release and who made the changes.
Second, automating a lot of these manual tasks
reduces chances of human error.
Going back to the importance of documentation,
should there be any sort of bugs,
these will be easily trackable and you can quickly
roll back to a stable version to reduce
any outages from deployments.
This leads to increased innovation and faster time
to market, resulting in happier deployment, development,
and operations teams.
With CD, oftentimes teams embrace the concept
of immutable infrastructure.
When delivering an artifact, you can
rest assured that each artifact is exactly the same.
After initial deployment, no additional configuration
is performed on the VMs and containers,
thus making the fleet completely standardized.
For VMs, you can use Packer to automatically perform
this build and versioning.
And for Kubernetes and containers, you can use Docker.
As a result, you'll get faster times for launch
to images and containers as they're
prebaked with all software and configurations.
In practice, it looks something like this.
When we have a new binary or configuration to deploy,
we must first bake a deployable image
based on a full build of a server.
Here we install all runtime dependencies,
such as runtime stacks and, of course, our application binary.
You can automate this in any way that you'd like,
such as using Chef, Puppet, or another tool.
We then deploy this image as a VM instance
in our various environments that we test in,
through to production, where we can
deploy the same image again.
If you're using Docker containers,
this is a very familiar territory for you,
and where you can bake images via docker
build or server-side build services,
such as Docker Hub and Google Container Registry build.
If you're deploying to VMs, Spinnaker
has Packer-based bakeries that can support
the flow that I just described.
There are other benefits that are
particularly pertinent as you're deploying to the cloud.
If your Chef recipes, for example,
are taking 40 minutes to complete
the build of a new server, you're
not able to take advantage of the elasticity of the cloud.
The demand has already come and passed.
Other ops-critical functions, such as auto-healing
and rollback images, are similarly very difficult
if you're not using these prebaked images.
Another product to highlight is Google Cloud Deploy.
Google Cloud Deploy allows users to deliver continuously
to Google Kubernetes Engine, or GKE, within minutes.
There are many benefits of this managed service.
First, users don't have to own, scale, and/or maintain
CD tooling themselves.
Similar to Cloud Build, Google Cloud Deploy
is a managed service.
This reduces the total cost of ownership
for continuous delivery.
There are no servers to manage or patch,
and resources can scale up and down automatically
to optimize cost and performance.
It also integrates with Google Cloud Platform's Identity
and Access Management, and has audit features built in.
This easily enables the securing, tracking,
and auditing of delivery pipelines and related
activities.
Google Cloud Deploy's opinionation
aims to reduce onboarding time and cost of ownership
by providing structure to continuous delivery processes.
You can define releases and progress them
through environments such as test, stage, and production,
and there's a one-step promotion and rollback
of releases via the web console, CLI, or API.
In addition, there is built-in support
for metrics to measure and optimize deployment success.
With increased visibility, users can gain insights
on deployment metrics and drive objective-based SRE and DevOps
processes.
This is an example of an end-to-end CI/CD workflow.
The first step for a CI/CD pipeline
is to host your code in a source control management
system, such as Google Cloud Source Repositories.
Once you upload your code to your repository,
we'll have to choose from one of many platforms designed
to facilitate CI/CD.
Many common platforms were designed
to run all kinds of automation and have since
been adjusted to support CI/CD.
Google Cloud Build was designed with CI/CD in mind
and is serverless, meaning you don't
have to manage the underlying infrastructure of your builds.
You can configure Google Cloud Build
with cloudbuild.yaml files that live directly
in your repository.
Cloud Build facilitates CI by supporting
many different source control services, easy integration
with Google Cloud Services for testing,
and it supports deploying artifacts
to various destinations, including Artifact Registry.
Cloud Build supports complex builds with multiple steps--
for example, testing and deployments.
If you want to add to your CI pipeline,
it's as easy as adding an additional step to it.
Take your artifacts, either built or stored locally
or at your destination, and easily deploy it
to one of our many compute services
with a deployment strategy of your choice.
VALERIYA SHIN: Now let's take a look
into how we can create a deployment pipeline for Cloud
Run that implements progression of code
from developer branches with automated canary testing
in Google Cloud Platform.
Cloud Run lets you deploy and run your applications
with little overhead or effort.
Check out the Cloud Run video in the description box below just
to get a quick run-through of Cloud
Run and other compute services available in Google Cloud
platform.
In this demo, we will create a sample Cloud Run service,
add a change on a development branch,
merge the branch into the mainline branch,
implement canary testing to rule out any change to the Cloud Run
service.
Let's start off with preparing our environment.
Let's go to Google Cloud Console and login
into Google Cloud Project.
In the console, we activate Cloud Shell.
And now let's create environmental variables
and enable the needed APIs if they're not enabled.
And now let's setup the admin roles for the service account.
If you haven't used git in Cloud Shell previously,
you can setup a username and user email values.
And now we will clone and prepare the sample repository.
We will store the code from sample repository
in Cloud Service Repositories.
All right.
Now let's move to the Cloud Run service.
In Cloud Shell, we will build and deploy the application,
including a service that requires authentication.
The next step is to enable a unique URL for development
branches in git.
Each branch is represented by a URL that's
identified by the branch name.
Commits to the branch trigger deployment,
and the updates are accessible at the same URL.
In Cloud Shell, let's setup a trigger.
Now let's create a new branch and open the sample application
in the Cloud Shell.
In the sample application, let's modify the code
to indicate version 1.1 instead of version 1.0.
And now let's commit the change and push
to the module repository.
You can check the progress of ongoing
build in the Cloud Build.
Cloud Build can also trigger a message via email,
Slack, or other messaging providers.
Now let's get the unique URL for this branch.
When code is released to production,
it's common to release code to a small subset of light traffic
before migrating the traffic to the new code pages.
Let's implement a trigger that is activated when code is
committed to the main branch.
The trigger deploys a code to a unique canary URL
and it routes 10% of all live traffic to the new version.
All right, let's setup the branch trigger
and now merge the branch to the main line
and push to the module repository.
After the build is complete, let's review new version.
As you see, 90% of the traffic is
routed to prod, 10% to canary, and 0% to the branch revisions.
That brings us to the end of this video, where we've
been over what is CI/CD, CI/CD in practice,
setting up CI/CD, deployment strategies, and a Google Cloud
Console demo.
We have tons of resources and guides
around setting up CI/CD on our documentation website.
A couple of resources have been added in the description box
below to help you understand these concepts
in further detail.
I encourage you to take a look prior to setting everything up.
Should you run into any issues, our support team
is always available, as well.
Stay tuned for all the exciting content that we have for you.
Don't forget to like and subscribe
to our YouTube channel.
Click on the bell icon to get notified each time
a new video is posted.
We'll see you soon in our next video, where
we will go over different operations and building
tools in Google Cloud.
Thank you, and see you next time.
[MUSIC PLAYING]