We use continuous build and deploys up through a test environment, and each changeset is tied to a work item (story). After the build is deployed to an environment, I think we can see every associated story for that build. Question is what has changed, functionally, both for verification/acceptance tests and for release notes, support training, and marketing. This is related to How can I identify which work items/user stories are in a selected build in Azure DevOps? except that we want to know before the candidate moves to a higher level environment and to collect the sum of unique changes since this pipeline last promoted to that environment
For this issue ,you could see related work items in Release stage page. It compares the current release with the previous release and then displays the newly added work items associated with changesets.
Note:If the current release deployed an older artifact, then the difference lists negative work items i.e., the changes that were rolled back from this stage.
In addition,you can also enable Report deployment status to Work for the stages under Option in the release pipeline, thus when the stage completes, it will create links to all work items linked to associated changes.
You can see if this is what you need.For the similar case,please refer to this .
Related
My question is a continuation to this post:
Close work items automatically on Release to specific environment
This accepted answer will work perfectly, but only if I can make sure that a build shows just the delta since last build as associated WorkItems, instead of all work items from history. Sometimes I see all items in history as associated work items in a build.
Builds are happening for several environments (Dev, QA, UAT, Prod). How do I make sure that when I run a new build, it only has delta since the last build in that same environment so that I am only looking at new changes that are coming in with a new build?
Update:
I think I get what you mean. Please see if my understanding is accurate: your master branch has many PRs and links to many workitems. You create release1 from the master, and then when the branch is run based on release1 for the first time, the API lists the associated workitems of all the commits of the master. The second time, the incremental workitem compared to the first time can be displayed normally. Later, you created release2 from the master. When the branch was run based on release2 for the first time, the API listed the associated workitems of all commits of the master(This is not you want.). The second time, the incremental workitem compared to the first time can be displayed normally. . What you want is to display incremental workitems from the last run of the branch based on release1 the first time the branch is run based on release2?
If so, it's obviously not possible to use this API to achieve the requirements. As I said in the answer, this API fetch increment refers to the increment based on the same branch, it does not apply to different branches.
But you still have a way to get the "increment" you want, check out this API:
https://learn.microsoft.com/en-us/rest/api/azure/devops/build/builds/get-work-items-between-builds?view=azure-devops-rest-6.0
You just need to compare.
Original Answer:
but only if I can make sure that a build shows just the delta since
last build as associated WorkItems, instead of all work items from
history. Sometimes I see all items in history as associated work items
in a build.
Why do you say 'make sure'?
The API should only get the delta workitems(under the same branch).
I think changes should not contain all of the work items linked to all of the previous commits(since it is only 'changes').
Do you mean the behavior on your side is unstable, do you mean sometimes contains delta changes but sometimes contains all of the changes during the branch lifecycle?
If not, then the understood of yours maybe a little false.
If yes, I think you need to report this issue to the Developer Community. Please also provide your problematic build url there in this situation. StackOverflow is an open forum, so it's not suitable for handling stuff with private information.
Builds are happening for several environments (Dev, QA, UAT, Prod).
How do I make sure that when I run a new build, it only has delta
since the last build in that same environment so that I am only
looking at new changes that are coming in with a new build?
I suggest you put each environment in a different branch, then when you run pipeline based on the related branch, the pipeline should only get the delta changes of current branch and the API should only get the delta workitem commits since the last pipeline run of current branch.
Goodnight. I have a CI / CD process in Azure Devops that was working normally. As it is all set up, I, after completing a PR, simply execute a Build from my master branch. After successfully completing the Build, I generated a Release and deployed it.
But now I can no longer generate Release. The option to generate a release no longer appears in my pipelines and the message below appears:
This build will be retained forever by master (Branch)
I've already researched it in every way and I don't know what it can be. Has anyone experienced anything like this in Azure Devops?
I've already researched it in every way and I don't know what it can be. Has anyone experienced anything like this in Azure Devops?
Yes, I noticed that this message is in several regions for some my organizations, like Central US.
But I did not see this change in other regions, like East Asia. I think this should be a newly released change and it has not been applied to all regions. This small change is used to remind us how long the current pipeline will be retained.
If we manually retain the pipeline, the message will updated to the "This build will be retained forever by YouName (user)":
And for the option to generate a release, I have not seen it in the most recent versions, and it can be traced back to the TFS2018 version. I think this feature should be removed for a long time.
At present, when we create a release, we will select the release tab:
I come from using Rally and Pivotal Tracker. In both I could assign work items to Releases as a planning tool, and to have a historical record of those work items that were deployed.
Even with all the highly-specific guidance from Microsoft about Azure DevOps, it is silent how to organize work against future Releases. I can't see a place to even associate a work item to a Release. Is there something I am missing in all the documentation, or is there some workaround strategy more robust than just using tags to pro-actively plan against releases? Or is Microsoft's expectation that I use some separate product management tool to manage work items against Releases?
There are multiple techniques employed to accomplish this, not "one way":
use a parent iteration path that groups the iterations you plan against a certain release. This works best when you completely finish one release before starting the next. Otherwise, it usually becomes a mess with multiple active iterations.
Backlog Iteration
+ Release 1.0
+ Sprint 1
+ Sprint 2
+ Sprint 3
+ Release 2.0
+ etc
-
use tags for releases. Add a tag [Release 1.0] top all work items that are included in that release, this is one of the most flexible options.
use Azure Pipelines to keep track of which Work Items were associated to which Git commits and thus was included in which Build artifact. Track the build artifacts across environments to see which work items were deployed to an environment by looking at the intermediate builds.
add a custom work item field to the work item types you want to track. You can change the work item process being used and you can add a field to the work items in which you can specify the release name/number. There are custom controls available that can scope the version numbers to a specific list or can fetch the allowed values from any REST API.
Azure DevOps is more flexible in the usage patterns as you can see, but it also means that sometimes you need to "figure out what works best" for your team.
Another extension you may be interested in is the Bravo Notes extension. Or one of the other extensions that can generate Release Notes based on you work item data, commits and/or pipeline artefacts.
Similar to this question but for Azure DevOps. Going back 6-12 months, I was able to open a deployed Release (or possibly a successful Build, my memory is hazy) in what was then VSTS and view the backlog Work Items associated with it. On that page I was also able to filter on release names so that the list would show me all Work Items associated with any Release from the same Release Definition that was newer than the one I filtered on. This was how I used to put together our user-friendly release notes. It allowed me to view the bugs that'd been fixed, the features that'd been included, and so on. As far as I can tell, this feature no longer exists in Azure DevOps - at least, I can't find it.
The closest I can get is to view a list of Changesets from a particular date in the Changesets pivot, but that's not as comprehensive as a list of Work Items that were completed, and also doesn't tell me which Release those Changesets were included in.
I can also run a Query to show Work Items completed from a particular date but again I don't think I can view what Releases those Work Items were associated with, and even if I could it wouldn't help much unless I could filter Work Items based on the repository branch from which the Release was created.
Does anybody know if there is a way now in Azure DevOps to view the Work Items associated with a particular Release or Build? And, ideally, a list of Work Items associated with any Build or Release created from a specified Build or Release Definition from a particular date (e.g. "Show me all Work Items associated with Builds created from the 'Education Only Version' Build Definition since January 1st").
Howzit
Edit: I just realized this question was long ago... it showed near the top, assuming you have this solution but now
When you deploy a stage you can see all the work items and commits that are linked to commits since the last build that went to that stage.
We would like to link a TFS work item to a Release so we can easily, with one click from the Release, open a TFS item that contains more info about this release. Info like Release Notes etc.
Is it possible? A release has these variables that can be set when the release is created but they won't hold a (clickable link).
We cannot link work items for an existing release for now, there's already a user voice submitted here to suggest the feature, you can go and vote it up or submit a new one to achieve that in future release.
However you can link work items from changeset, try below steps:
Associate the work items to a changeset when you check in the changes
Then enable Automatically link new work in this build under Option in the build pipeline. Thus when a build completes successfully, it will create links to all work items linked to associated changes. See Automatic linking work items to builds for details.
Create a release pipeline and set the build which created in step2 as the artifacts source (For CI/CD).
You can also enable Report deployment status to Work for the stages under Option in the release pipeline (For set the repository as artifacts source ), thus when the stage completes, it will create links to all work items linked to associated changes.
Please note that in the release summary, it compares the current release with the previous release and then displays the newly added work items associated with changesets. So if you create two releases with the same artifacts source, then the second release will not include the work items... You can reference this thread for details: In TFS 2018, how do I get linked work items to show up in a release?