I have a TeamCity server building our deployments which is linked in with our issue trackers (both JIRA and TeamCity). If I put the right tag on the check-in comment this automatically links the build to an issue in the tracker and I can see a list of issues resolved in this build.
I'd like to aggregate this list of Issues across multiple builds. Basically, I'd like to automatically generate documentation for releases, which might comprise multiple builds. Is there any way to do this?
Issue tracker in teamcity only shows you the relevant tickets in a build. If you know the build number from where to start you can filter the list starting from that build to get an aggregate list.
Alternatively you can use a third-party tool that does something similar. Not sure what version control system you are using but we are using GitReleaseNotes to extract tickets from commits and link to Jira.
Related
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.
I am new to Azure DevOps, so perhaps this is a really simple question. When selecting a build (there are many) to deploy to production, it would be great if I could identify the user stories or tasks were included in that build. I want to be able to say what work is being deployed before it is live, or tell customers who are waiting for new features when that feature is live.
I have tried to write a script using the Azure DevOps API and can see my builds and pull requests. But how do I link them? Is there an existing tool to do this maybe? It would also be great to say given a user story id (e.g. 171171), you could say which build it appears in. Is this possible or do this without saving all of the data from the API and reading this cached version?
You can specify work items (Bugs, User Storys, ...) when commiting to the Git-Repo. This is done by Hashtag and the work item number (e.g. #1234). Visual Studio also has a UI support for this, which does the same.
The linked work items will automatically be display at the Build summery page.
Just add work items into commit. Here is different options: Linking Work Items to Git Branches, Commits, and Pull Requests
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.
I would like to get the issue list from Bugzilla and JIRA for an open-source project. For each issue, I'd like to collect the corresponding compilation units(for java projects, class/or interfaces files), which may relate to the issue.
Any idea on implementing this feature would be appreciated.
Many thanks!
For JIRA, there are some solutions out there you could use out of the box. See the documentation to integrate with source control for JIRA how to do it. This only works for some source control systems, you should which ones are supported. This gives you a list of change sets (e.g. for Subversion) for each issue.
Another approach could be to do it on your own through an interface to the source control system yourself. The following prerequisits have to be in place:
Your developers have the tools to add the information which issue was worked on by which commit on a per commit base.
You have rules that changes to the sources should all the time being done only for one issue at one time.
You are able to parse the additional information you will get from your version control system e.g. by a script or a program.
For Subversion and JIRA, it could work like that:
Ensure that all commits are only done if the Subversion commit message contains at least one JIRA ticket number. You may even ensure that by a pre-commit hook
Learn how to get the following information from the subversion log
The ticket IDs (by parsing the message) for each change set
The files that had changes for each change set
Collect for each file all tickets.
Show them in a format you like.
I think that this is not too useful, because ticket per class is too fine grained. Perhaps you should have a mapping of the files to modules, sub-projects, ... and collect tickets for them.
All solutions will be different depending on your selection of tools. JIRA and Subversion are here just examples :-)
The best way is to first integrate your issue tracking system with your source control. That means that whenever a developer commits a new change, it determines the set of issues related to this change. This linkage is managed by your issue tracking system and it can show you all the source files, resource files, config files that have changed in the context of an issue.
This info, will be available through the api of that issue tracking system as well.
I am preparing to move my team's source control from VSS over to TFS 2008.
This is for an asp.net website, and I am currently using a combination of nant scripts and Cruise Control to do all of the builds and deployments.
I've been trying to wrap my head around the best way to architect TFS build to do the same thing I'm doing with NANT and Cruise Control, but I can't determine the best approach.
Here are my requirements:
When code reaches a certain point, I manually apply a label to it.
This labeled code needs to be built and deployed to any of our 25 different Dev, QA, or production environments.
Any of these 25 environments can be on any current or past labeled version of the application.
I need to be able to deploy any labeled version of the application to any of the environments.
I'm currently accomplishing the above using NANT to perform the build, and using Cruise Control to just pass in command line options for which environment(s) to build and deploy. I have a Nant config file with a list of all of my environments, and an associated label each environment should currently be using. This file gets manually updated whenever a new label is created.
I know the approach I'm using for NANT probably won't be the same as with Team Build, but has anyone done something similar with Team Build and could share how you accomplished it?
Labeling in TFS is much more robust than in VSS. When you create a label, you can create based on a changeset, date, workspace version, heck even a different label. (BTW, I was grabbing a link and came across this post that you might find relevant.)
By default, a Team Build will build from the latest version of code in source, but you can override the "CoreGet" target in a build to build a specific version. Aaron Hallberg (a.k.a. TFS's John Skeet) shows an example here.
see 4.
I haven't personally had this difficult of a requirement, but I've done something similar. When you queue the build, you can pass in any number of parameters in a couple important ways, 1) through the response file and 2) at queue time (simple example here). In either case, two parameters could be which environment and which label/version number. At my current project, I have continuous integration turned on, so when code in a workspace is checked in, the current code is automatically labeled, pull the specifics for my drop location from the response file, then deploy to the respective location.
Given the fact that you have ~25 environments and n number of versions/labels, you could build a simple GUI that reads the current labels through the TFS API and lets you pick which version to build to a particular environment.
To answer the question, the way I addressed this was to use a combination of a custom build task, cruise control, and msbuild.
The custom build task allowed me to get the latest version from a specific branch and label.
Cruise control allowed me to pass in specific information for a specific build to MSbuild, using a config file, but initiate the build from a UI.
msbuild was used like normal, however it was called from cruise control, and the custom build task did most of the work.