>> Hi everyone! My name is
Damian Brady and today I'm going to be talking to
you about DevOps Best Practices for Azure and VSTS.
So I'm a Cloud Developer Advocate at
Microsoft and you can get hold of me if you
want to contact me about this topic or
anything to do with the VSTS or Azure.
My Twitter handle is
@damovisa and you can find me
Damo visa pretty much anywhere.
My team at Microsoft is the team
of League of Extraordinary
Cloud DevOps Advocates and you can get
hold of us on Twitter as well using that hashtag
#LoECDA or have a look at
our website to find out where we'll be and when.
Now the larger group of Cloud Developer Advocates,
you can also contact us on Twitter
and have a look at all of our profiles.
There are a lot of developer advocates with
a lot of different specialties.
Everything from Linux and Open Source
to .NET and DevOps of course.
Just have a look there's a lot of us and find
out when we're going to be in your area as well.
Now today we're going to be talking about DevOps.
So probably a good place to start is
talking about what DevOps is.
So at Microsoft we define DevOps as the union of people,
process and products to enable
continuous delivery of value to our end users.
Now there's a lot of parts to this definition,
but probably the most important ones
are the fact that it's not just about products.
So I'm going to be showing you
Visual Studio Team Services,
which is a Microsoft product.
But if you just implement that in your organisation,
you're probably not going to have a lot of success.
You really, really need the people and
the process to be on board with this as well.
If the people aren't bought into the idea of
continuous delivery of value or
the process doesn't support that either,
then you're not going to have a lot of
success where you need it.
And more importantly as well is that it's
about continuous delivery of value.
So value can be anything from
bug fixes to new features or even
changes to infrastructure to make sure that you
improve your availability style for your end customers.
So you want to do this continuously,
deliver this value continuously,
rather than every three months when there's
a release cycle or every six months.
As soon as it's ready for the user,
you want to make sure that you make it available.
So with that in mind you can
also think about DevOps as kind of
a four-stage process and a bit of
a cycle more than a left to right kind of process.
Everything from the idea
itself and your planning through to
developing that implementation testing it,
releasing it out to production and
then monitoring what's happening in production as well,
to make sure that that feeds back
into your planning cycle and that you can
fix things that go wrong and
introduce new features as soon as they're required.
So that's really important as well.
The next question really is why is it important.
And you can probably summarize this with one sentence,
which is that your competition is already doing this.
Even if you're an internal IT shop,
if let's say you take a month to release
a bug fix that took about ten minutes to implement,
during that month, you're
probably going to be losing customers.
If you have software directly to customers,
they might move to a competitor.
But even if your internal software,
your team is suffering for that month while you're
not implementing those features and fixing those bugs.
So the practice's of
DevOps and doing it properly allow you to increase
velocity and also reduce downtime when there is a problem
it means that you can deploy a fix for
that problem much much quicker than you could otherwise.
And then finally, it reduces human error.
So point-and-click errors and copy
paste errors and things like
that become a thing of the past.
Automation is very much a part of
DevOps and this helps you actually deliver
the value continuously and very quickly
without so many errors that you
might care if you're doing things manually.
So Microsoft Solution for DevOps is
Team Foundation Server or Visual Studio Team Services.
Now these are actually the same products
they have exactly the same path codebase,
except VSTS, Visual Studio Team Services
is hosted for you on the Cloud.
We put this in Azure for you and so you
don't have to worry about the infrastructure,
whereas if you want to install it yourself,
use Team Foundation Server and it's the same product.
It consists of a whole number of
features but this is a new Microsoft it's
changed from the old days and we're not
forcing you to use the entire suite.
If you're using like
GitHub for example for your source control,
you can absolutely continue to use that,
if you're using TeamCity or
Jenkins or something for your builds,
Octopus deploy or something like that for
deployments you can absolutely slot those in.
And in most cases VSTS will
integrate really really nicely
with those products as well.
So we're not forcing you to use the whole suite.
Now if you're deploying to Azure of course,
VSTS is kind of
your no-brainer solution is the one you want to go with.
The integration between VSTS and Azure is
really incredible and you'll see
some examples of that in a second.
Now probably the best way to
start with all of this is to actually show you
how you can build a pipeline using
VSTS deploying your application all the way to Azure.
So I have an application here
which is just an ASP.NET full
framework application and it's
actually in source control already,
we have this code in
Visual Studio Team Services
but I haven't deployed it anywhere.
I'm going to try and deploy that to Azure,
so let's jump over to
the Azure portal and I'm going to create a new website.
So let's do that here I'm going
to call it damo-techsummit.
Damo is already gone, that's great.
I'm going to use my CDA subscription.
I'm going to create a new resource group
I could deploy this to Linux as well,
it's an ASP.NET full framework application,
so that doesn't make sense.
We're going to put it on Windows instead.
I'm going to create a new App Service plan.
The App Service plan is really
just how much you pay for your application,
how much availabilities is there for you.
I'm going to leave Application Insights off.
We will look at that a little bit later,
but for a brand new application
there's probably not going to be a lot of data.
So let's create that web application
and this should only take a few seconds,
and then we'll be able to talk about how to
deploy our application to Azure.
So one of the ways that people might deploy,
is back in Visual Studio if you go to
your solution explorer right-click
on your application and go to publish.
Now if you've ever heard me speak
about anything and this is
something I really like to say.
Friends don't let friends right click Publish right,
this is fantastic for trying things out,
but as soon as you're working in a team with
a couple of people you probably don't want to
do this because so much depends on
your own machine and
your own setup when you do this Publish.
If you pushing straight to
production from your local machine,
if the tests haven't run properly or let say
your environment looks slightly
different than the production environment,
then this is very dangerous thing
to do you can bring production
down and impact all of your
customers,so we don't want to do that.
Let's jump back to the portal and have
a look at some of the options we have,
so let's go to our website here and
we can see right away we get access to
this url so this is
our web application running in Azure right now.
We'll say we got our start page
nothing deployed to it yet,
so some options for deploying
if we look back in the portal.
We could have a look at the FTP site
so we could actually copy things straight up to FTP.
Again, a little bit
dangerous because if you deploy
something bad, production is down.
We'll have a look at the deployment options section
here to see what other options there are.
We can deploy straight from our source code as well.
So let's just set that up quickly.
And we've got our code in Visual Studio Team Services,
but if you saw there's a whole lot of other options.
GitHub, Bitbucket, even Dropbox and
OneDrive if you have your source code there.
Now as in Visual Studio Team Services
it's in this account we just need to
choose a project and we've
got our Asp.NetFull application,
we're going to use the Master Branch and I'm not going
to worry about performance tests for the moment.
So let's set that up, now
what this is doing in the background
is it's configuring a connection
between Visual Studio Team Services source code,
the Master Branch and Azure itself.
And there's a really cool tool that's available to
you through Azure with websites,
called Kudu you can get to that if we jump back
to our actual application if we zoom into here,
if you just before Azurewebsites.NET type .scm,
this gives you access to the management portal for Kudu.
Now what Kudu does amongst
other things is it lets you put
your source code straight up onto
the website and then it will run deployment scripts.
Now by default it will detect
what application type you have we'll have found that I
have an Asp.NetFull framework
web application and it will have done
a deployment to make sure
that that gets compiled and actually runs.
We can see in here there's a whole bunch of
Json this is just the details of the deployment,
so we can see all of this stuff that's going on in Kudu.
One of the things which is going
on we've got complete equals false,
which means that the deployment still in progress.
Kudu lets you do some really cool things
like have a look at a PowerShell or
command line prompt and actually
navigate through the folders
that are there on your website as well.
We only care about the deployments at the moment,
so let's jump back and see what that looks like,
we can see that the deployment has completed now.
So we can drill in and see exactly what steps have been
run we can see it generating the deployment scripts,
running the deployment command and if we
wanted to we could have a look at those logs.
But once again there's a bit of a problem with this,
even if the deployment has succeeded in
this case this is coming straight from your source code.
There's no real opportunity
to test this before you go out to
production unless you have multiple
of these setup for different websites.
So if I checked in code or if I committed
code to my master branch that broke the build,
then production would be broken,
and we really don't want that.
So I'm going to disconnect this Kudu.
Git Sync here
and we're going to replace this
with something a little bit better,
which is this Continuous Delivery section here.
So let's go into this and we'll
have a look at what this does.
It will tell us the steps that it's
going to take when we continue
which is basically creating a build test and deployment,
deploying to a test environment if
we want and then approvals for
production and all sorts of stuff that
we didn't get with Git sync.
So let's configure this,
and once again we need to tell it
where our source code lives,
which using Visual Studio team services.
But again we could use
GitHub or an external or internal Git.
I want to choose my Team services
account which is dam-ms-demos.
It's chosen the project and the repository for me by
default and we're looking at the master branch.
So this is where the source code is.
We also need to tell it what it's building.
Now because we're building up
an entire continuous build and
continuous integration build and continuous deployment,
it needs to know what kind of build to create.
Unlike Kudu, it's not going to detect this automatically.
So we have to tell it what kind of application.
We have a few options here.
ASP.NET is the one we're using but it could be Node, PHP,
Python or even a static web app
if we don't need to do any compilation.
Now we're at ASP.NET,
so let's choose that.
I'm going to leave the load
testing and configure deployment steps
alone for the moment.
These are valuable but we're
just going to use the default for the time being.
So let's click on "OK".
I'm going to explain a little bit
about what's happening here.
Now our code lives in
Visual Studio team services and that's fine.
It could live on in GitHub or in a local repository.
But we need to run through
a couple of steps to get this out to Azure.
The first one is to build our application
every time there's a change to that master branch.
The second one is to take the output of
that build and then release that to a website.
We have a lot of control over where that goes,
but what's happening now is Azure is actually
talking to Visual Studio team services to
configure a build and then configure
a release so that everything's
set up for me so this just happens.
Now out of the box,
this is quite similar to the Kudu one.
It works in VSTS rather than in Kudu,
so we have a bit more control over it.
But out of the box it's really just picking up
every change to the source code,
building it and then deploying it.
One advantage out of the box is that if the build fails,
it won't try to deploy it which is
a bit of an advantage right away.
So this is completed.
Let's jump into the build definition
to have a look at what it's actually created
for us and you can see there's actually a
built in progress already.
Before we jump into that,
let's just go to the "Edit" page
and have a look at what it's created for us.
So right out of the box,
we can see it's doing a new Git restore building
our solution it's running
tests which is something Kudu didn't give us,
and then publishing symbols and publishing that
artifact backup to VSTS to be used later on.
Now like I said, we have full control over what
happens here so one thing I'm going to change,
I'm gonna change the agent that
actually gets used to build this.
Out of the box, you get access to
the hosted Visual Studio 2017 build
or a Linux preview or even
Mac these days if you want as well.
Or you can use your own private queue.
So I'm going to choose that one just because
I've got a pretty powerful machine behind
the scenes that can build these
things a little bit faster
and if I wanted to get my code from a different location,
I have access to GitHub,
even Subversion, Bitbucket or an external Git repository.
These are options available to me as well
and if I wanted to modify this build,
I could change the settings in the existing steps
or I could add new tasks and there's a ton of stuff here,
so.NET Core, Android, Ant, Docker.
Even Go now. Gradle, Grunt.
There's a whole ton of tasks that are out of the box.
And there's also marketplace tasks as well.
If you want to do something that's not in the box here,
you can download well
over 500 different tasks from
the marketplace to add to your project.
That's all I need to change at the moment so let's
just save that change to
the build and we'll have a look
at how we're going with that actual build itself.
It's still in progress.
So I can jump into that build and
have a look at what it's doing and we've
gone past the new Git restore
building the solution, running our tests.
And you can see on the right,
we get full access to everything
that's happening on the command line.
So nothing is hidden from you here at all.
If we drill into the summary of this bill now,
we can see our tests have
passed which is good because it's a brand new project
and we can even see down here
there'll be a link to the deployment in a second.
Let's just refresh that and have a look.
And down the bottom, here's
the link to the deployment that's happening and
we're already deploying to
what's named our production environment.
On the left we can see all of the associated changes so
because this was a project
that I've played with a little bit.
We've got all of the changes for this first build.
Will jump into the release and have
a look at what that looks like as well so
this is the continuous deployment released that
was set up as part of that Azure step.
The the Azure UI that we looked at.
Once again, we get all of
the console output if we wanted and we
can see that it's actually deploying
this Azure App Service right now.
Let's once again jump into the edit screen
for this release definition to see what it's done.
And we can see that we're picking up
the drop from that build definition and
there's a continuous deployment trigger
on this as well which
means that every single time there
is a new drop from that build,
we will trigger this deployment
to what's called our production environment.
We also have the option
of doing pre-deployment conditions,
which I'll get to in
a minute or post-deployment conditions
as well so we have a bit more control there.
If we look at what's actually
happening in that production environment,
there's one step which is just deploying to
an Azure App Service which will deploy our web site.
So this is quite simple at the moment,
but you'll notice that the connectivity between
Azure and VSTS is all done for me.
I don't need to set up any service principles
and things like that that's handled for me.
So let's have a look at this release and see if we've
completed and we can see yes there is a tick.
We can jump back to our website and just
verify that that's being completed.
And that will spin up a little bit
for the first time because this
is an ASP.NET full framework application,
takes a few seconds to spin up.
And we can see there's our ASP.NET web
application deployed through VSTS all the way to Azure.
Now this is great but you'll notice there's a couple of,
couple of things we've looked at.
There's a few different options that we've had for
deploying our web application. So this is great.
We've actually set up
an entire CICD pipeline
here for Visual Studio deploying to Azure.
Now the key things I want you to note here are that
this is available for any language in any platform.
Sure I'm doing an ASP.NET
full framework application right now,
but if I wanted to do PHP or Python or I'm even build
an iOS application and deploy
to devices in my organization.
All of these are available to
me using that build definition.
We saw how many tasks were
available and they kind of let you
do anything on Linux on Windows.
The other thing I want you to notice
is there's kind of a spectrum
of good to bad When it comes to deployments.
So the bad stuff or the things that I wouldn't recommend.
Obviously right-click publish.
But also things like copying and pasting to
production or even a manual push to
a remote Git repository
which is one of the other options you
have with Azure or manual FTP uploads.
These are a little bit dangerous
because you're writing directly under
production and so much
depends on what you're actually putting in there.
You don't get an opportunity to test very
much and it's a manual process,
which slows things down.
Slightly better is this idea of sinking
from Git and letting Kudu do our deployment.
But again, if I've introduced bad code,
that deployment is not going to work
and this site is going to be down in the meantime.
What we really want to do is build
an entire CICD pipeline with
Visual Studio team services
to get all the way out to production.
Now there are still some challenges with this.
It's not smooth sailing
and you'll probably have picked up
a couple of these in
the kinda hello world that we've done.
I'm going to look at a few in
particular approvals or an approval process to
make sure not everything goes all the way through to
production unless we're really happy with it.
There's also the idea of
downtime now we saw when we deploy
that application the first time we hit it
there was a bit of a spin up time for ASP.NET.
We don't want to do this in a production environment,
we want it to be available straight
away so we'll look at that.
And then finally the one I want to talk
about is monitoring just to
close that loop when it comes to
actually deploying our application,
having a look at what's happening with
it and then pushing out to production as
well to let us feed back
into what happens what we're going to do next,
the work that we're going to do.
That's really important too.
So let's attack this straightaway.
Let's talk about approvals to start off with.
Now there's a couple of ways that we can look at this.
Number one is we
probably don't want to do our deployment all the
way through to production without checking that it
works in a test environment first.
But even better than that,
we probably want to stop
any bad code from even getting to
that deployment stage or
even a build stage and we can
do that with Visual Studio Team Services.
So let's jump into our code section
and I'm going to go to the branches.
Part of code here.
And we'll see that at the moment we've
only got a master branch.
And that's okay, but it's a good practice
to do changes through a pull request process.
Now we can enable that, that's enabled straight away,
you don't have to set anything up to do pull requests.
But one of the really good features of
VSTS is Branch policies.
So if we jump into "Branch
policies," we can see that we can
protect this master branch in a number of ways.
I'm going to enable a few of these branch policies,
so I'm going to require a minimum number of reviewers.
It's just me and this team so
I'm just going to say one reviewer,
and I'm also going to check this check box,
which you should probably never check which is,
allow me to approve my own changes
which is probably a bad idea in general,
but for the purposes of demo we'll do that.
You can also make sure that
work-items are linked so people aren't doing
work without the actual tasks
behind them, which is a good idea.
The other one I'm going to check
is checking for comment resolution.
When somebody reviews my code,
I have to mark those comments
that they make as resolved to make sure that
the VSTS knows that I've read the message and
I've understood it and made
any changes that are required.
And then finally the one I'm going to point out but
not enable, is build validation.
Now this is incredibly powerful.
What this lets you do,
is before anything can be merged back into master,
it will have to pass a build.
I could choose a bill definition that will
compile my application, run tests,
do all sorts of stuff like that,
and only if those paths
will allow me to merge my changes back into master.
Now this is a really kind of
a practical example of the idea of shift left,
which is a DevOps principle.
Shift left basically means that you move the discovery of
any problems and the fixing of any problems as
far left in this process as possible,
if you're thinking about it as a left or right process.
As far left as possible,
is a really good way of making sure that you're
picking things up when it's the cheapest to fix them.
By making sure that you build before
you even merge that code into your master branch,
you can make sure that no broken code is
ever going to get compiled and pushed to production.
Let's save those changes.
So now, our master branch is a little bit more protected.
The other thing I want to do is
change our release process.
Right now, we're deploying
directly to our production environment,
as you can see when we go into the edit page.
I don't want to do this,
I want to go to a test site first.
So, let's just change this and make it Dev.
And then, my production environment
is probably going to look the same,
so I can clone this phase or
this environment to make sure that
we're doing the same deployment
to our production environment.
Let's call this one Production. Save that.
And what I'd probably end up doing here is
change this task to point to a different location,
so that Dev and
Production are pointing at different websites.
But there's another option available
to me as well which actually ties
really well into the next problem that we have,
which is the idea of reducing downtime.
When we deploy our application to production,
as much as possible we don't want to impact
people who are using the application right now.
We want to reduce this downtime to zero,
and we can actually do that with
some really cool features in Azure.
Let's jump back into that portal,
and we'll have a look at our website here,
and I'm going to click on "Deployment slots."
Now "Deployments slots" are basically,
an extra website that you get access to.
I'm going to create a "Staging slot"
here which is pretty common practice.
It's basically a new copy of our website,
and it allows us to deploy to that other copy,
and then just swap these slots
when it's up and running and when we know it works.
The advantage here is
that we are spinning something up ahead
of time and then just changing the DNS details,
so that instead of hitting production,
it's now going to hit what was staging,
so we're basically swapping those environments.
To get to our staging site,
we can, if we zoom into the URL,
type -staging or the name of our slot,
and you'll see that we have
a brand new website up and running,
there's nothing deployed to it yet.
All right, so we're going to change
our release definition
to enable us to actually use these slots.
If we jump back to editing our release definition,
I'm going to change my Dev phase,
and change the task here to deploy to our staging slot.
As a handy checkbox there,
I can choose the slot that I have which is staging,
and I'm going to add one more task here which is
basically going to spin up our application ahead of time,
so that we don't have to wait for
it when it actually gets deployed.
Now, this is actually
a task from the marketplace as well.
This is a community-driven task,
it's not one that was out of the box.
But I can do a couple of things here
in my deploy Azure App Service,
I can choose an App Service URL variable names.
I'm going to call this WebUrl,
and I'll copy that,
and in my smoke test,
it's asking for a URL to hit.
I'm going to use that URL from the previous step,
which means that if I change the name of
my App Service or the name of my website,
it's still going to flow through to that next step.
My Dev site now,
of my Dev environment in my release definition
would deploy to my staging slot,
and then spin that staging slot
up and make sure that it's actually
returning HTTP 200, that it's up and running.
If we go to production,
I don't really need to deploy anymore.
What I need to do is swap those slots.
So, let's remove this task
and I'm going to add a new task.
If I search for swap,
I get this app, Azure App Service Manage,
which is the slot swap as
well as a few other things with Azure App Services.
Let's jump in here,
we choose the subscription that we've got which is
the service principle that was
set up by Azure right at the start.
And I want to swap slots for this App Service that I've
got which is damo-techsummit.
I need to choose the Resource Group as well.
That's going to be the same name,
and then I need to choose where this swap is coming from.
It's coming from my staging swap slot
and at swapping with production.
And that's all I need to do.
So right now as things stand,
I have a check and a protection on my master branch,
so I can't actually make a change
without submitting a pull request
and making sure that those policies are met.
And then even when the build and deployment works,
it will go to my staging slot
and then it will swap into production.
There's one more thing that I want to do which is to
stop that from going to production until I'm ready.
If we jump into these pre-deployment conditions,
we can set a pre-deployment condition
for pre-deployment approvals.
What I'm going to say is that I
need to approve this deployment to production.
It'll go to Dev automatically,
but I have to say okay we're ready for production now.
Once again, I'm going to change something
that you probably shouldn't change,
which is requesting that the user
requesting a release or deployment should not approve it.
I'm requesting it, I need to
approve it because I'm the only person on this team.
That's going to make sure that I have a chance to
verify that everything's okay
before going into production.
If you wanted to do this automatically,
there's a new feature called Deployment Gates,
which allows you to do things like,
run an Azure function to make sure that it's
returning the correct things
before you promote to production.
You can even have a look at work items to make sure that
no automatic bugs have been
raised as a result of going to
your your staging environment.
This can be really handy for canary deployments as well.
So, if you're deploying to a small group of users,
if you get work items or
an Azure function or something like that that verifies
that those canary users are actually
successful and using the application correctly,
and then after a period of time
automatically deploy to production.
That's a really good way of doing it with these gates.
Now I'm going to disable that for the moment and
just stick with pre-deployment approvals.
We'll save that, and then I'm going to
go and make a change to my application,
and we'll see these disapproval process and
the zero downtime stuff working for us.
Let's make it a really simple change.
We'll call this, we'll change the title here,
ASP.NET with approvals and no downtime,
we'll save that, and I'll try and
commit this directly to my master branch.
We'll say new title,
we'll "Commit and Push",
and you should be able to see right
away we get an error when
we try to push it saying,"Failed
to push to the remote repository".
And then we can have a look at the output window
for more details,
we can see that it rejected that push
to master because pushes
to this branch are not permitted,
we have to use a pull request.
Let's do that, we'll jump
back and we'll go to our Branches,
and I'm going to create a new branch which is,
I'm going to call it dabrady/,
which is my handle.
And I'm going to call it dabrady/new-title.
So, let's create
that branch and we'll check it out automatically.
So, now our change belongs to that branch,
and I'll push that branch up to the server.
So, let's push this branch back up to VSTS.
What will happen here, which is really cool tooling in
Visual Studio is it will actually
prompt me to create a pull request.
It's realized that I'm doing this in a different branch,
now, maybe I want to merge that back into master.
So, we could click on that and it
will create a new pull request,
or we can jump back into
our Visual Studio Team Services instance.
Go to pull request in code,
and it's prompting me to create a new pull request
directly from here, so I can do that.
Let's create a pull request,
we'll call it new title, and create that.
And we can see right away that we
have this branch policies that we set up.
It's already there running and making sure that we've got
all of the policies met
before we can deploy the production.
Right now, we haven't approved it,
but we've got all the comments
resolved because there are none.
But if I add a comment, and just say,
this is not good, we'll say that
that policy is no longer met.
I have to mark that as resolved
before it comes back and says that this is okay.
If I wanted to approve it,
then I'd be able to merge that.
But I'm going to set up an autocomplete.
So, as soon as these policies are met,
it will auto merge.
I'm going to check that checkbox to delete the branch
because I don't need it anymore after the pull request.
I could squash those changes if I wanted to as well.
Let's just set this is the default.
And then when I approve this,
you'll see that it will automatically
close that pull request,
merge it back into master,
and finish that process for it.
If I was using a bit more complex branching strategy,
I might want to cherry pick that into a different branch,
maybe a release branch or something like that,
or revert that change if I really want to.
Now, the other cool thing is because we've got
a continuous integration build on our master branch,
we should have already kicked off a build
after that pull request has run.
And sure enough, we can see that there
is a build in progress.
Let's drill into that build and follow it through.
And we can see that it's already done on
our NuGet restore,
it's building our solution,
it's running our tests,
and its published the artifacts.
So, that build has succeeded already.
Once again, if we jump into the summary of this,
we should be able to see the deployments if we refresh.
So here's our deployment running,
and we can see this two environments now at the moment.
So, our dev release is cued to our dev environment.
And once again, we can see
all of the different things that happened there.
Once again, we get the entire build,
the process that's happening on our hosted agent.
And I can refresh this if I want details more quickly,
but what all we're really doing here is
downloading that artifact and then pushing that out.
So, if we jump into our actual application here,
this is our staging application,
we should see this one light up when it's
completed. So, here we go.
We've got our release, it's deploying
the Azure App Service,
and we can see all the details on the right,
and then when it's completes,
we should be able to see our staging site up to date.
So, we're quickly running our smoke test,
which means that we'll hit the application,
and then, once it gets an HTTP 200,
which means that ASP.NET has spun up for the first time,
it will be ready to go in our staging site.
Let's just refresh this to see if we've
got more details here.
Smoke test is still running,
but that will finish any second.
And in our staging site,
we can refresh this and we can
see that we've got our new change,
ASP.NET with approvals and no downtime.
Now, the cool thing here
is that this is the staging site,
but we've stopped short of going to production.
And in fact, production is still
running with everything that was there before.
And if we go back to our release,
it stopped it ahead of time to say,
there's a release for
our production environment that's pending.
So, this has stopped at my pre-deployment approvals.
If I approve this,
then we'll see this start to deploy to production.
Now, remember, we're not actually
moving anything to production here.
All we're doing is really swapping those slots over.
And you can see in our Azure portal again,
if we jump in our continuous delivery page,
we can see not just that first thing where it's
set up the continuous delivery and triggered the build,
but we can see what
actually running in production right now.
We ran release nine into production.
We're actually running one at the moment, you can see.
So, we get this traceability right from Azure as well.
Back in our web application,
if we just start refreshing this and
like visiting the pages around,
just to demonstrate that this is still available to us.
We have our web application with the old code in it,
but it's swapping that slot at
the moment, and at some point,
we'll just get this switchover
between staging and production.
So, it's still responding.
We're still getting our old site
because that switch is still happening.
But at some point in a couple of seconds,
we should be able to get our new application.
You can see there, there was no actual downtime.
The site was responding constantly,
but just at one point,
we swapped over to our other application.
Which is really cool, we've lost that whole problem
with the production downtime while we do a deployment.
Now, there was one more issue
that we were going to address, which is monitoring.
Now, because I just created a brand new web application,
this is probably not going to be very interesting,
there's not going to be a lot of
traceability apart from my clicking around us then.
So, let's look at an application
that's already been set up
with Azure and with Application Insights.
And that's the Smart Hotel application.
We'll go to that home page,
and we should be able to see,
this is our hotel website.
If you're watching Connect or one of those events,
you would have seen this come up.
One of the features of Smart Hotel is
the ability to upload a picture of a pet,
and find out whether that pet is able to accompany you.
So, let's go to our images.
I'm going to upload my picture of a dog,
and it's going to upload that image to Azure.
It's going to analyze it,
to find out what kind of animal it
is and then it's going to process
and tell me whether that dog can arrive in my hotel.
And it looks like a dog, and it's accepted.
I can bring my dog with me.
But if I choose a cat,
it's going to upload that image,
it's going to analyze it,
find out that it's a cat,
and tell me that I'm not allowed to bring my cat in.
Now, personally, I think that's a bit of a bug.
We should really be accepting
pets of all shapes and sizes.
This is a personal opinion.
But because I'm able to add
these bugs and things, I can do that.
Now, Smart Hotel is also in Visual Studio Team Services.
And if we have a look at my dashboard for Smart Hotel,
we should be able to see that I currently have
no tasks assigned to me. There's nothing here.
What I would really want to happen is as
a result of that request to go and get a cat,
I want to tie this back into
a new task in Visual Studio Team Services.
And so I can do that.
If I jump into my Application Insights portal
for my Smart Hotel site,
I should be able to see all of the different requests and
things that have happened
while I've been visiting that site.
Everything's traced for me and I
can feed that stuff back into
Visual Studio Team Services to
close that loop we were talking about before.
So, let's drill into all of these server requests.
And we should be able to find my requests.
There we go, Pets/GetUploadState.
I just happen to know that is the URL,
that gets that information.
So, this is probably a good context
for a developer who wants to fix that bug.
We can see all of the requests and things like that.
Let's drill into this one,
which looks like the most recent,
and I can see exactly what was happening at that time.
So, we can see the actual request,
the response, how long it took.
We can even see all of the remote dependencies.
So, we can see three calls to Cosmos DB here.
So, we can actually drill really,
really deeply into what
happened as a result of this request.
Now there was a problem with this,
this is a really good context for the developer,
so I'm going to add a new work item.
Now, this is linked back to VSTS,
we're closing this loop here.
I'm going to say, cats should be allowed,
and I'm going to assign this to me.
And again, we can see all these details,
we can add anything else to this if we want,
or just click "Okay", and
let that create a new work item.
Back over in my dashboard in Visual Studio Team Services,
if I refresh this,
I should be able to see I now have a task assigned to me.
It's a bug saying,
cats should be allowed.
I can drill in, and go down to
my repro steps which have already been created for me,
and even right at the bottom,
I get this deep link back into that page that I was
at before showing me
all the details of what has happened.
So, as a developer,
I have a huge amount of
information that can help me fix this bug.
We've close that loop
between what's happening in production,
and gone all the way back to planning and to fixing bugs,
which is really, really powerful.
So, we've looked at these three challenges that we have;
approvals, downtime, and monitoring.
And you can solve these in a number of ways.
Approvals, you can solve with
branch policies to make sure that
poor requests gets submitted and
things don't go straight to production.
Pre/post-deployment approvals to make sure,
in my case, that I checked and said,
this is okay to go to production.
Or if you want to do that automatically,
you can do it with deployment gates.
We reduced our downtime by using deployment slots,
deploying to a staging slot then swapping.
We looked at monitoring with Application Insights,
which can feed all the way back
into Visual Studio Team Services,
to close that loop and actually feed
our production metrics back into our planning phase.
If we have a look at DevOps as our cycle,
planning can come from
our tasks that we've decided on ahead of time,
but also from our monitoring and our production metrics.
Development is a little bit
smoother and we can make sure that we can
approve changes before they get
to production into a release.
Our release is a little bit nicer as well,
because we don't have downtime
in production when we deploy.
And once again, when
monitoring everything that happens in
production to feed back into that planning phase as well.
When you're actually doing the deployment,
you want to make sure that you're going all the way to
the right with this CI/CD pipeline.
But you can go further than that,
and you can do things like branch policies,
pre/post-deployment approvals and gates like we've seen.
Use deployment slots to make sure that
production that has no downtime,
and Application Insights to feed
that information back again.
So, this is really where we want to be,
and VSTS and Azure allow
us to do this in a really nice way.
So, thanks everyone for joining us.
I hope you enjoyed those demos
and got something out of it.
And feel free to contact me on
Twitter if you have any questions.
Không có nhận xét nào:
Đăng nhận xét