A must read for all Developers is the following eBook Building Real World Cloud Apps with Azure: Best practices for DevOps, data storage, high availability, and more, by Scott Guthrie, Mark Simms...
This book explains 13 patterns and practices that can help you be successful developing web apps for the cloud.
CI means that whenever a developer checks in code to the source repository, a build is automatically triggered. Continuous delivery (CD) takes this one step further: after a build and automated unit tests are successful, you automatically deploy the application to an environment where you can do more in-depth testing.
Generally we recommend that you do continuous delivery to your development and staging environments. Most teams, even at Microsoft, require a manual review and approval process for production deployment. For a production deployment you might want to make sure it happens when key people on the development team are available for support, or during low-traffic periods. But there's nothing to prevent you from completely automating your development and test environments so that all a developer has to do is check in a change and an environment is set up for acceptance testing. for more details see https://docs.microsoft.com/en-us/aspnet/aspnet/overview/developing-apps-with-windows-azure/building-...
For more information on the continuous integration and delivery features of Azure DevOps Services, see the Azure DevOps documentation.
If you're looking for a turn-key project management, team collaboration, and source control solution, check out Azure DevOps Services. Sign up at Azure DevOps Services.
Simplify and speed up the DevOps process with Azure DevOps services. Azure DevOps Server Labs available now, you can learn how you can remove barriers between teams, encourage collaboration, and improve the flow of value to your customers. Simply Start Learning the labs will help you to get started with Azure DevOps services to automate software delivery and meet business needs. See https://azuredevopslabs.com/ for full details.
When you deploy your web app, web app on Linux, mobile back end, or API app to Azure App Service, you can use a separate deployment slot instead of the default production slot when you're running in the Standard, Premium, or Isolated App Service plan tier. Deployment slots are live apps with their own host names. 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:
Each App Service plan tier supports a different number of deployment slots. There's no additional charge for using deployment slots. To find out the number of slots your app's tier supports, see App Service limits.
To scale your app to a different tier, make sure that the target tier supports the number of slots your app already uses. For example, if your app has more than five slots, you can't scale it down to the Standard tier, because the Standard tier supports only five deployment slots.
Within the Azure Portal (https://portal.azure.com) you need to take the following steps:
The following Microsoft Doc has a full walkthroughs of developing deployment slots https://docs.microsoft.com/en-us/azure/app-service/deploy-staging-slots
Before creating deployment slots you need to have a useful pattern. In my opinion it is best to use a deployment slot as a pre production environment. So in my case I use pre-production and production This will lead to the following solution architecture.
This solution architecture makes sure that the development/ test / acceptation environment is completely separated from production.
By simply utilising a pre production deployment slot you are able to test your application against the production SQL database. With this setup you can’t alter any data in pre-production this is why there is a dotted line between the pre production web app and the test / acceptation database. That you could use to test all your CRUD operations. Besides this is also makes sure that the pre production is as close to production as needed for a clear test results.
When making use of deployment slots there are a considerations and disadvantages to be aware of:
The web application and deployment slots are created within the same environment (This is also the case when you create a Azure Web App within the same App Service Plan). This means resources between the two instances are shared, So if you want to do a stress test on pre-production you are certain that it will effect the performance of the production instanc see https://docs.microsoft.com/en-us/azure/app-service/deploy-staging-slots.
Deploy a web app in Azure App Service. using Git, Cloud Shell, Kudu Build Server, Azure Pipelines
Release It! Design and Deploy Production-Ready Software. Book by Michael T. Nygard.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.