>> Hey folks. Welcome to this demo.
I'm Anirudh Raghunath, a Program Manager at Microsoft.
In this demo, I'll be going over the following topics.
I'll be going over what CI/CD is and what are its benefits.
Next, I'll give you an introduction to GitHub Actions,
how it works, and how you can configure them.
After that, we'll deploy a sample app to
Azure Kubernetes Service using GitHub Actions.
Finally, we'll go over
preconfigured real-world microservice application and see that
it's simple to configure CI/CD in
this case as well. So, let's get started.
What is DevOps?
DevOps is a set of practices that works to automate and
integrate the processes between software development and IT teams.
It's an agile development practice,
streamlined software building, testing, and release.
DevOps is often implemented using CI/CD.
CI, or Continuous Integration,
is an engineering practice in which members of
a development team integrate the code at a very high frequency.
Since integration has usually been
a time and effort consuming activity,
CI tactics depend on
automation tools that execute build and testing.
CD, or Continuous Delivery,
is the practice of ensuring that
code is always in a deployable state.
This means that all changes to code: new features,
bug fixes, configuration changes,
are always ready for deployment to a production environment.
Now let's look at some benefits of DevOps.
DevOps promises faster delivery of features,
more stable operating environments,
improved communication and collaboration, and most importantly,
more time to innovate rather than fix and maintain infrastructure.
Here are a few metrics.
Organizations that have good DevOps, practices on
an average post 200X faster deployments,
25X faster recovery time,
3X lower change failure rates.
These are some significant metrics that really highlight
the advantages of having optimal DevOps practices.
There are many tools available to implement CI/CD,
with the newest one being GitHub Actions.
GitHub Actions enable you to create custom
SDLC workflows directly within your GitHub repository.
These workflows can be triggered using a wide variety of
events and can help you build robust CI/CD pipelines to build,
test, and deploy your code.
These events include push, pull request,
issue creation, folks, bad books, and many more.
They make use of pre-configured actions or
tasks with over 3,000 actions available on the marketplace.
This also includes the full suite of actions by
Azure that let you connect to the cloud
in an easy and consistent manner.
Now let's start with a hands-on demonstration.
I'm going to be using this nodejs hello-world app,
and we'll deploy it to Azure Kubernetes Service.
To get us started, I wanted to configure a few things.
I've provisioned an EKS cluster
and have a Container Registry to store my images.
As you can see, I have configured
a very simple Docker file to containerize this app.
Additionally, I have added two manifest files.
Deployment manifest creates a replica set with
two replicas that will pull the image from my Container Registry.
Next, the service manifest will
create a service of type load balancer.
And this would point to the replicas
created as part of our deployment.
I have also configured two workflows,
each to be triggered at different points of time.
The first one is the pull request workflow.
This will be triggered every time
a PR is raced against the master branch.
As you can see, I'm first building my container image.
Next, I'm making use of Azure's image scan action,
which internally uses tribute and toggl
to find vulnerabilities and link your image.
I'm going to use this to scan for any
vulnerabilities my container image might have.
This is also a good way to proactively prevent
a vulnerable image to get deployed into our cluster.
If the scans succeeds,
I can merge the pull requests into my master branch.
This would also be a good place to add automated test cases.
The second one is the CI workflow.
This will be triggered every time someone makes a comment
to the master branch. As you can probably tell,
once our PR gets checked in,
this workflow will be triggered.
It contains two jobs.
The build job would be used to first build my container image,
tag it with the comment and
push it to my Container Registry.
Next, we have the deploy job.
It makes use of multiple Azure actions.
First, set the Kubernetes context to my cluster.
Second, create the required namespace.
Third, add a secret to
the cluster to pull my image from my private registry.
Finally, deploy to the cluster using my manifest files.
As part of configuring the actions,
I have also created three secrets,
namely the Container Registry username,
its password, and the Azure credentials
required to set the Kubernetes context.
Let's jump into the command line real quick.
I've already prepared all the commands I'm
going to be using for this demo so
that you don't have to see my butter fingers
ruin the demo by making typos.
First, let's get all the resources in the cluster in this namespace.
As you can see, we currently have nothing deployed.
Now let's create a feature branch and make a small change.
I'm going to edit the title of the app for the sake of this video.
There we go. Now, let's commit this and push it to my remote branch.
To integrate our changes,
let's create pull request to the master branch.
So, the feature branch, it correctly forms a tree.
You can see our changes over here.
Now let's give it an appropriate description and create
a pull request,
There we go.
Now, if you notice,
the PR workflow has already
been kicked off in the form of a check.
If you click on the "Details" link,
you can see that our workflow is already running.
It's building the container image and
then it'll scan it for vulnerabilities.
For the sake of the demo,
I'm going to pause and come back once it's done.
As you can see, the check is now complete.
Again, clicking on the "Details" link
will take you to the workflow run.
Awesome, there were no vulnerabilities found. Let's move forward.
Now that all of this looks good,
I'll go ahead and merge this PR.
If you go to the "Actions" tab,
as you've probably guessed,
our second workflow, the CI workflow, has been triggered.
If you click on it and go to the "Details",
we can see that the first job,
which is the build job, has started running.
I'm going to pause again and wait
for the deployment job to complete.
Great. Now that it's done,
our resources have been deployed successfully to Azure.
Jumping back into command line again,
you can see that all of our resources
have a DB deployed to the cluster.
Let's quickly grab the IP address
of our service and use it in our app.
You can see that the change we made
has been successfully deployed to the cluster.
Now obviously, this is just a sample app and configuring
the full-blown enterprise application will take a bit more effort.
But the overall structure remains the same.
Let's take a look at an example.
I'm going to run by you, how we can deploy
a complex application with multiple microservices involved.
We have the Rock Paper Scissors Lizard Spock application.
If you take a look at the architecture,
it contains multiple different microservices,
each written in a different language.
It also has a Cosmos DB Instance and an Azure function,
all bundled and deployed on AKS.
For an app with so many moving parts,
provisioning can become faster than if done manually.
So, we've configured the workflow
to take care of this for us.
As you can see, you can configure
the trigger to work on specific parts.
So this workflow will get triggered only
if there are some changes to the ARM bot,
where we have stored all of our ARM
templates or if there are some changes to the workflow file itself.
We use a login action by Azure to connect to the cloud.
Then we use easy CLI to provision the resources.
Now, how do we deploy the different microservices?
A clean way to do this is to have
a separate workflow for each one, a cicd.
Let's pick Python microservice.
Similar to the one before,
it's configured to trigger only when
there are changes to the Python directory.
We've also included the bot to
the home chart we are using to deploy this to our cluster.
The rest of the workflow file remains largely
similar to the one we created in the previous example.
The only difference here is that we're using
Helm to deploy charts to our cluster,
instead of directly using manifest files.
There we have it, configuring CI/CD for
an enterprise-grade application with
multiple microservices using GitHub Actions.
Let's quickly summarize what we've seen in this demo.
We went over how we can configure workflows using
GitHub Actions to create powerful and flexible CI/CD pipelines.
We also saw that this functionality can be
extended to enterprise-grade applications at scale.
We looked at the suite of actions that Azure
provides out of the box for Kubernetes,
which allow users to seamlessly connect to
their clusters and manage their workloads.
A key point to note here is that
GitHub Actions work not only for Azure,
but for all other clouds as well.
As well as on-prem clusters.
The workflows we configure for our deployment will create it
using one of the many started templates provided by Azure,
which allows users to quickly get started.
That brings us to the end of this demo.
The documentation to all the actions provided by Azure can
be found at aka.ms/actionscd.
For any further questions,
you can reach out to me at my e-mail address.
I hope that this has been informational. Thanks for tuning in.