I have a requirement to update work item status to a ready for test state after the first successful release using TFS release management. It seems like there should be a straightforward built in task to do this but I can't see it. My current thinking is
Use TFS REST API to query the workitems and update them all using powershell
Wrap this up in a powershell task and include in the release definition
This will do the job I reckon. It's yet more powershell in our releases but they are built on a stack of powershell anyway so at least it's well known.
But is there a better (quicker) way to do this? If the answer is a straight 'no' then great - I will accept that answer gladly.
We are on TFS 2015 R4.
Many thanks for any/all help
Sorry, there is no out-of-the-box feature for this by Microsoft.
But we still could use some three-party extensions or tasks to handle this situation.
The WorkItem Updater task can update the following work item fields during a build or release:
Update the state for workitems linked to a build.
Update the assignee for workitems linked to a build.
Add the build as Development Link to the workitems.
The limitation is also very obviously, it could only update work items which be linked to a build. Which seems not be a problem, it's also a good behavior track work items during build pipeline.
Otherwise, you have to use the ways mentioned above to update normal work items after/during a Release.
Related
We use Azure DevOps Server 2020 Update 1.1 running locally on our server.
When we commit, we always add a link to one or more associated workitems. The workitems are correctly linked to a commit. So far, so good.
I have a build pipeline that is running for the first time. There is no previous build. When running the pipeline, some of our workitems are not added to the list of related workitems.
DevOps lists 50+ items. To be exact, there are 78 items. However, when I manually check the commit history, I find 186 work items associated with at least one commit. What could be the reason for 108 workitems missing from this list? I could not find anything that the missing workitems have in common. How does DevOps find the related workitems? Is there a way to debug this process?
Thanks in advance.
I have spoken with Microsoft about this.
I have an incomplete list of related work items in my build pipeline because the number of changes linked with a pipeline execution is limited to 250:
Let's say we have implemented a very important "Feature A". Now we continue working and make 250 more changes without ever mentioning "Feature A" again. In this case, when we run a build pipeline, "Feature A" will never be part of the related work items. This is especially bad if the list of related work items is later used, for example, to create release notes.
In my opinion, it is very dangerous and misleading that there is such a limit.
The limit for 250 changes was defined by the product group and is basically a threshold to prevent performance degradation.
I sincerely hope that Microsoft will remove this limit.
Is it possible to add additional mapping to Get Sources at runtime?
Like in a prejobexecution task?
We are currently using a Powershell script that determines which additional mappings to setup based on iteration, area and different business requirements, maps them to the current workspace and then runs tf get.
This works, however, the changesets and work items from the additional mappings are not linked to the run.
We have also tried a different approach, where a “starter”-pipeline runs the scripts and modifies another pipeline (updates the tfvcMapping) and then invokes it using a build completion trigger.
All changesets and work items are linked, however, the approach does not seem right.
Add additional mappings to Get Sources at runtime (Azure DevOps pipeline - TFVC)
I have encountered a issue very similar to yours before (I use git). Personally, I prefer your second solution, which saves all the linked information (changesets and work items) at the cost of an additional pipeline.
For the first way, just as you test, we will lose some relevant information, which is not what we expected. Although we can use the checkout command to get the latest changesets, we cannot simply complete it for workitems, because it is done by Azure devops. It is difficult for us to obtain the associated workitems through changesets and associate them with our build.
The solution for me, we create a pipeline(as you said starter-pipeline) to invoke the REST API Definitions - Update to update the get source for another pipeline, then hen add build completion trigger:
PUT https://dev.azure.com/{organization}/{project}/_apis/build/definitions/{definitionId}?api-version=5.1
Check the similar request body here.
Hope this helps.
In Jira, you can create Releases for a project. As part of a Release, you can specify which issues are part of it as well as add Release notes.
These are extremely useful when you have automated build scripts, as the API for JIRA can be queried by the scripts as part of a CD pipeline.
You can therefore do things like (but not limited to):
Fill in a changelog dynamically
Stop deployment if there are an issues part of the Release that are not Done
Retrieve version numbers
Question: Is there a VSTS equivalent?
I do not think there is currently anything directly comparable to a Jira 'release' built into Azure Devops, which would allow you to package up completed Work Items on a board into a 'Release' work item.
You could implement a "poor man's" version of this by creating a custom process for your project that included a new 'Release' work item type. Each 'Release work item' could then be manually linked to work items you want to include in that release and could contain custom fields for the 'version' number or any other meta data you wanted to store with that release. This could then later be queried from a CD pipeline which, taking one of your examples, would allow you to do something like iterate over the linked work items for the release and make sure they are in a 'done' status.
Edit: As an example of integration techniques, the REST API for Azure DevOps supports a simple REST GET request to query all work items in a project for a custom work item type:
GET https://dev.azure.com/{organization}/{project}/_apis/wit/reporting/workitemrevisions?types={YourCustomWorkItemType}&includeLatestOnly=true&api-version=4.1
The API will also return any custom fields you have associated with this WIT, listing them under the key 'Custom.{YourFieldName}' within the "fields" object of the WIT response.
If your team was working with sprints, the other potential method I could think of to do this would be for each 'sprint' to become a named version which would become your 'release' once the sprint was complete. Work items that were not implemented as part of that sprint/version/release) would then be moved into the next sprint or closed. I'm not sure this approach would be very sustainable for complex projects.
There are features of interest listed on the Azure Devops Features Timeline that may improve this workflow in the near future (for example, "Release traceability – Work Item integration", planned for implementation in 2018 Q4), although it's difficult to find out any implementation details.
I noticed that by default VSTS adds up remaining work, but does not sum up neither completed work nor original estimate.
What needs to be done to set this up?
I do have some admin access to VSTS, but not sure this will be sufficient...
I even found this article https://learn.microsoft.com/en-us/vsts/work/customize/reference/support-rollup-of-work-and-other-fields?view=vsts
but I still can't figure out how to enable it in VSTS
Thanks for help!
There isn’t such feature in VSTS now, (VSTS (Hosted XML) is supported: Rollup estimated and actual work using Project).
There is a UserVoice: Rollup Completed Work.
You can to do it through this extension: VSTS RollUp, which is based on the web hook to update work item, the result will be:
I'm trying to execute a bit different build steps in VSTS based on type how build was started: automatically or manually.
I'm especially interested in accessing that information from powershell script. But so far was not able to find suitable solution or workaround.
Did someone faced similar requirement before? How did you solved it? I would appreciate your help!
Seems you want to know whether the project build is happening through TFS triggered build or manually triggered build.
There is no such feature for vnext build for now. About this , you could submit your uservoice to this link, TFS Product Team is listening to your voice there.
As a workaround either to use two build definitions through different version patterns or manually add a specifical tag after a manually build finished. Through using tags to set some labels on the build to distinguish manual and automatic builds. But this is a manual action, it would be better if we can do this automatically.
It seems to be I've managed to find an option that allows to determine wherever build was triggered automatically or manually.
All builds started manually have actual user in $Env:BUILD_QUEUEDBY variable, while automatic builds have system account there. My value was [********]\Project Collection Service Accounts.
I don't know how reliable it is, but for me so far following code did the job:
# Identifying who triggered the build
$OwnerId = $Env:BUILD_QUEUEDBY;
$OwnerId = $OwnerId.ToUpper();
if ($OwnerId.EndsWith("PROJECT COLLECTION SERVICE ACCOUNTS"))
{
Write-Host "Build was triggered automatically. Resulting files considered 'BETA'"
}
else
{
Write-Host "Build was triggered manually. Resulting files considered 'STABLE'"
}