https://docs.microsoft.com/en-us/azure/devops/learn/what-is-continuous-delivery https://docs.microsoft.com/en-us/azure/devops/migrate/phase-features-with-feature-flags https://medium.com/@denniszielke/continuous-kubernetes-blue-green-deployments-on-azure-using-nginx-appgateway-or-trafficmanager-4490bce29cb
You use Azure Pipelines to manage the build and deployment of apps.
You are planning the release strategies for a new app.
You need to choose strategies for the following scenarios:
Releases will be made available to users who are grouped by their tolerance for software faults.
✑ Code will be deployed to enable functionality that will be available in later releases of the app.
✑ When a new release occurs, the existing deployment will remain active to minimize recovery time if a return to the previous version is required.
Which strategy should you choose for each scenario? To answer, select the appropriate options in the answer area.
NOTE: Each correct selection is worth one point.
Box 1: Progressive exposure –
Continuous Delivery may sequence multiple deployment ג€ringsג€ for progressive exposure (also known as ג€controlling the blast radiusג€). Progressive exposure groups users who get to try new releases to monitor their experience in ג€rings.ג€ The first deployment ring is often a ג€canaryג€ used to test new versions in production before a broader rollout. CD automates deployment from one ring to the next and may optionally depend on an approval step, in which a decision maker signs off on the changes electronically. CD may create an auditable record of the approval in order to satisfy regulatory procedures or other control objectives.
Box 2: Feature flags –
Feature flags support a customer-first DevOps mindset, to enable (expose) and disable (hide) features in a solution, even before they are complete and ready for release.
Box 3: Blue/green –
Blue/green deployments which means that instead of replacing the previous version (here we refer to this version as blue), we bring up the new version (here referred to as the green version) next to the existing version, but not expose it to the actual users right away. On the condition of having successfully validated that the green version works correctly, we will promote this version to the public version by changing the routing configuration without downtime. If something is wrong with the green version we can revert back without users every noticing interruptions.