We have a requirement of associating work items with TFS Builds. Generally, this is possible (or we can say 'natural') while using XAML Build Templates in TFS (via Integration Build field of WorkItem. In the below screenshot it was mentioned as 'Integrated In'). We are currently trying to migrate from XAML Build Templates to vNext version of VSTFS 2015 and further to integrate with Octopus Deploy for CI/CD practices.
We are now half the way in the migration because we are stuck up making this vNext templates to associate TFS WorkItems with their Build numbers. Without doing this step, if we complete this migration, it will be difficult to get associated build numbers for each Work Items delivered in that build.
When we searched MSDN blogs, we got a post (link given below) similar to our requirement but I tried that and ended up with no luck.
https://blogs.msdn.microsoft.com/tfssetup/2016/05/09/build-association-with-work-items-in-vnext/
So, please suggest the ways which can resolve our requirement.
Since you are going to migrate from XAML build Templated to vNext. Suggest you also upgrade your TFS version to higher all together.
Just as Daniel point out TFS2015 released already 4 years, kind of little old. Same latest feature in TFS/Azure DevOps are not supported.
What you are looing for is a build-in option in TFS2017 update2 and above version.
Automatic linking from work items to builds
With this new setting in the build definition, you can track the
builds that have incorporated your work without having to search
through a large set of builds manually. Each successful build
associated with the work item automatically appears in the development
section of the work item form.
To enable this feature, toggle the setting under Options in your build definition.
More details refer this blog.
Besides, you could also take a look at our official tutorial Migrate from XAML builds to new builds in case you need.
Related
I have been responsible for administrate our TFS projects and have started to investigate the current configurations. I found the following link for determining which process our team projects are connected to: How to determine what Process template an existing TFS 2012 project is configured with?
When using the rest API described in the article above, it seems like the projects depend on a process template called "Microsoft Visual Studio Scrum 2013". When reading this article: Scrum process it seems to me that the process is outdated and should be upgraded to use the "Scrum" template.
I have searched the internet for knowledge on how to upgrade the project to use the new Scrum process but had no luck of finding an answer. Does anyone have an idea of how to update the projects to depend on a newer process? Maybe the whole question is wrongly put as I may lack some obvious knowledge about how these things are meant to work. All I want is to ensure our projects are updated to use the latest TFS technology.
We use Visual Studio 2017 and did recently upgrade our TFS server to TFS 2018.
In general, some new features will be introduced when upgrade from old to new version of TFS.
Generally if you haven't made any changes to the original process template, upgrading is quite easy. Just enable new features by running the Configure Features Wizard in your team projects configuration page.
If it can’t upgrade automatically, you need to apply updates manually. See Add updates to team projects manually.
If you customized the process template, then you can follow the steps mentioned in this link to Update a customized process template to access new features.
To update the existing projects, a not so nice but easy way is to remove all work items and process data from your project and then add the newest items. Martin Hinshelwood has some great guidance on how to do this.
I've been tasked with migrating a build from TFS to VSTS, I've used TFS from a developer point of view, however I've never created builds. Can anyone give me any advice where to start, good websites, tutorials, tools that might help, anything that might catch me out etc, basically my knowledge on this is very limited so anything would help. I've no doubt there must be somebody out there who can say we've done this, here is what we did...the new VSTS build will need to be a copy of the TFS build however some analysis needs to be done as the build process is old and certain parts may not be necessary. Thanks in advance!
Migrate New Vnext build definition from TFS to VSTS
If you want to template your builds or move them from TFS to VSTS, you could also use the REST API's to perform this. Details please refer this blog: HOW TO MOVE BUILD DEFINITIONS IN TFS TO OTHER PROJECTS USING THE REST API
Another example shown here. It shows how to get the JSON response of a build definition and again using the same reference to make a new one in the project you desire.
Migrate Old XAML to New Vnext build definition from TFS to VSTS
Unfortunately, there will not be any automated conversion processes. The new builds are based on a different architecture and run on a completely different system. And you can use both the new builds and agents alongside your XAML builds, controllers, and agents.
If you have heavily customized XAML builds and custom activities, you
can continue using those builds until you are ready to port your
business logic into scripts that can run in the new builds.
You should also take a look at these series of articles by jessehouwing devoted specifically to the case like yours.
About how to create a build, you could refer this tutorial from MSDN.
We are using TFS and the TFS Build Service. We are considering to migrate the Build service to Jenkins but we came across some issues. According to this site, there are some things that do not work very well with the TFS and Jenkins plugins. All of them we use a lot:
Associated Change sets – Team Build automatically associates a list of change sets that are included in the build
Associated Work Items – Team Build analysis the relationships and also associates Work Items with a build. Indeed it walks the work item tree (parent) and maintains that association in the chain.
Is this still true? We have this scenario:
A developer checks in a code that fix a bug or resolve a User Story. It does that by associating his check in with the work item ID.
His check in triggers a build that will associate the work item with his changeset. For bugs, the build will update the "Integrated in Build" field with the build number. We use this field to know in witch version the bug was fixed.
Is there any way to make Jenkins behave and do what TFS build service does?
Another option is to mix the two using dummy builds on the TFS side that set the records straight and kick-off the Jenkins' builds. Some hints
How to trigger Jenkins builds remotely and to pass parameters and “Fake” a TFS Build.
This approach requires a bit of effort but has many advantages:
No big-bang, use Jenkins opportunistically
Can continue using existing builds
Having a build identifier in TFS allows you an overall monitoring and to use the Test features
I have a VSTS build definition for one of our projects that requires jenkins to build, but we still have all our other products using VSTS natively. To maintain consistency, this build definition triggers a jenkins build. We configured the build definition to not sync code as jenkins will download it (save time) and not to publish the artifacts back to the agent (i have another script for that found here). This allows developers to continue to use git as normal, and the build/release process is consistent with our other products. Along with task tracking and such.
To prevent unexpected build breaks and test failures, We have been using gated check ins. This works very well for our core solutions, and has helped improve our quality.
As part of our overall architecture, we have a certain section of our code with many micro-services, each of which is a new solution. New solutions are added to this part of the code base regularly. These are important parts of the system, and I need to make sure they get compiled as part of a gated check in without the chance for developer error.
Is there a way to configure TFS to find ALL solutions under a certain path and include them in a gated check in build?
Thanks
Not without modifying the build process template, which is almost never a good idea. The new build system in TFS2015 does allow that, however.
TFS 2015 vNext builds allow wild cards to search for all solutions. I haven't had success getting this to work with Visual Studio build steps, which you would need, but it works well with NuGet Installer and other build steps. We will not see gated builds in vNext builds until we get update 2 see TFS feature timeline
My team has TFS build machine building checkins.
Today, we have more than a dozen build definitions to prevent building projects/running test in unaffected areas. This was when we weren't using incremental build.
Now that we enabled incremental sync/build, I am thinking about creating one giant gate definition that include all my team's source code. Since incremental sync/build is enabled, unchanged files don't get built anyway. But TFS is still running all tests.
Is there a way to dynamically pick just test assemblies that were built recently?
I can do it by modifying build template to filter out test assemblies that are more x hrs old but before I go that route, I wanted to check if there is something already available.
thanks
Customizing the template is the right path. Beside the official documentation, take a look at ALM Rangers' Build Customization Guide.
The FindMatchingFiles activity has no date filtering, so you have to roll your own.