>> Hey friends, how would you like to avoid
cold starts when updating your production apps or
use real production traffic to run
experiments without impacting all of your customers?
You can have all that and more with
Azure App Service deployment slots and testing in production.
Byron Tardif is here to show us how it
works today, on Azure Friday.
[MUSIC]
>> Hey friends, I'm Scott Hanselman and
it's another episode of Azure Friday.
I'm here to talk about one of my favorite things,
Azure App Service. How's it going Byron?
>> It's going good. Thanks for having me Scott.
>> Yeah. I've actually been using this,
so I'm excited to see some of
the new improvements and stuff that you've got to show me.
Cool. So yeah, we're going to talk about
deployment slots and how you use them with testing in production.
This demo is a little bit more complicated than what I usually do.
>> Good.
>> So let's see. Let's hopefully everything goes as planned.
>> All right.
>> So I have this app that I have set up beforehand,
and what I did here is just a very simple app where
I have aggregated some of the videos that we've done in the past.
>> Oh, cool.
>> So if this loads, we'll see all of
the different App service-related videos that
we have and we have a little bit of the Azure Friday logo,
and that's about it, very simple.
The other thing that I have done is I
have prepared a staging slot.
For those people that are not familiar with staging slots,
this is a feature of App Service that lets you
create basically like a sister site of your app.
This is where we recommend people do all of their deployments.
So when you're changing codes,
you don't want to affect life traffic in production,
you want to do all of your tests
here and then once you're confident with it,
then you can put it into production.
So right now if we take a look at that app,
we'll see that it has basically exactly the same.
The only way that you can distinguish this right
now is if you go look at the URL.
So here we have Azure Friday-stage
and if I switch over to the other one,
it's just the naked Azure Friday domain.
So it's usually the
whatever.Azure Websites.net and you
add hyphen and then the name of the slot.
>> The name of the slot.
>> You said stage, I means it's staging,
it could be development testing, production, whatever.
>> You name it whatever you want.
So what I'm going to do now is I'm
going to make them look a little bit different.
So here I'm going to show another feature that we don't
usually talk about for Deployment Center,
and that is the ability to
move forward and backwards in your commits.
So you see here,
this is basically deployed from
a source code that I have in GitHub,
and what I have here is I'm pointing
to this commit which is not the latest.
So now, what I'm going to do is I'm going to
click on the logs and go to redeploy.
So this is basically going to move the pointer from
this commit to the latest commit,
and it will automatically move the bits forwards.
One of the things that you can do is right now I'm moving forward,
but you can always move back.
>> That's a really important thing and I liked that you
pointed out that it doesn't get talked about a lot,
because this is a super useful feature
because you'll find yourself
accidentally putting something into staging or
production and your first impression might be,
"Oh, I need to go and put in a commit right
away to move forward to fix that."
That's an important thing to do,
but ultimately you could get into Azure and just back out.
It's effectively control Z.
>> Exactly, on your deployment
>> On your deployment. Which is huge,
and then later take your time and fix your commits.
>> Exactly. What I'm going to do now is I'm
back into the staging slot and I'm going to reload,
and now we have a little bit different version of the code.
So now I have all of these Twitter followers,
and here's where I see my life goal to one of
these days not be
a rounding number compared to your Twitter followers.
So now the next thing that I'm going to do is I'm going to
go into configuration because this
is another important thing to call out.
You can have different versions of your code
and you can also have different versions of your configuration.
>> Yes.
>> So in this case,
I'm going to edit multiple settings.
So I'm going to use Advanced Editor,
and what I'm going to do here is I'm
just going to remove that underscores.
>> I noticed there when you were in that JSON,
it says slot setting true.
>> Right. So that means that this is
a setting that will stay with my slot,
and it will not move to production.
>> Okay. You could have lots of
different settings and certainly people have
rich and deep configuration,
and you can decide which ones are slot specific and
don't jump when you swap,
and which ones do.
>> Exactly. So the canonical scenario
is we sometimes have people that want to target
a specific database when they're doing staging so
they're not modifying production data.
You can add that declaration as well to connection strings.
So that's where it becomes very useful.
>> With my sights on both Hanselman.com and Hansel minutes,
my podcast, I use ASP net core underscore environment.
I make the name of my staging slot match my environment
so that when I wanted Hanselman-debug,
I'm running a Debug Build,
or if I'm on staging,
I'm using my staging features and I can even put
a watermark to indicate that I am on staging.
>> Exactly. I don't know if you've ever
wondered what the Azure Friday would look like green.
>> Constantly.
>> Because we're Emerald City, right?
>> That actually works.
>> That's one of the things that I did with
the environment variables is I set
this to basically colorize it to green,
and it also did
another very subtle change which is
it made the logo a little bit bigger.
>> Okay.
>> So now we have things that look very
different in production versus stage.
So the next logical step would be, "Well,
how do I make sure that what I have in
stage is working properly and it's not going to break?''
One of the things that you can do is
you can configure testing in production.
So in order to do that,
I'm going to go back into my production slot.
Over here we have this UI that is built right into
the deployment slot's feature.
This used to be a separate feature that was in separate menu item.
So if people have used it before,
this is where it lives now.
Traditionally what we would tell people to do is basically
start with a one percent traffic going to that slot,
where you start dripping a little bit of
production into that slot but for the sake of the demo,
let's go 50-50 and take a bet.
>> What's so interesting about this is I can tell you
that in the late "90s and in the early 2000s,
we would literally fly a consultant
in from the company where we bought the load balancer.
You would buy a load balancer and they would
teach you how to do this stuff.
Now it's a series of text-boxes in a button,
and what this does is it puts so much power in
the hands of an individual
that only big companies used to have before.
I mean, I'm just one person running my little blog in
my podcast and now I can do sophisticated routing
and test staging into production and then I can even write
PowerShell scripts and slowly ease it to a 100 percent.
>> Exactly.
>> It's amazing.
>> All of this is automatable,
because it's exposed through the Arm surface.
That's one of the powerful things of App Service and that's
the philosophy behind how we do things.
We want to make sure that this
complicated scenarios become turn key.
>> You just deleted a cookie which we
didn't have an affinity cookie,
right? A sticky session cookie.
>> That was actually the TipMix cookie.
I'll explain that in a second.
Right now we're going to take bets.
When I reload, this is my production app with the production URL.
Do you think that logo is
going to be green, or is it going to be Blue?
>> 50/50.
>> 50/50. So let's reload.
You're going to see that what happened here
is or tip mixed cookie has a value of 83,
which is greater than 50.
So therefore it's going to stay in production.
>> That's clever.
>> If I delete this cookie,
and reload again, we might need to do it
two or three times. There we go.
>> Would it have stuck there? Once that cookie gets set,
because you don't want someone within
the context of a single session,
to dance between the two.
It's that first one, so that's where that cookie
acts as a tip next and also as a kind of an affinity.
>> Exactly.
>> If I go to my staging slot,
nothing is changed here,
I'm just routing traffic to it.
>> Okay. So when you go to the staging slot,
with the staging URL,
it's staging because that's what you asked for.
>> Exactly.
>> Testing in production doesn't
change staging, it changes production.
>> Exactly.
>> Now, the other thing that is important is
that people sometimes have outside in monitoring,
and we wanted people to target always
production and never fall into one of these experiments.
>> That's a great point because I might go and set up an alert,
and that alert is telling me that production is down,
but I don't need to know if staging is down.
>> Now, this is more like you're
validating the HTML that comes out of production,
so it's a little bit more sophisticated,
and if there's a change there,
you don't want it to trigger unintentionally because you're-
>> It would come off as a flaky
because it would sometimes be wrong.
>> Exactly. So one of the ways to do that
is I have this little dashboard setup to help me.
I'm going to hit this "Prod" URL,
and I'm going to call out something
that's a little bit different here.
So you can force yourself to be routed to one of
your experiments by defining this extra query string parameter.
So right now, it says XMS routing name equals self,
and this always targets production.
But if I give it the name of the slot that I want to hit,
so in this case I named it stage,
it will rob into state.
>> Okay, so self means whatever the prefix in the URL is.
In this case, you could say
self if you're onstage and it would stick on staging.
>> Exactly.
>> I see, and that overrides.
>> That overrides any tip rules that you have.
>> Okay.
>> So this is very useful when you're
doing test or automation and you
don't want your testing and production to interfere with that.
>> Okay, so then if I were going and
doing whether it be Selenium tests
or other tools to go and check the actual content and I want
to ensure production, that would stay there.
Now once I put that URL that URL got query string in.
Does that stick or do all?
>> You need to include it with every request,
because otherwise it falls back into
the routing rules and testing and production.
Then,one final thing that I want to show you is,
let's say we've done the test, we've validated everything.
So now, what we want to do is we want to say,
hey the- what we had in staging wasn't the right thing to do.
The green icon translates to more followers or more viewers,
but maybe the logo was nicer smaller.
So let's go tweak some of those app settings,
so that they will move with your code.
So like you called out earlier,
there were some app settings that were- sorry,
I'm not in the right slot.
>> This is a really important thing to point out, right?
You're in production, you're going to switch over to staging,
and then you'll notice it says,
now stage at the corner there,
and I catch myself sometimes as
well just double-checking where I'm at,
and what's nice is,
you've changed the feature by the way
testing and production only works in production,
you can't accidentally do it from staging.
>> Exactly.
>> As a user of the product I
noticed that and I found it very helpful.
>> Yeah we don't want people basically going
on routing rule loops.
>> Indeed.
>> So what I'm going to do is I'm going to say,
yes the color is something that we want promoted into production.
So I'm going to unpin it from stage.
>> All right.
>> But the layout,
we want to keep the layout with a smaller logo.
>> We're still testing that feature.
>> We're not satisfied with it,
we might want to tweak it.
So I'll save that,
makes sure those changes are applied,
and then now at this point I'm ready to perform a swap operation.
So the swap operation is basically what promotes staging
or whatever slot you want to call it into production,
and we do that through DNS.
So there's no redeployment,
there's no changing of the bits,
and this is important because we can keep any active session
going to the bits that they were
using as it transitions into staging.
>> So because there's that affinity cookie,
anyone who's in the middle of
work are not going to notice this change.
>> Exactly.
>> That's cool.
>> Any new connections can come into
the new bits but now in the production slot.
So to do that, I'm going to go over here to overview, start Swap.
>> I love this new UI, the new UI on Swap makes it really,
really clear what's happening.
>> We put a lot of work to make sure that it was very
clear what direction things were moving,
and what was going to happen once you swapped.
So you can see that there's changes,
now we're going to have the color you promoted,
and it points out the old value versus the new value,
and it makes it really really clear,
and it gives you a moment there to validate
everything to make sure that you don't make any mistakes.
>> So this is going to take a couple of seconds
while we do the DNS trickery.
Sometimes we can start hitting an
earlier even before the UI is done.
>> While that's happening, I want to point out that,
you have this feature,
if you're using App Service,
this isn't a thing you need to upgrade to,
I've got a basic,
I've got this ability of you have a feature of,
you have a version of App Service that supports Slots,
you have testing and production.
>> Exactly. This works both on Windows or Linux,
it also worked for our Docker based offering as well.
>> Really?
>> So it's across the board,
which goes back and forth with that philosophy of
App Service which is, we build it for everybody.
>> Right. Yeah, so you have this feature now
and I'm actually going and deploying into GitHub,
then I build on Azure DevOps,
I deploy the staging,
I validate, and then I hit "Swap."
Again, that's big company sophistication, and I'm one person.
>> There's people leaving the DevOps stream right?
>> Oh yeah, it really is.
>> So here we go. Now we have production.
>> With a new green logo.
>> With a new green logo but a smaller size.
>> Fantastic. Testing and production,
swapping, this is something that you have right now.
I would encourage everyone who's using
App Service to get on board and check this out,
and really think about how it can affect your workload.
All right, I am learning all about the great new features,
and fun stuff that you can do with
Azure App Service today on Azure Friday.
[MUSIC]