>> I'm here with Yev Bronshteyn
and Yev today is going to talk to us
about using DevOps with Azure Spring Cloud. Take it away, Yev.
>> Thank you, Brian. My name is Yev Bronshteyn and we're going to
talk about how you might follow
a DevOps process with Azure Spring Cloud.
Now, DevOps first and foremost is
about people and process not about technology.
So, instead of specifying a particular approach,
I want to show you the tools and techniques available with
Azure Spring Cloud so that you can pick
the ones that work best for your organization.
Now, in this talk we're going to be using Azure Pipelines.
However, all of the technologies
and approaches we're going to talk
about are applicable to any other CICD tool you might use,
such as Jenkins or GitHub Actions.
Here's our agenda for today.
We're going talk about making Pipelines
to provision your application environment,
for building your application,
for deploying your application to Azure Spring Cloud,
and to top it off, we'll cover some best practices.
We're going to divide the process into three distinct pipelines.
One to provision your environment,
one to build your application,
and one to deploy your application.
The reason for making these pipelines separate and distinct is
that you might want to orchestrate them
differently depending on your scenario.
For example, in production,
you might want to provision once,
but then build and deploy regularly
provided that you have rigorous automated tests.
In a nightly build environment on the other hand,
you might want to do the build first
and then only provision an environment if the build passes.
So we're going to keep these three pipelines separate
and distinct knowing that they do work together.
Let's start with provisioning your application environment.
There are two common approaches we see customers use.
One is Terraform and the other is
Azure Resource Manager templates or ARM templates.
Let's talk about Terraform first.
The advantage of Terraform is that it
has broad industry support and you can
reuse your Terraform scales across
different products and across different Clouds.
I have a sample Terraform script here to provision
an Azure Spring Cloud instance and an app in Azure Spring Cloud.
Once we have our Terraform script,
let's talk about how to put it into a pipeline.
With Azure Pipelines, you're going to need to
get the Azure Pipelines Terraform task.
If you access the link on the slide here
or accompanying the video,
you will go to this page where you can click
the "Get it Free" button to add
the Azure Pipelines task for Terraform into your organization.
Then once you have this task,
you can navigate to
your pipeline and just create
a new Azure Pipelines with two Terraform tasks.
You don't actually have to remember how to do
all of this from scratch,
you can just search for Terraform in
the assistant on the side and you will
get a user interface for creating the tasks you see here.
In this pipeline, I have two tasks.
One to run the init command and one to run the Apply command.
Just as a reminder,
if your Terraform files are not
in the root directory of your repository,
you'll want to provide this working directory parameter
to specify where they are.
Once we have this, you can click
"Run" and that's going to provision the environment automatically.
Again, you might do this nightly for
nightly builds or only once for production builds.
You can use the same pipeline.
So let's talk about how you might use
Azure Resource Manager or ARM templates instead.
Now, ARM templates work very similar to
Terraform in that you're specifying what you
want in your deployment and then Azure Resource Manager
will create that environment
for you or update that environment for you.
The advantage of ARM templates
is that you are not starting from scratch.
If you have an existing environment,
may be one that you've created Azure Portal,
you can just navigate to that environment.
Let's say I have my resource group
here containing my Azure Spring Cloud instance
and a database and I can go to "Export
template" and this will generate an ARM template that I can use.
I can use it verbatim or perhaps parameterize it to suit my needs.
Those are the two most common approaches
for provisioning your environments
reproducibly and consistently with
Azure DevOps and Azure Spring Cloud.
Now, let's talk about how you would
build your Azure Spring Cloud application.
Build process typically consists of three steps
that are independent of the environment
that you're provisioning or deploying to.
First, you would run the Maven or Gradle build,
you would copy all the jars you've created
to a staging directory and then you publish
that directory as an artifact of
the build pipeline so that other pipelines could consume it.
To get started with this is very easy.
If you have Azure Pipelines open,
you can click on this "New Pipeline"
button and you will get a template for getting started.
So I will choose the location of my code.
I'll use this fork here and from
the templates I can scroll down to Gradle or
Maven and choose the one that's appropriate for the project.
Now, right off the bat,
this gives me a Maven task to build the application.
I just need to add two more.
I can use the assistant here to add
a copy files task to copy of all the jar files to
a staging directory and I can then add a publish task.
Publish build artifacts right here to then make
these artifacts available to the subsequent deploy pipeline,
and I have a completed pipeline here.
There's the Copy task and the Publish task,
and the links to all of these will be
available at the end of the slide deck if you download it.
So that's the built pipeline.
This is independent of any particular environment.
Let's focus now on actually deploying
the application that we've built to Azure Spring Cloud.
Typically, we see two patterns
with deployment environments that customers use.
These are not mutually exclusive.
One is that customers will have
different environments for different stages of deployment.
So there might be a test or
DevTest environment that gets regular deployment,
a QA environment or
staging environment that's more production-like,
and ultimately production itself.
You can certainly do this with Azure Spring Cloud,
but there's another pattern as well.
Azure Spring Cloud offers
blue-green deployments as a feature of the product,
which means that you can have
one deployment of your application running and receiving
production traffic while uploading
another deployment that's running in the same environment,
but not receiving production traffic,
so that you can independently
test your changes on a private endpoint and
validate that you can have reasonable confidence in
those changes before any production traffic sees those changes.
Once you've validated your new deployment,
you can set that deployment as active,
so that it receives
all the production traffic and you can combine these two patterns.
For instance, maybe once you deploy to QA environment,
you'll want to do some manual testing by your QA team,
but at the same time on each deployment,
you might want to do some automated testing
before making that deployment active.
So these two patterns can
combine very powerfully with Azure Spring Cloud.
To actually accomplish these deployments,
all it takes is a couple of commands with Azure CLI.
When we've been working with a single deployment,
the command we need is the az spring-Cloud app deploy command.
This will create a new deployment- this will upload
the application to Azure Spring Cloud and although
we're not using blue-green deployments in this case,
Azure Spring Cloud will still make sure that your app is up
and running before taking down the old instance.
If you do want to use blue-green deployments so that you can do
additional automated testing before
routing traffic to the new deployment,
you can use the az spring-Cloud App Deployment.
Create command.
This will create a new deployment that
will only be available on a private endpoint.
Once you've established your confidence
in the changes you're deploying,
you can use the az spring-Cloud App Set Deployment command.
That will make the new deployment
active and it will receive production traffic.
Let's look at how we might orchestrate this with Azure Pipelines.
Here I have a release pipeline.
You would find this by going to
Azure Pipelines and clicking on "Releases".
First, I will define the artifacts component.
This is what we are deploying and you can see I've specified
the Build Pipeline as the source of
my artifacts so that when this runs,
the artifacts published by the Build Pipeline will be downloaded.
Note, I can enable Continuous Deployment
so that all the new changes are automatically deployed,
or perhaps only new changes on the master branch.
Next, I have a stage task for
each of the Microservices or applications I'm deploying.
The Stage Task will create
a new deployment that's available on a private endpoint.
All of these tasks have
a single task group that's parameterized for each application.
But under the covers,
all these task groups do is run the same
az spring-Cloud App Deployment
Create command that we just talked about.
Once each of the apps is deployed,
I can have some additional validation
before routing production traffic to the app.
First, I might get a manager's approval.
This allows the next stage to be blocked
until one of the select approvers approves the deployment.
To ensure some additional testing on requirements are met,
I can create a Gate.
For example, I might block
the rollover to production until
all the high priority work items have been resolved.
I might invoke a REST API to hit
an additional health check endpoint or I
might invoke an Azure function to perform an integration test.
Once all the constraints have been met,
we have another task group which under the covers
runs the az spring-Cloud app set-deployment command.
All of this is just an orchestration around
Azure CLI and Azure Spring Cloud
that allows me to follow a flexible,
highly automated and reliable DevOps process.
Let's talk about some best practices for
using Azure DevOps and Azure Spring Cloud.
First, we talked about having
three distinct decouple pipelines. This is important.
When you decouple pipelines from each other,
you allow yourself and your developers to troubleshoot
and re-run any one pipeline without influencing all the others.
For example, might want to have
several attempts at redeploying
a build without having to rebuild the application.
You certainly shouldn't need to tear down and
reprovision environments or update
your environments just to re-run the build pipeline.
Similarly, the pipeline definitions
should be decoupled from the environments onto
which you're deploying so that
one pipeline can be reused across multiple environments.
This will help keep all your environments, Dev,
Test, QA and Production consistent with each other.
You want to minimize duplication among your pipelines.
You can use variables, parameters, task groups,
and templates to use the same code, the same flow,
the same logic across all your pipelines.
This will eliminate customization you have to
do from project to project or from environment to environment.
Keep in mind, if you have YAML pipelines,
you can create multiple pipelines with
the same YAML file where only some variable values can change.
This will allow you, for example,
to create a provisioning pipeline for your test environment,
your QA environment and
your production environment all with the same YAML,
but each pipeline can have different permissions so that
only the users who are allowed to touch
that particular environment can run that pipeline.
Next, let's talk about protecting secrets.
Unfortunately, we see many customers where secrets,
credentials or passwords are available in plain text.
Familiarize yourself with the mechanisms that
Azure DevOps and Azure provide for keeping your secrets safe.
In Azure Pipelines, you can have secret variables that
are injected into the environment of your tasks.
You can have secure files that are
downloaded as files to be available to your tasks.
For any secrets that need to be available,
both during deployment time and at run time,
Azure Key Vault is often the right answer.
All the links on the slide will take you to
the resources you need to get started with all these tools.
Lastly, in Azure Pipelines,
you can cache the Maven repository so that you're
not downloading the same artifacts from one build to another.
This will not only speed up your builds,
but help you have more reliable and reproducible builds
so that if Maven Central or
another public repository becomes unavailable,
your build can still complete successful.
All the sample materials you've seen in
this video are available on GitHub.
If you download the slide deck,
the slide will have all the links.
Lastly, we have many additional resources
for you to get started using Azure Spring Cloud,
and I hope you'll check those out. Thank you very much.
>> Thanks very much Yev.
That was wonderful.
I really, really like how easy it is to use Azure Pipelines
to make the deployments directly to Azure in
Cloud using the CLI behind the scenes.
It's a great way to do it and it's good to
know that the CLI is being used behind the scenes as well.
Thanks a lot for that. That was great.
Thank you, Brian.