>> 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.
