This is Part 26 of Azure tutorial. In this video, we'll discuss
azure deployment slots. Before that, let's quickly recap, what is azure app service ? We discussed
app service and the benefits it provides in part 18 of this video series. It's a platform
as a service offering and we use it to host web applications, REST APIs and backend services
for mobile applications. It offers several benefits like scalability that is both manual and
auto scaling, standards compliance like ISO, SOC, PCI etc. Easy security implementation including
support for external authentication providers like Google, Facebook, Twitter or Microsoft.
Support for containerization and docker. Devops optimization, deployment slots. In this video,
let's focus our attention on deployment slots. So, what are deployment slots? Azure deployment slots
are very useful. They allow you to run multiple versions of your application code on the same
infrastructure. Let's understand the use of development slots with an example. Let's say.
you have a web application with name mywebapp and this application is deployed in azure. By default,
it gets the URL mywebapp.azurewebsites.net. This is your production version of the application and
your users are able to access and use it. Now let's say, you have to make a change to your
application, maybe there is a bug that you're fixing or you're adding a new feature. The point
is, you're making a change to your application code and you want to test these changes in your
production like environment. At this point, you might be wondering, why can't we just test on our
local machine? Why is there a need to test this changed version of the application on the same
infrastructure as the production? Well, the simple answer is, to test how your changed version of the
application behaves on production environment. It's an opportunity for you to identify and
fix any infrastructure or environment related issues. One way to achieve this is by creating
a deployment slot and then deploy our changed application in that slot. For example, if we
name the deployment slot staging then we get this URL - mywebapp-staging.azurewebsites.net. The only
difference here is in the URL, we have the name of our deployment slot, staging in this case. Now,
let's see how to create a deployment slot in the azure portal. Creating the deployment slot itself
is pretty straightforward. Navigate to your app service in the azure portal. Notice, this resource
that we are looking at at the moment is an app service. We can tell that by looking at this
small text right here and under "Deployment" we have "Deployment slots". Now, here's the important
point to keep in mind, not all azure app service plans support deployment slots. For example,
this free app service plan does not support deployment slots. You have to upgrade to a
standard or a premium plan to add deployment slots. So, let's click this "Upgrade" button
and upgrade our app service plan. At the moment as you can see we are on this free plan - F1. Let's
navigate to the "Production" workload and then select this plan - S1 and click "Apply". Now,
let's go back to app service and then click on "Deployment slots". Again, notice, we still
see this message upgrade to a standard or premium plan to add slots. So, click this refresh button.
There we go, by default we have one deployment slot kudvenkatquotes and this is the production
deployment slot. Now, let's add a new slot. For that, click on this button "Add slot".
All we need to do here is provide a name for our deployment slot. Let's call it - staging
and pay attention to the URL here. Notice, we have the same URL with hyphen staging
in the URL right now. So, this URL goes to this staging deployment slot and we can also clone
our application configuration settings from an already existing deployment slot if we want to and
then click this "Add" button to add the deployment slot. There we go, our staging deployment slot is
successfully created. At the moment, we already have a version of our application code already
running in the production deployment slot and it looks like this at the moment. As you can see the
author name is displayed on the right hand side. What we want to do is change our application code
so the author name is displayed on the left hand side. To achieve this, all we have to do is change
text align value from right to left. Let's do the same in the alternating template as well.
We want this version of our application code to be deployed in the staging deployment slot. So,
for that, first let's get to the publish page by right clicking on our project name in the solution
explorer and then select this option - Publish. At the moment, as you can see we have just
one publish profile here and this publish profile deploys to the production deployment slot in
azure. Now, we want to deploy our application code to the staging slot. So, we need to create another
publish profile. We can create as many publish profiles as we want. So, to create a new publish
profile, click on this "New" button. Select Azure as the target and click Next. On this window,
select Azure App Service, click Next. Expand quotes resource group and then our app service
and then here we have deployment slots folder and we see our staging deployment slot. Select that
and then click Finish. Our application has a dependency on SQL server database,
because the quotes that we display on the web page are coming from a SQL server database. So,
we need to configure that dependency. Select azure SQL database and then click Next.
We see our production SQL database instance here. In a real world, we will point our staging
version of the application to a separate staging database, but to keep this example simple and in
the interest of time, let's select this production version and then click Next. On this screen,
provide a database connection username and password and click Next and Finish.
Notice, now in this drop-down list we have
two publish profiles. The first profile publishes to the production slot and the
second profile publishes to the staging slot. So, let's select this and then click Publish.
There we go, we now have two versions of our application code running in azure. On the left,
we have the staging version. Notice in the URL, we have the word staging and as you can see the
author name is displayed on the left hand side and on the right hand we have our production
version and again the author name is displayed on the right hand side. Now, we can even redirect a
percentage of our live traffic to our staging version of the application. At the moment,
as you can see 100% of the live traffic is going to the production slot. Now we can redirect a
percentage of this traffic to the staging version of the application. Let's actually do that.
Let's redirect 50% of the live traffic to our staging version. Let's save these changes.
Now, notice the URL, this is our production URL, we don't have the word staging in URL
and we see the author name displayed on the right hand side as expected. We've just configured
to redirect 50% of our live traffic to the staging slot. Now, notice what's going to happen when I
refresh this page. We still see the author name on the right hand side but then let's delete
these two cookies here so x dash m routing name and tip mix and then reload this page.
We still have it on the right hand side. Let's try the deletion again
and then reload this page. There we go, notice, now, the author name is on the left hand side.
So, this is being served from our staging slot. Now, let's change this to zero so 100%
of our live traffic goes to our production slot. Save changes. At the moment, in the staging slot
we have our changed version of the application. It gives us an opportunity to test our application.
Once, we are happy with the changes, we swap the slots staging to production and production
to staging. To perform the swap operation in the azure portal, all we need to do is
click this button - Swap. On this window, you specify your source and target. We want to swap
staging to production and production to staging, so click this Swap button.
There we go, swap complete. So, our new version of the app is now in production and the version
that was in production is now in the staging slot. The important point to keep in mind
is, azure warms up the production slot before the swap operation, so this means we get zero
downtime deployments, how great is that? Notice, now, the staging version displays the author name
on the right hand side and our production version displays the author name on the left hand side.
Now, here's another important bit to keep in mind, you can even undo the swap anytime you want. If
for whatever reason, you change your mind and want to revert the deployment to a previous version,
you can simply swap back again, staging to production and production to staging. Now, let's
quickly recap some of the important points about deployment slots. With deployment slots, you can
run multiple versions of application code on the same infrastructure. They provide a great way to
test your builds before promoting to production. By default, you get one deployment slot -
production. You can create multiple deployment slots - Development, Staging, Testing etc. You
can also route a percentage of live traffic to deployment slots other than the production
slot. Not all app service plans support deployment slots. Production deployment slot is automatically
warmed up just before the swap operation, so this means we get zero downtime deployments.
Traffic redirection is seamless and no requests are dropped because of the swap operation.
Swap manually through the azure portal or we can even automate this by configuring auto swap.
We can even roll back a swap anytime we want to. That's it in this video. Thank you for listening.