I'm looking for a pre-made option to take 2 builds, and compare the work items or PRs completed between them. i know there are REST API options in order to find out this information ( https://learn.microsoft.com/en-us/rest/api/azure/devops/build/builds/get%20work%20items%20between%20builds?view=azure-devops-rest-5.0 ) , but i would rather not build my own app for this if one already exists. Is there something built into azure devops that shows this information, preferably in an exportable format? Is there possibly an existing devops extension in the store? Any searching i do just brings up the REST API call and nothing else unfortunately.
They seem to have changed it in Azure DevOps. We are using Azure DevOps Server (on-prem). In it, the old TFS-like work items comparison between the builds is possible when you actually deploy (execute a release) in a stage:
(in the screenshot below the right popup pane is showing the work item "diff" between the build currently deployed in TEST and the one which is about to be deployed now)
If you are open to it being generated at build time, you could look at using the Generate Release Notes Build Task from the marketplace.
Related
I am trying to create a release pipeline in Azure DevOps. We already have a functioning build pipeline that works well, it is able to package the build with VSBuild and publish it as an artifact. Then in the release pipeline I am using an IIS Deployment job (which includes IIS Manage and IIS Deploy tasks) and it gets that artifact to deploy.
The problem is that we already have a publish profile (.pubxml) that should take care of pretty much everything the IIS Deployment is doing (at least as far I as I understand it). So to me it seems I have two options that don't require me to refactor the project configuration itself.
I can try to mimic the settings on the IIS Deployment job to match our .pubxml as closely as possible and manually applying any changes that aren't doable through the task settings. Obviously this is not ideal as that would require us to update both when ever we make changes and it introduces a large chance of the pipeline breaking down over time.
I can scrap the idea of using IIS Deployment and just use a VSBuild task that uses arguments /p:DeployOnBuild=true /p:PublishProfile=Staging. This doesn't seem like best practices because it means my release pipeline isn't passing a build package to deploy, it is just creating a new one at each stage.
So is there a better option that would allow me to utilize the package I created with VSBuild and the .pubxml configuration together in a deploy? If that isn't possible then are either of my options the "correct" way to handle my situation or am I just missing another method of deployment I could use?
Thank you for any help or insight you can provide. Please let me know if there is any more information I can give that would be useful.
You can try using publish settings file (*.publishsettings) for your IIS deployment.
A publish settings file (.publishsettings) is different than a publishing profile (.pubxml) created in Visual Studio. A publish settings file is created by IIS or Azure App Service, or it can be manually created, and then it can be imported into Visual Studio.
To view more details, you can see:
Publish an application to IIS by importing publish settings in Visual Studio
Deploy your app to a folder, IIS, Azure, or another destination
So unfortunately there doesn't seem to be a way I can achieve everything I wanted in this. The publish profiles are required for when we build the project so without making changes to how we configure those I need to build the project whenever I want to deploy. Ultimately I went with option #2. I essentially just copied most of the build tasks used in the testing pipeline and placed those in the release pipeline with a few modified commands to actually deploy the build once finished. It all seems to work just fine but still doesn't feel like best practices. If I am missing something please let me know and I will make updates as appropriate.
I have a setup that requires the repo, CI and CD of the application to live in one Azure DevOps project. Some of the work that is being done on that application is managed at times in a different Azure DevOps project.
I know that I can allow linking and reporting on CD progress to related Work Items. My problem is that it seems to work only when the Work Item is within the same Azure DevOps project that the CD is in.
Does anyone know of a way to get it working across projects?
I have this enabled on the CD pipeline:
Also, when I navigate to the Work Item associated to this Release Pipeline I see this (different Azure DevOps project):
As you can see it does not seem to report on the progress of the associated Release Pipeline. But it does report on the repo that lives in the other Azure DevOps project. Also, if I click on the Release link, it will bring me to the Release of the project where work is being managed and not where the Release Pipeline actually lives.
Does anyone know of a way to get it working across projects?
Of course, this can be achieved, you can refer to the following steps：
Step1: Commit changes to the Repo with Work items.
Note: You can link the work item from another project.
To link work item with repo, there are two methods:
Use #ID in comment.
Select the work item ID.
Step2: Enable the option Automatically link new work in this build in Build pipeline -> Options
Step3: In Rlease Pipeline, you need to select the Report deployment status to Work and
Report deployment status to Boards
The Option Report deployment status to Work will show the release under the link tab.
The Option Report deployment status to Boards will show the release under the Deployment tab.
Based on my test, it could work on work items from another project too.
I have an ASP web application that I have building in an Azure DevOps Build Pipeline. That is all fine.
I want an external organisation to be able to define their own Azure DevOps Release Pipeline to consume the build artifacts produced by our Build Pipeline. I need the access of that external organisation to be restricted with some sort of credentials (i.e. I don't want the project to be public to everyone). The external organisation should be able to deploy the latest version.
I thought this would be a relatively simple process using only Azure tools (particularly with reference to Feeds), but have tried a number of different approaches based on the documentation but all have failed. I don't want to publish to GitHub - I just want to keep everything inside Azure. I have tried using Universal Packages with Feeds, but the Release Pipeline can only pull a specific version from the feed rather than LATEST.
Does anyone have any recommended approaches I should take?
There is Latest option in the feed of your Release Pipeline:
I run UI tests for my app in a release definition in Azure DevOps. I generate test report. I decided that it is convenient to save it in the build directory(wrong assumption?). The directory where the report is is:
browserName + DateTime.Now.ToString("ddMMyyyyHHmmss", CultureInfo.InvariantCulture) + #"\";
so the directory regex would be for instance : Chrome\d+
I build the test project in the release pipeline, run the tests, then I try to publish my report. The goal is to make it available in the Azure DevOps, or send a link to download it or any other way that makes it accessible.
To do so I added a step Publish Build Artifact
but then I get an error:
but then I don't have a fileshare available(I am able to create Azure Storage Account for instance) additionaly Publish Build Artifact doesn't support wildcards so I can't use regex Chrome\d+ to pin down the report directory.
Question: How can I make a file that is generated during release pipeline accessible?
EDIT: I found out in the meantime that I have Sharepoint available with enough storage.
Unfortunately publishing from release pipeline is not allowed.
Can we publish artifacts in release pipeline - Azure devOps?
One way to get around this is to try to publish Universal package in release pipeline but it has limitations. Create feed and publish there your files so you can share URL to others. It is not best option but if your test results files are not large you can publish to the feed and clean it sometimes(manually, because REST API provides way to delete package but does not provide function to get list of all packages published).
https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/package/universal-packages?view=azure-devops
The disadvantage of this option is that for free users it has limit up to 2GB. You can delete old packages when required but it takes around 24 hours to free space. But you can forget to free space and your pipeline will fail with not enough storage error and by next 24 hours you will have to disable this task to let pipeline pass.
"I decided that it is convenient to save it in the build directory"
Remember that agent working directory is cleaned depending on option you choose.
https://learn.microsoft.com/en-us/azure/devops/pipelines/repos/pipeline-options-for-git?view=azure-devops#clean-the-local-repo-on-the-agent
I'm new to Azure DevOps and I'm trying to understand how to package a release of a PowerShell script project I'm working on.
I'm previously familiar with GitHub and the manual process for drafting a new release of my project repo. I'm now experimenting with Azure DevOps and what I want to achieve is a similar output to GitHub where my repo of PowerShell scripts are packaged into a zip file which I can publish for release.
I'm not familiar with the pipeline process in Azure DevOps or YAML as a newbie to proper release cycle tools. Previously I've just created scripts and shared them simply as they are or dropped them into a GitHub repo and manually packaged a release. I'm not likely to be turning out large numbers of builds and so have never had to come at this from an automated standpoint which seems to be the way Azure is driving me unless I'm missing something?
It's pretty simple. I prefer to do this using the old-fashing GUI (hint: there is a link when starting a new Build Pipeline that says Use the classic editor), and then convert to YAML after I get my Build Pipeline working.
1) Create your standard Build Pipeline.
2) Add the step to ZIP your files
3) Add properties to that Archive step. Specify the source to zip and target where you want the zip file to end up at.
4) Lastly, convert that single step to a YAML step by clicking in the upper-right corner on the link View YAML.
There are a lot of steps I am leaving out, but I hope this leads you into the right direction.