18 hours 58 minutes
Welcome back in this episode, we're gonna take a look at it. Another feature inside of our Web APS called Deployment slots.
My objectives include for you to just understand deployment slots. And then we're gonna jump out to the Azure Portal and demo how they work
when working inside of the azure app service plans Standard premium, Nice, elated tears. We have the option of using deployment slots.
Deployment slots are a separate area where you can pull your Web app in order to test it before putting it into production.
This lot is outside of the production environment and has its own host name for access.
This allows for valid any changes before putting the Web app into production. And when the time comes, you can swap slots with the production one to make it live.
The previously stage slot now contains the former production code. So if there is an issue, you can easily swap back
when working with our deployment slots in our different versions of our applications, there are some things that are gonna be swapped and other things that are not when this action is performed. Some of the things that are swapped includes like the framework version 32 or 64 bit or Web sockets upsetting and connection strings are also going to be swapped,
but you do have the option of making these sticky
meaning. Your production slot may have a connection strength that points to the production database, and you don't want this swapped whenever you make this action happen. Other features that are swapped include handler map ings, public certificates and Web jobs content.
Here's some of the things that aren't swapped, such as the custom domain name or scale settings, and I don't want you to think about that for just a second. You may not want scale settings from your test or deaf stage to be swapped over to production, because maybe you don't care about auto scaling inside of your staging environment
because that's all it is. It's just a staging environment where you're testing the application code.
Other things include Web job schedulers, always on settings and our diagnostic settings. To understand this concept a little bit more, listen about to the azure portal created deployment slot and swap it out with an application
back inside our Web application under deployment. Let's like deployment slots
and right now we just have our production one. So let's click on at a slot,
and I'm just gonna name our slot stage.
And when creating a slot, we do have the option of cloning it from our existing production one. Right now, I'm just gonna slight Do not clone and go ahead and add.
Now that we have our slot created, let's go ahead and select it.
Have you see it's gonna take us to an overview page that's very similar to our production slot.
And right up here we have another your L that matches the name of our Web app, but it has dashed stage to match the slot that we're looking at.
Let's go ahead and click on browse.
As you can see, the staging slot has the default app, just like we saw when we first created her Web app.
Let's go back to our Web app.
So let's say I have some new code that I want a stage and verify it works before we put it into production,
just like we did in the last episode. I'm going to use FTP to send our code to our deployment slot here, so let's go back to the deployment center, scroll down to FTP
and look at our dashboard.
And I'm gonna grab our end point and credentials because these are gonna be different than what we have in production.
I also need to go back and turn on F T. P s inside our application settings.
Here I have the code that I downloaded earlier from get hub with our basic hello world application.
And here what I'm gonna do is just make a small change inside a V s code.
And instead of saying hello, world,
we're going to say hello, Cy Bury a Z 300 students.
So I'm gonna go ahead and save this.
Let's bring back our FTP client.
Let's create a new session.
I'll input the information I saved earlier,
and I'm gonna copy over our updated application,
and I need to delete the default page
back in the overview. Paige, let's go ahead and restart our application.
We'll browse to it again,
and here on reopen it. We see our updated application. Instead of saying hello World were saying Hello, Cy Bury a Z 300 students
and we know we're in our staging slot by the Earl has dash stage at the end of the name of our Web app.
So let's go back to the portal.
Let's pull up the production version of our Web app right now.
Remember, it's still just says Hello world.
Here we have our source lot, which is the stage and then our target. So we're gonna be swapping stage and production. So let's go ahead and click on Swap.
Now that our swap is successful, let's go ahead and click on clothes.
Let's go back to our production girl here and refresh.
We can see where the text has been updated with what we previously had in stage.
And if we go back to our staging app
and notice the Aureole, it has dashed age in it and we refresh.
It goes saying Hello world, which was our previous production version.
So I hope this makes sense and shows how you can stage your code, test it live, and then swap it with production in order to minimize any issues or downtime.
And if we needed to, we could immediately go back
and we could select swap again just in case there was an issue with the version. We just deployed.
The main point of swap is just understanding how it works and then knowing that some of the settings are swapped and are not swapped whenever you do so in some settings can be configured per slot, such as a connection string to a database. Let's say in your staging deployment of the application
it was connected to a staging or development database. You wouldn't suddenly want this one to become your production.
So you may want those connections to be sticky to the slot that does it for a demo. Let's jump back to the slides and wrap this up.
That does it for some of our azure app, Service's and Web app concepts coming up Next, we're going to jump into something else with an introduction to containers. See you in the next episode.