We have two web APIs hosted on azure for staging and production.
And we are consuming those APIs in mobile app where we provided which API should be used.
Right Now we are testing with staging app with staging mobile app.
If we do production app deployment and do swap slot from staging to production, does it will affect the staging app.
We have 2 different versions on hockeyapp staging and production mobile app. After swap slot does staging app will still point to staging API?
Should we standard API publish method.
Any help on this appreciated !
Slot swap switches the apps to the other slot.
So the app version in production will be running in staging and the one which was running in staging is now in production.
In my opinion you are using them a bit wrong here.
The purpose of deployment slots is to allow a "staged deployment" where new code can be published to the slot without bothering production, and then hot-swapped with minimal downtime.
What you really need is a testing environment, which you target from your testing app.
When deploying you deploy to staging and then swap to production.
Related
I have 3 App Service slots in Azure:
ExampleName (Production)
ExampleName/master
ExampleName/staging
CI/CD is configured this way:
on push to branch 'master' deploy to 'ExampleName/master' slot
on push to branch 'staging' deploy to 'ExampleName/staging' slot
I read about deployment best practices in Azure docs and they say that:
Continuous deployment should never be enabled for your production
slot. Instead, your production branch (often main) should be deployed
onto a non-production slot. When you are ready to release the base
branch, swap it into the production slot.
I am new to this and quite confused about which settings should the "ExampleName/master" slot use before swapping slots? Should it use the production database and other services? Or it should use the ones from the staging environment?
Since the version of the already running app in the production slot can be different from "/master" one I am thinking that it shouldn't use the production one, but don't know if I am right or not.
You should use different app services for your prodcution and non-production workload. Because behind the scene they use the same resources. So making stress test on your non-production slot you may take entire site down.
The prhase prodution slot and stagind slot doesn't refer to environments. They just saying that one slot is main and serve traffic. It is used to minimize downtime. So first you may publish your app to staging slot, you can make small tests to be sure that all is fine and swap slots. But this is not designed for becoming and environment.
In azure you can have slots that you can deploy your web app to.
For example you can have Production and Staging slots.
You can deploy to Staging then test if everything is OK and if so swap Staging with Production slot.
I believe that behind the scenes those slots are just 2 sites in IIS.
My idea is to just swap bindings and rename the websites so the Staging slot/website will get http://prod-superapp.com binding and the Production slot/website will get http://stg-superapp.com binding then rename Production website to Staging and Staging to production.
The last step is needed so that when we deploy the next time we deploy to the Staging slot again.
Can you think of anything better than this? Do you find any problems with that approach that I am currently not aware of? I know that there can't be two site with the same binding running at the same time so that scheme will have some downtime while the whole process completes.
I have a working app service named "matanwebserver" over a subscription in Azure.
This is a website that I am working on. I work with Visual Studio and I wrote my code inside this app service in Visual Studio.
Now I want to create an Integration site so I can test my code before publishing to the production site.
For that, I created a new app service in azure under the name "matanwebservertest" and I want to use the code I wrote for "matanwebserver" over the new app service that I just created.
I could not find any source which provides a solution, so thanks in advance.
Added some screenshots for a better understanding of the issue
In Visual Studio I do right click on the web app which is called "MatanWebServer" and choose "publish".
Then I choose the new web app that I just created on Azure portal which called "matanwebserertest", and publish successfully.
enter image description here
This is the original (production) website. which its address is http://matanwebserver.azurewebsites.net
enter image description here
After publish to the matanwebservertest web app, I expect to see a "copy" of the original site, but it seems like nothing is there.
enter image description here
To get the current app cloned to the new one, have a look at the 'Clone App' option.
What you're trying to do feels like a perfect example to use for using Deployment Slots Please refer to Set up staging environments in Azure App Service.
When you deploy your web app, web app on Linux, mobile back end, and API app to App Service, you can deploy to a separate deployment slot instead of the default production slot when running in the Standard or Premium App Service plan tier. Deployment slots are actually live apps with their own hostnames. App content and configurations elements can be swapped between two deployment slots, including the production slot. Deploying your application to a deployment slot has the following benefits:
You can validate app changes in a staging deployment slot before swapping it with the production slot.
Deploying an app to a slot first and swapping it into production ensures that all instances of the slot are warmed up before being swapped into production. This eliminates downtime when you deploy your app. The traffic redirection is seamless, and no requests are dropped as a result of swap operations. This entire workflow can be automated by configuring Auto Swap when pre-swap validation is not needed.
After a swap, the slot with previously staged app now has the previous production app. If the changes swapped into the production slot are not as you expected, you can perform the same swap immediately to get your "last known good site" back.
I heard that there will be no session time out happens when the deployment switch happens in Azure from staging to production. Is my understanding correct?. If so how Azure handles internally this switch?.
The answer depends on what switch form staging to production you're talking about. Because you could use Deployment Slots like this, but it is not recommended to have a full-blown Staging environment as a slot on your App Service. Since these slots run on the same App Service Plan as Production, heavy load on Staging could hurt Production performance.
I tend to think of it more as a 'Pre-Production' environment using a Deployment Slot where you can do some last checks (smoke test) before you release the new version of your application into the wild.
I would think sessions are managed internally since the two slots run on the same App Service Plan, making this a relative simple scenario.
Documentation
Deploying an app to a slot first and swapping it into production ensures that all instances of the slot are warmed up before being swapped into production. This eliminates downtime when you deploy your app. The traffic redirection is seamless, and no requests are dropped as a result of swap operations.
Find more information about using slots here: Set up staging environments in Azure App Service
I have a web app in ASP.NET Core RC1 in production and deployed in Azure with thousand of users using day a day.
I'm now upgrading my web project to RC2, following the tutorials I have found on Google (for example: Scott Blog, Official Doc, Tutorial1, Tutorial2, Tutorial3)
I need deploy the version RC2 when I have finished the upgrade without lose service to my users.
Do I need to create a new web app for the RC2 version or can I deploy in the same web app?
What is the way to implement that?
Thanks.
You can use Azure Deployment Slots. Develop and test your web application on you local, push it into the Staging slot. If it works fine there just swap the Staging Slot with the Production Slot. If the test fails there, don't worry, your actual application will still be running in production. Swap them carefully.
If you are using a storage with your web app, create a test (if possible) database in Azure for Staging Slot. If database is not an issue, you can use the same database with Staging and Production. Make sure that it works fine on your local system first.