I understand that VSTS Release is still not under final version, but I am stuck with a problem. When there is a pending approval, sometimes it is simply not possible to approve/reject the release. Example:
As you can see I have 3 environments: DEV, QA and PROD. When deploying to DEV, there is no approval required. So now it shows "In Progress" but an approval is waiting.
On the picture above is a proof that we are waiting for the Post deployment approval.
Finally, you can see above that I configured myself to receive notification for approval and to be an approver.
Any idea?
[UPDATE]
The above shows that I could approve pre-deployment to QA (DEV here was auto-approved), and now I cannot approve the post-deployment to QA.
Here is a screenshot of a successful release (only on DEV environment though), and having the same warning message:
Cannot update deployment status for (web app name) -
{"Message":"Repository could not be found."}
You need to go into the release and cancel all previously queued releases. In your first screenshot under environments, each environment should be a hyperlink. Select that one in question and under Waiting for Deployment, you can cancel all the ones you don't want. That will clear up the queue.
When we have a prior release candidate that we are not going to deploy to prod, it looks like this:
Note this is in the new Azure DevOps UI for VSTS/TFS builds and releases. This shows, chronologically from the bottom up, two releases deployed to prod, then a third release not deployed to Prod, then a fourth release (at top), which cannot be deployed to prod until the third release is rejected or cancelled. Both will work but in my experience the release tracking is a little cleaner if you reject the release rather than cancel it.
To do this, click "Pending approval" in the third release Prod environment to view approvals and then click Reject. If you have multiple prior releases not deployed to Prod you will need to reject or cancel them all - again my preference is to reject them chronologically (from first undeployed release near the bottom towards the last undeployed release near the top).
Once done, the release at the top will no longer appear as queued and you will be able to approve it (assuming you have enabled Pre-deployment approvals for approving deployment to Prod) to allow deployment to commence.
Related
I want to keep all the history from our master branch, 1 year
the history deleted after 2 or 3 months and is bad we want to keep our production history....
To keep all the history from the master branch for a year, you can set up branch policies in Azure Devops.
Go to the Branches page in the Repos section of your project.
https://learn.microsoft.com/en-us/azure/devops/repos/git/branch-policies?view=azure-devops&tabs=browser
You could see the doc for details.
If you are using an on-premises Team Foundation Server or Azure DevOps Server, you can specify release retention policy defaults and maximums for a project. If you are using Azure DevOps Services, you can view but not change these settings for your project.
And for every release pipelines, you could see retention policy for each stage but not specific branch. You could go to release pipelines and edit release then you could see 'retention' for the release.
For individual key releases, you can click on (…) of one release pipeline and choose “retain indenfinitely”.
BTW, neither the pipeline's retention policy nor the maximum limits set by the administrator are applied when you mark an individual run or release to be 'retained indefinitely'. It will remain until you stop retaining it indefinitely.
I have a release pipeline set up dev qa and prod. QA and PROD triggers are set to after stage with pre-deployment approvals set up
Problem I facing I have feature which I broken into 3 sprints ( user stories ) after each sprint all dev work is deploy to dev for testing. After dev is deployed the email going out to pre-deployment approvals for QA which is not what I need
Solution I looking for is each sprints get deployed to dev. When I am done with the whole feature I can add a message and click a button or something then the email must go out to the pre-deployment approvals can this be done using triggers are set to after stage?
You could set a post-deployment approvals for dev stage, after deployment for dev stage is finished, it need approval before the release is triggered to other stages. After you approve the post-deployment approvals for dev stage, the email for pre-deployment approvals will send.
I have recently moved from Classic release to YAML release pipeline. With Classic release I would simply trigger manually the deployment I was interested in (Dev, Integration, UAT or Production).
However with YAML pipeline I use stages and they are triggered automatically after building. To prevent that, I've added Approval guard on the Integration stage as shown below.
However the pipeline was running indefinitely and would never end. So I've set a 5 minute timeout on approval and now the Integration stage is marked as Skipped if nobody approves.
I feel I'm not doing it the right way as it is quite different from classic release.
Is this the correct way to handle release pipeline when using YAML ?
Is this the correct way to handle release pipeline when using YAML ?
Yes, you are on the correct way (At least for now).
Just as you said in the question, Azure devops does not support manually triggered stage(s) in YAML multi-stage pipelines. So, we could not simply trigger manually the deployment stage we are interested in.
There is an On Roadmap user voice about this request:
Manually triggered stage(s) in YAML multi-stage pipelines
You can look forward to it, and I believe it will meet us soon.
So, your workaround is correct for now.
Is that possible?
It would be very convenient, to have all branches with an open PR deployed somewhere, where I can have a shareable link.
There are the PR-Branch Triggers, but AFAIK it can only deploy one branch to one environment at the time. And another PR update would just overwrite the state.
EDIT to clarify what I mean:
Each feature branch (or bugfix or whatever) of our webapp should be deployed to an app service (or whatever), so when we create the feature, we always have a link to share during development, in which our designers (or whoever) could find issues in early development. At another cloude storage provider, we had something like that and we would always receive a unique link after successful deployment.
I'm a bit late but working on this now. What I intend to do:
Pull request on selected feature branches triggers task 2
Task will create app services via Terraform (Link)
Use the 'app service deploy' task to push the artifact from that pull request to the new app service created in the prior task.
We'll see how it goes
If deploying each feature branch to an app service is what you are trying to achieve.
You can try below steps(Only for classic pipeline view):
1,In your CI build pipeline, Go to triggers page, add each of your feature branch to branch filters, So that each Pull request made to your feature branch can trigger a build.
2, in your CD release pipeline(Classic view), add different stages, each for an artifacts which built from feature branches:
3, for each stage, In the pre-deployment conditions page, add an artifacts filters to its corresponding feature branch. So that the artifacts from this specific feature branch will trigger to deploy its corresponding stage.
4, Change the settings and parameters of the tasks in each stage according to each feature branch. So that each app service deployed for each feature branch has its own settings and configurations,
5,Configure your app service deploy tasks in each stage.
With above steps done,each time when a new pull request is merged to the feature branch, the corresponding stage will be automatically triggered to deploy this pull request to the configured app service.
I'm trying to create a CI/CD pipeline for an example prototype. Thus, I've started simple enough to test my infrastructure - I'm using an almost untouched boilerplate of ASP.NET Framework Web App (targeting 4.6.1). The steps I've completed are:
App is deployed to an Azure App Service.
Its version control is hosted with Azure DevOps.
A build pipeline with the following tasks has been created, set-up and tested if it executes (tasks and their order, come from a template):
Azure Deployment Options/Settings are bound to the repository DevOps, thus builds are also displayed in Azure, and should be deployed there if successful.
The Build Pipeline is bound to the correct repository inside DevOps
Builds get triggered by pushing to the master branch
The next step was to verify that a broken build, because of failed tests or any other reason is not deployed to production in Azure. I've created a failing test for this reason.
And this is where I'm left stumped. Builds do fail as expected and the "App Service Deploy" task is skipped, because the build tasks before it have a failure:
And yet those broken builds still get deployed to Azure and to production without even waiting for the pipeline to finish. I'm verifying that a change has actually happened with small visual updates.
Build started and finished in Azure as soon as a push occurs before the pipeline in DevOps is fully traversed (or even started, if finding an agent takes longer):
(DevOps still not finished):
What am I doing wrong here? Am I understanding the pipeline wrong? Have I missed a set-up step somewhere? I'm lost.
Edit: As asked by Josh, here's my trigger as well:
Edit 2.2 A bit more clarification of my deployment options in my App Service in Azure, related to Daniel's comments:
This turned out to be the issue.
This is the only option I'm allowed to choose when tying my deployment to DevOps. I'm not allowed to choose a pipeline, just a project and a branch. In a tutorial I've compared with, the settings are the same (at least in this menu), but the build does not get triggered from the repository, but expects the pipeline to reach the appropriate step first, which is why I haven't considered it to be the culprit. Is there some additional setting up, I've missed to do, to indicate that it must look for a pipeline, rather than fire straight away from branch changes?
The deployment you have set up in the Azure portal is tied to source control only, not your build definition. So every time you commit to source control, two things happen that are totally disconnected from each other and start in parallel since they listen to the same repository for changes:
A build fires off in the pipeline.
The Azure website is updated with the version you just pushed to source control, since its deployment options are bound to it.
Remove #2 and your problem will go away. You set the App Service you want updated in the pipeline, you don't need an additional hook in the App Service itself.