New SEP GitHub Project: TFS Manual Build Creator
Have you ever needed to integrate artifacts built on an existing build server (like Jenkins) with Microsoft’s Team Foundation Server (TFS)?
I hadn’t either until last week, when I found out there isn’t a canned solution.
Working on a medium-sized project for a client, we moved our source code from TFS to Git in an effort to manage the risk of merge issues and code getting out of sync between multiple geographically disparate teams.
Okay, so, source code in Git, not TFS. Check.
Well, we’re also using Microsoft Test Manager (MTM) to handle testing and traceability. If you’ve never used Microsoft Test Manager, think of it as an alternative front end to TFS that focuses on testing. Here’s a simplified version of how MTM executes tests created for a particular sprint:
- MTM finds a registered Lab that will run your tests. Think of a Lab as a known environment running on a VM or a physical machine.
- MTM grabs your project’s code from TFS and uses Microsoft Team Build to pull a BuildTemplate from your source code and generate a Build.
- The Build is loaded onto the Lab
- MTM executes the Test Cases that have been created for the User Stories in the sprint, using the Lab loaded with the Build
By moving our source code to Git and our builds to Jenkins, we basically obliterated step 2.
There are a few solutions that could have worked, other than our custom solution:
- We could have written a new BuildTemplate that pulled the relevant artifacts from Jenkins and pushed them to TFS or MTM. This approach was 86’ed because BuildTemplates are darkest magicks and Ron broke his wand. Again.
- We could have used a TFS-to-Git bridge, such as git-tfs. We were reluctant to use this approach because “MORE SOURCE CONTROL” didn’t seem like a good solution to source control problems.
- We could have moved to Mongolia and adopted the simple lifestyle of a nomadic herder. We opted not, because nobody knew how to build a yurt.
Our solution is the TFS Manual Build Creator, a command-line executable that can be used to tell TFS about a build and where its artifacts can be found on a network share.
Once the build information has been entered into TFS through this utility, MTM can see the build and life can resume at step 3 above.
Our intention is to hook the executable into our Jenkins build process such that whenever a build of specific projects is completed, that build information will be pushed into TFS so our testers can verify that our client is getting exactly what they want. It’s actually quite neat to watch in action.
Neat! Why Open Source it?
There are a few reasons, once again in bullet points:
- Look at what I did! It’s neat!
- If I looked for a solution to this problem and couldn’t find one, chances are someone else will look for a solution and fail to find one too.
- Getting software out into the world lets everyone see our chops. Not only do we use these tools that improve our products and help us work more quickly, but when they don’t fit together easily we can make them work using MIGHTY EXPERTISE.
- I like finding surreptitious ways to get my controversial opinions out in the open.
- Not only can we use the software for this client, but when the client brings on new vendors to work on this project in tandem, they will be able to use it as well.
The project can be found on GitHub. I don’t want to brag, but it’s currently the newest project under SEP’s account. And that’s saying something. Kinda.
“And” what? Go use it! Spread the word! There are probably dozens of teams toiling under the oppressive yoke of mismatched tools, and this project is the balm that would ease their misery!