- Coming up, we'll take a look at the latest updates
to Azure DevOps, a customizable platform
for running devops in your organization
or on any tech platform or cloud.
We'll look at how you can use your preferred
language, tools, and processes, and take advantage
of new first-party GitHub integration
for your open-source projects,
turn-key, cloud-hosted code versioning,
and automated approval workflows.
You'll learn the build and release CICB process
with Azure pipelines,
and automated code quality checks with release gates.
And new features, such as IntelliSense and Autocomplete
in our visual editor to help you build
quality code faster.
(upbeat music)
So I'm joined by DevOps expert Abel Wang.
Welcome to the show.
- Great to be here.
- Before we get into too much detail
on the Azure DevOps Toolset,
DevOps is a pretty loaded term with
lots of industry buzz around it.
So what do we at Microsoft mean by it?
- Well, for us, it's about us as developers
being able to continuously deliver value
to our end users.
And in order to do that,
we need to bring together the teams
that develop and operate the apps
while still allowing them to use the Dev processes,
tools, skill sets, and technologies
that are right for their organization.
Now DevOps is so important to us at Microsoft.
It's is inherent in how we deliver Azure
as a platform to build your apps and services.
- Right, it used to be that you could develop code
and throw it over the fence to an operations team
who had to figure out how to run it in production,
how to update it, but that separation
can also cause issues when things break
or if you need to try to recreate
production environments rapidly.
So these teams really need to align.
- Yeah, and that's a huge part of it.
We wanna get developer and ops disciplines
on the same page, not separated by walls,
but one unified team,
and this leaves less lost in translation.
For example, a core concept is
infrastructure as code and pipeline as code,
where we codify the entire build and release process.
The other big part of it is making sure
we build higher quality code
and deliver value to our organizations faster.
Core DevOps concepts, like continuous integration,
and continuous delivery, focus on code being delivered
more frequently and discreetly,
and this will give us the ability to really
leverage modern architectures, such as Microservices.
Now we can continuously iterate by testing,
innovating, and updating the code.
- Yeah, so it really sounds like DevOps
is a lot more than just checking a checkbox
but really a culture change in how you're developing
and releasing your products.
- Yeah, totally, think of DevOps as one continuous motion
where you plan, build, and deploy and operate your apps.
But it doesn't end once your code hits production.
Once in production, we still need to gather
telemetry and feedback.
And this feedback?
It will let us know if we're delivering value,
which in turn, will come back and help us
plan more effectively for that next iteration.
- All right, so on one hand, we have these DevOps processes,
but we also have a tool set called Azure DevOps,
so how do these align?
- All right, so Azure DevOps, the product,
that is the ultimate DevOps tool set.
What we've done is we've taken VSTS
and updated it to align it even more with DevOps processes.
The goal was to make it super clear,
that this tool set,
it works with any editor, any language, any platform.
Not just Visual Studio and Windows,
any language targeting any platform.
Azure DevOps is basically a suite of five
key separate tools that work extraordinarily well together,
but you could use a combination of different tools
to manage your DevOps processes today.
For example, maybe you're using Jenkins right now
for your build and another tool for your deployment.
If you need a solution for code collaboration
and version control, we have Azure repos.
Or through our first party integration with GitHub,
you can use GitHub, and that allows you to bring in
your open-source projects.
Or you can do your planning and tracking of your work
and your bugs by using Azure Boards.
Or take advantage of iterative testing
with Azure Test Plans.
Or package management with Azure Artifacts.
Or orchestrate your full CICD pipelines
and your release pipelines for your code
with Azure Pipelines.
And release gates.
Now that will ensure code quality
and the right approvals are in place
in order to go from one stage to the next.
- All right, so you can use any of these components
individually to extend your tools and DevOps processes,
but I imagine it's more of an advantage
if you use the tool set all together.
- Yeah, totally.
Using all five parts of Azure DevOps together
is gonna give you an unprecedented view
and to help you view your project.
Since all that data that's being collected
automatically gets correlated for you.
We also give you an open DevOps platform,
which supports any language, targeting any platform,
whether that's Linux, Mac, Windows, Azure,
or even someone else's cloud.
Now you can also use things like Azure AD
for access management,
and assign access privileges at the reource level.
And you can use Azure Monitor,
or even wire up the monitoring solution of your choice.
- Now the good news here is that not only are you adding
additional security in this world,
but you can also help control your cost
by making sure only the people with the right permission
can deploy code to an Azure resource.
- Right, so let's make this real.
Let's walk through a real live example.
So what we have here is a health tracking app that I wrote.
It's based off of MicroServices, so it has a web front end,
and the code is in GitHub.
The front end is written in Node.
It also has an API layer that's written in .NET Core
that's gonna run in a Kubernetes service.
It also has an iOS and Android mobile portion as well.
All the code is held inside of GitHub.
Even with the code in GitHub,
we can easily connect it to Azure Boards,
so now we can use the power of Azure Boards
to track all of the work that we're doing
for our software project.
- I love this because it means that you don't have to move
your code or change how or what you're developing with
to start using DevOps.
You can easily just add it onto the tools
that your team might already be using.
- Absolutely, so the next things that I wanna do is,
I wanna build out my CICD pipelines from GitHub.
Now to do that, I need to install the Azure Pipelines
marketplace extension for GitHub, which I've already done.
Now once I do that,
it will connect up to my Azure Pipelines account
where now you can see all my GitHub repos
that I can build my CICD pipelines to.
Let's go ahead and choose my Mercury Health,
and notice it analyzed that repo.
It figured out that this repo was written in Node,
so now it's offered me some templates that I can choose.
I'm gonna choose a Node.js, and just like that,
it's gonna create for me a build definition
described in YAML where we can now save it
and kick off that build.
- That's awesome, so you've been able to really quickly
create Azure Pipelines as code.
I notice you checked it into your source control.
This makes it portable,
so I imagine when somebody else takes your code,
they don't have to go and recreate
your entire pipeline from scratch.
- Totally, just by cloning that repo,
or forking that repo,
not only do you get the source code,
you also get the build definition,
so it's super portable, super useful.
- Nice, I love how portable the YAML is,
but it can also be a little bit difficult
when you're learning it,
so can I still use that nice visual editor?
- Absolutely, you can.
So the YAML build engine is actually the exact same
build engine as what we had for the visual editor.
It's just a different front end.
Now using the visual editor,
it really helps to create the YAML.
Let me show you what I mean.
The build engine inside of Azure Pipelines
is basically a task engine that does one task
after another, after another.
So here I'm literally saying,
install MPM, set up my database connections,
build everything up, archive everything,
and then you're ready to go.
And to customize this build, all you need to do
is add or remove tasks.
Now out of the box, there are hundreds of tasks
that you can just download and start using
for all sorts of languages and all sorts of platforms.
If what you wanna do doesn't exist out of the box,
not a big deal, jump into the Marketplace where our partners
have now created over 500 build and release tasks
that you can just download and start using.
And if what you wanna do doesn't exist out of the box
and doesn't exist in the Marketplace,
you can write your own custom task.
A custom task?
That's nothing more than PowerShell or Node.js.
So what that means
is anything you can do from the command line,
you can easily get this build system to do as well.
When you finally figure out what your build needs to do,
if you want the YAML for it, check this out,
all you need to do is click on view YAML,
and just like that, bam.
We give you the YAML for that build definition
where you can now copy it and start using it.
- Now this makes generating YAML easy for every developer,
even if I might not be familiar
with all of the possible tasks.
- Exactly, so let's go ahead and copy this
and paste this into our YAML file.
Now this is our YAML file
with the new build definition all pasted in.
Now the cool thing is, inside of VS code,
we've also installed the Azure Pipelines extension.
Now this extension will give us the power
of IntelliSense and AutoComplete,
so we can now do things like this,
where we can just start typing,
and immediately auto complete everything that we need.
- All right, so now that you've got your build definition,
how do I actually use this to go and kick off a build?
- All you need to do is save this file and check it in,
so once you do that,
it will automatically kick off that build.
The build will kick off.
It's gonna download the latest source code from GitHub,
including the YAML file,
and it will load that YAML file
and then execute all the build steps
described in the YAML file.
When it's done doing that,
you get a build report that looks like this
that will show you everything that's happened
during your build.
- All right, so this is great.
I've got my build now, my code is ready to go,
but I also now need to get it somehow into production.
So how can I set up that pipeline as well?
- You need to create a release pipeline.
And it's as simple as clicking on this release button.
Now once I click this release button,
it'll take us to the visual editor for a release pipeline,
and it's gonna ask us, do you wanna use a template?
Which, of course I do 'cause it makes my life easier.
I'm deploying into Azure App Service,
so I'll go ahead and use the Azure App Service template.
Now once I select the template,
we now define the stages
that we want to deploy our application into.
So I wanna deploy into a staging environment,
so I'll name this Staging.
And the other thing that you need to do,
after you define its stage,
is to go into that particular stage,
and now you define what are the tasks that you need
to deploy your application for that particular stage.
Now we used a template,
so all I need to do is put in my Azure subscription
and choose the app service that I'm deploying to.
The app service that I'm deploying to
is gonna be the MercuryHealthMM, so I select that,
and now we've created a pipeline that will deploy
our application into the staging environment.
I still wanna deploy into a production environment,
so let's go ahead and create that.
I'll clone this,
and I'll call this environment my production environment.
Just like that, we've now created a pipeline
that takes code from a build,
deploys it into my staging environment
and then into my production environment.
- That's great, now is there something that I can do
to make sure that the right quality
and approval steps are gonna take place
between moving something like staging and production?
- Absolutely, so there are all sorts of automated
tests that you can run, right,
like unit test, load test, automated UI test.
You can also add manual approvers
before and after each particular stage.
So let's go ahead and jump to a particular stage
at the end of our staging environment.
I'm gonna add a post-deployment approver
where here you can add a list of people
where every single person on that list
has to approve before it'll flow through the gate.
Or you can add a group of people
where only one person has to approve in the gate,
and it'll flow through that gate as well.
Or you can have a combination of lists or groups.
You can make this as flexible as you need to,
or tighten this down as much as you need to as well.
Once we do this, and the release flies through,
you can see that we have a release now
that just got deployed into our staging environment,
but not only is it in the staging environment,
it's now waiting for an approval
before it flows on over into the production environment.
Let's go ahead and approve this.
So I can say, this looks good in staging, and approve it.
And as soon as I approve it,
it flows on over into my production environment.
Now one of the things that I've done
is I've added a pre-approval gate as well,
so instead of just blasting code in,
somebody has to physically approve it.
So I can go ahead and approve it,
and I can say, ready to deploy,
and if I click approve, immediately bits will start flowing.
I can also defer this deployment until later,
so I can approve it but say, let's schedule this
and deploy this Saturday at 2:00 in the morning
when nobody's on the system, or something like that.
Let's go ahead and approve it, and now bits will flow
and it's gonna flow all the way
into my production environment.
- This is great.
You've really been able to tighten down the security
to make sure that, before any code goes into production,
the right people get notified,
and the right people approve that code
before it finally gets deployed.
What's next in making sure that I continue
to automate the quality of this pipeline?
- Beyond manual approvers, we can also make sure
that we establish something called release gate.
This gives you automated monitoring in AI
to help make sure that your code is of high enough quality
before it goes from one release stage to the next.
Out of the box, we give you five release gates.
First, we'll go from the bottom up.
First, we have the Security and compliance assessment gate,
which uses Azure policies in your resource group
to help determine if a gate should pass or fail.
Next, we have the Query Work Item gate,
which uses a work item query
to determine if a gate should pass or fail.
Next, there's the Query Azure Monitor Alerts gate,
which uses Azure monitoring
to help determine if a gate should pass or fail.
Finally, there's the Invoke REST API
and Invoke Azure Function gates.
Now these two gates,
they're the extensibility points
where you can write your own code
to create your own custom gates
to make it do whatever you need it to do.
One example that I always show
is one that I did in a hospital recently.
Where here they had a rule where you could only deploy
into production after a document has been signed
and uploaded to their DocuSign server.
After deploying into QA,
and it's been approved by a manual approver,
the automated gate kicks in, which hits a function,
which checks DocuSign to say,
hey, has the document been signed?
Five minutes later, document still hasn't been signed,
so it did not push to production.
10 minutes later still hasn't been signed.
15 minutes later document finally was signed,
and now automatically the code will propagate
into the production environment.
- I like this, you've been able to automate these steps.
You're not having to wait for a manual person to intervene,
and you're still able to quickly get your code out
without having to compromise on the quality
or the safety of that code.
- Yes, and here's the cool thing.
You can use whatever monitoring options you want.
So in Azure, it makes sense to use Azure Monitoring, right?
But here's an example where I deploy code
and I actually use Dynatrace as my monitoring.
I deploy my code into the staging environment,
and once it's in the staging environment,
I go ahead and run a series of load tests,
and then, using Dynatrace,
determine if my response time is fast enough.
Here I did something wrong with my code.
Response time was too slow, so it blocked that release
and the bad code never propagated
to my production environment.
- Wow, that's a really cool use case of a quality check.
We saw you created a full CICD pipeline.
You took your code from GitHub,
deployed it all the way out to production.
You added critical, enterprise-grade features
for approvals, monitoring, and quality control.
- Yeah, and just remember Azure DevOps the product,
this is for any language targeting any platform
whether it's Azure, whether it's behind your firewall,
or even someone else's cloud.
- Great stuff, so how can everyone watching get started?
- It's really easy, try Azure DevOps for yourself.
If you already have VSTS, you know what?
You automatically have Azure DevOps.
If you don't, go to dev.azure.com,
and create yourself a free organization
and start creating your builder release pipelines for free.
And you know what?
If you're an open source project,
we will give you 10 parallel pipelines
with unlimited build minutes for Mac, Linux, and Windows.
- Well, thanks, Abel, for the great overview
and for joining us on the show.
Of course, keep watching Microsoft Mechanics
for the latest tech updates.
Thanks for watching.
(upbeat electronic music)