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.
Continuous Integration and Continuous Delivery workflow
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-...
If you're looking for a turn-key project management, team collaboration, and source control solution, check out Azure DevOps Services. Sign up atAzure DevOps Services.
Getting started with Azure DevOps
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.
Example with Azure App Service Deployment slots
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.
Using Deployment slots
Deploying your application to a deployment slot has the following benefits:
You can validate web app changes in a deployment slot before swapping it with the another slot.
Eliminate downtime on deployment, and automate the swapping.
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, seeApp 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 theStandardtier, because theStandardtier supports only five deployment 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.