We are using Azure CI/CD pipeline and have started publishing to deployment slots. After doing this change the publishing history is no longer updated, not in the production or staging slot. Is there any way to keep track on whats in production when using deployment slots?
Related
We are currently switching over from Classic (UI) Azure Pipelines to YAML pipelines.
We would like to deploy a branch every night to an environment (when changes have occurred) and also be able to deploy to this environment manually. With the Classic pipelines it was easy to setup a scheduled deploy to an environment that could also be triggered manually when desired.
In the new YAML pipelines we currently use the "Business hours"
check to make sure the nightly deploy takes place, but we are unable to override the check when a manual deployment is needed.
Is there a way to setup a YAML pipeline where a deploy waits for either a manual approval or a scheduled trigger to occur?
We have been converting our Release pipelines in Azure DevOps to instead be YAML files that run as Pipelines. This is so we can store our deployment process as code. The deployment process is working well - so a developer commits code and the Pipeline builds and publishes the artifact in one stage and then it auto-deploys to the QA environment in another stage. Subsequent stages deploy to an Environment (e.g. QA, Staging, Production) each of which requires some approval(s). The deployments themselves aren't the issue.
What I'm struggling with is unlike the old Releases there isn't a dashboard that will tell me which version of the project is in each environment. The Pipeline summary represents each stage for the Run as a dot (running, succeeded, failed, canceled, etc.) but wasn't built to represent what each environment has (probably because a stage doesn't have to be a deployment).
Is there somewhere else I can look for this information or do I have to build my own dashboard by calling the AzDO APIs? Looking at the Environment gives a list and I can root through the history, but that's not the experience our developers are looking for.
Is there a setting in Azure Devops release pipeline to "swap" deployment slots, similar to how it can be done in Azure Portal with source/target?
We have a stage where after the developer has verified the deployment on staging environment, he would want to enable the swapping to production, but I cannot find a setting like that. The only deployment slot setting I came across in Azure Devops is specifying the slot in App Service deployment task, but theres no swapping mechanism that I see...
Yes, this can be achieved in an Azure DevOps release pipeline.
The only deployment slot setting I came across in Azure Devops is specifying the slot in App Service deployment task...
Yes, this is the first step - deploy your app to a slot using the above-mentioned task:
Then, add a new Azure App Service Manage task to the job:
Which you can then configure like:
You just need to ensure that the Source Slot points to the same one you've deployed to in the Azure App Service deploy task.
I'm trying to configure Azure DevOps Release pipelines for our projects, and I have a pretty clear picture of what I want to achieve, but I'm only getting almost all the way there.
Here's what I'd like:
The build pipeline for each respective project outputs, as artifacts, all the things needed to deploy that version into any environment.
The release pipeline automatically deploys to the first environment ("dev" in our case) on each successful build, including PR builds.
For each successive environment, the release must have been deployed successfully to all previous environments. In other words, in order to deploy to the second environment ("st") it must have been deployed to the first one ("dev"), and in order to deploy to the third ("at") it must have been successfully deployed to all previous (both "dev" and "st"), etc.
All environments can have specific requirements on from what branches deployable artifacts must have been built; e.g. only artifacts built from master can be deployed to "at" and "prod".
Each successive deploy to any environment after the first one is triggered manually, by someone on a list of approvers. The list of approvers differs between environments.
The only way I've found to sort-of get all of the above working at the same time, is to automatically trigger the next environment after a successful deployment, and add a pre-deployment gate with a manual approval step. This works, except the manual approval doesn't trigger the deployment per se, but rather let an already triggered deployment start executing. This means that any release that's not approved for lifting into the next environment, is left hanging until manually dismissed.
I can avoid that by having a manual trigger instead of automatic, but then I can't enforce the flow from one environment to the next (it's e.g. possible to deploy to "prod" without waiting for successful deployments to the previous stages).
Is there any way to configure Azure DevOps Release Pipelines to do all of the things I've outlined above at once?
I think you are correct, you can only achieve that by setting automatic releases after successful release with approval gates. I dont see any other options with currect Azure DevOps capabilities.
Manual with approval gates doesnt check previous environments were successfully deployed to, unfortunately.
I hope this provides some clarity after the fact. Have you looked at YAML Pipelines In this you can specify the conditions on each stage
The stages can then have approvals on them as well.
We are using trunk based development and we have dev sandbox and production environments in Azure DevOps. We move build from dev to sandbox to production by promoting the builds. After moving build to production if there is an issue is there anything the pipeline i can define to trigger a rollback.
The only other option I can think of is get the last know commit number and trigger a build with that commit number. and let the pipeline take care of the rest. Is this correct is there a better way to do rollback in AzureDevops
Each release is a snapshot of the deployed artifact(s) and variables. The simplest "rollback" is simply to go to the Release Management history for the project, locate the previous release, and deploy it again to replace the newer release. Complications can arise if there are, for example, incompatible database changes.