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.
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.
We have Azure Build and Releases pipelines for our App Service. Everything is pretty straight-forward.
We initially configured single instance for the App Service and Release pipeline worked great.
But after scaling it out to 3 instances what we learned was that release pipeline delivers artifact only to one of 3 instances
So, the question is, how we can configure it in a way so artifact is deployed to all instances of the App Service regardless how many of them there are
Additional details:
this ASP.Net Core 3.1 project
we use "Azure App Service deploy" task
You will probably want to use deployment groups by changing your agent to a deployment group agent phase.
The deployment group allows you define multiple target environments, add tags, and target those tags on specific phases. I'm suspecting that you have installed the agent on all the target machines, but it will only run once and will pick from any agent registered in the pool. Instead, I believe you want it to run on every target.
You can even configure the release pipeline to automatically deploy the last deployment release as new targets are added.
You might reference this answer about the difference between an agent pool and deployment pool: Azure Devops (VSTS) Different between Agent Pool and Deployment pool
I'm building an Azure DevOps pipeline to deploy a custom-build powershell application to several on-prem environments that we support. I configured the required agent pools and installed them as a service on the on-prem environment.
Next, I have set up my pipeline in Azure DevOps, selecting a GitRepo:
Build (with the steps: Use Nuget, Nuget Restore, Build solution, Update version, Copy Files, and Publish build Artifact)
Release (with step: Publish Build Artifact)
Some things are unclear for me:
Do I need the Publish Build Artifacts twice? Can the Build pipeline
end with Copy Files step, and that the Release pipeline picks up this
artifact?
It is my understanding that the release publishes the app to the
on-prem environment (in my case). Where can I set a custom path (ie:
C:\deployed_apps) where the app needs to be deployed? When I tested
this pipeline, I got errors that the path I created using an variable
was not found.
What am I missing in my setup to get this pipeline working?
As #Shayki Abramczyk
pointed out this task is not for deployment, it just upload your Build Artifacts to azure devops server where your release pipeline can download directly.
In your case, if you want deploy your application to several on-prem environments, You need to create a deployment group first, A deployment group is a logical set of deployment target machines that have agents installed on each one. You application will be deployed to those machines in a deployment group in release pipeline. Check here for more details about deployment group.
After the deployment group is created, you can add a deployment group job by click the 3 dots, and then specify your deployment group as below pic shows, You can then simply add a copy file task or other deployment tasks to deploy your application to your on-prem machine.
In the release pipeline you shouldn't use the Publish Build Artifact. in the end of the build you put this step, what this step does? upload your artifacts to the Azure DevOps or to a file share. now in the release pipeline you choose the build artifact (in the left pane). the first thing that the agent does when the release pipeline started is to download the build artifacts to the agent. now you need to take them and deploy it to your environments. how? it depends which kind of application is (it can be just copy files, it can be deploy to IIS, etc.).
You can put the path in the variables tab and use this variable when you deploy the app (with copy files task, for example).
In VSTS Release, how do I stop all continuous webjobs and remove schedule from triggered webjobs for specific deployment slot?
scenario:
I have a asp.net core web application with bunch of webjobs. Some of them are scheduled, some are continuous.
In VSTS Release I deploy the webjobs together with web app to App Service using Web Deploy.
However, in staging environment I don't want to run the webjobs, since they would interfere with production (the share the same database, etc).
I guess I would have to write some powershell to stop the webjobs. It comes down to these steps:
How do I run PowerShell in VSTS that is connected to my Azure Subscription
How do I list all webjobs for my webapp and deployment slot
How do I stop continuous webjob
How do I set trigger to manual and remove schedule from scheduled webjobs
You can set two sticky app settings on the staging slot:
WEBJOBS_STOPPED: 1
WEBJOBS_DISABLE_SCHEDULE: 1
Actually not sure if you need the second one even.
Source: Kudu Wiki
Then WebJobs will not run on that slot, and by setting the slots sticky (i.e. slot settings), they will stay on the staging slot and not be swapped with the app.