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.
Related
I am wondering why my build pipeline for Azure DevOps is getting practically all the changes instead of just the most recent one?
I only made one change to 1 file, that didn't have an associated work item. This is what the change looks like. As you can see I have only changed one file. So why is it detecting all the changes?
I thought maybe it was because I didn't have this option enabled.
But even with that option enabled on a pipeline setup the EXACT same way all the changes are still pulled. Am I missing something subtle here?
There's an option on the pipeline to automatically link work items that are completed in a run.
You can edit the Pipeline and in the settings, tick Automatically link work items included in this run. You can pick * for all branches, or a specific branch.
Not sure what you did for your pipeline. Every time you change the files of repos for pipeline and then re-run the pipeline, it lists the changes for each build for the current project. This depends on how many changes you have made to the repo project since the last pipeline.
The below shows:
Then, click into the latest pipeline, and that is true, it will list all changes compared to the previous pipeline.
Click into it and you could get the detailed every single change.
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.
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 am using Build Pipeline: VSTS and Repo: VSTS
I am trying to create VSTS build pipelines for two branches Dev and UAT. I can achieve it by creating two different pipelines but since both has almost similar steps so I wanted to have only one pipeline and depending on condition I can omit some steps. But I am not able to figure out how to pass the variable value(branch which triggered the build) before queueing the build in VSTS.
Background: I tried to get both branch source, setted triggers on both branch and use Build.SourceBranchName variable but it is giving value the top level(Project) value instead of branch name. I have structure like below
Project
- Dev
- QA
The agenda is to trigger the build pipeline on checkin, sanity checks an publish the artifacts as per the environment(Dev,QA). I am not going for CD right now (will be handled manually because of some constraints).
The solution might sound very awkward but I am a newbie and I want to learn it.
I have checked some people have explained through API but any way to do through UI?
VSTS use API to set build parameters at queue time
Any help would be highly appreciated.

To add a variable that you can pass the value when you queue the build you need to go to variables tab, then add your variable and check the checkbox Settable at queue time.
Now when will queue a build you can change the default value.
UPDATE 2017/02/28
The tags in the release triggers are not source control tags, they are tags that can be generated by your build step. You can tag your builds automatically (see below), or manually during a build, I haven't tried this yet.
My assumption about the tags were flawed, which makes this question pretty much invalid. However I am going to try and see if I can find some sort of workaround for my exact scenario, and then I will post it here.
Background
I am setting up our CI/CD pipeline using VSTS, and part of our branching strategy is that only release/* branches that are tagged will be deployed to production.
Problem
I am trying to trigger a release using the VSTS Continuous Deployment feature, which should be able to work with branches and tags. At first I tried this, thinking that I could use a wildcard for everything:
Attempt 1
The trigger never worked, so I decided that it is probably not supported (because I can't find any documentation around it). So I tried an explicit tag.
Attempt 2
That didn't work either, so I decided to abandon the release/* wildcard altogether and just attempt it with a specific release branch.
Attempt 3
Still didn't work. I am either missing some really important steps here, or it is broken. Please help.
PS - For every attempt, I made sure that I committed a new file in git, tagged the commit, and kicked off a new CI build.
PS - Specifying a wildcard for branches like release/* works perfectly, as long as you leave the tag field empty
It is filtered by the build tag instead of source tag/label.
For example, a release definition CD with myTag filter, then the corresponding new build need to have myTag.
To add the tag to build, you can refer to these steps:
Edit your build definition
Add PowerShell step (Inline Script: Write-Host "##vso[build.addbuildtag]myTag")