Naked ALM Consulting Logo
 

The TFS Automation Platform is dead, long live the TfPlugable

Book an Expert

 

The TFS Automation Platform is dead, long live the TfPlugable! It has been a long time since I have talked about the TFS Automation Platform that I had almost forgotten about it myself. It was almost two years ago that I spoke to Willy about an ALM Rangers project to build a solution to dynamically deploy plug-ins for TFS, kind of like Nuget for TFS Extensions.

When we first attempted to get this off the ground way back in 2011 we had a team of rock star Rangers that ended up having no bandwidth for yet another project and it faded and died after a few sprints. I was sad, but what can you do…

The Problem

However recently I have seen more and more customers wanting their TFS servers to have custom automation as part of their deployment. There are quite a few things that come out of the box but there are still many things that could be done. From Admin tasks to simple rollup or email alerts for your entire organisation there are a plethora of extensions for Team Foundation Server that would be useful but are currently hidden away in the back of your TFS cupboards and never see the light of day.

I would like to do for Team Foundation Server what NuGet has done for distributing and popularising shared assemblies. We need a store for Team Foundation Server where we can pick and choose what extensions we want. Now this already exists for Visual Studio in the Visual Studio Gallery but there is nothing for Team Foundation Server. I can’t find Check-In Policies for TFS and it is hard to install them, although there is a little love from the Power Tools. I can’t find background operations for TFS… oh I can search for them and find them on blogs, Codeplex or GitHub… but I want the same thing that NuGet or Chocolatey provides.

It is easy to create to create extensions for Team Foundation Server, but it is hard to deploy and manage them. Here are the key integration points that we will be looking at:

  1. TF Job – These jobs can be schedules or one off and run within the context of the TFS Server Itself. They are a compiled DLL that has to be deployed to a particular folder on the TF Server in order to be loaded and registered with TFS.
  2. TF Event Sink – Events are fired on the TF Server as a result of Work Item, Build, Source Code changes and implement the ISubscriber interface. Again they need to have the containing DLL dropped into the correct folder on the TF Server.
  3. Custom Controls – Sometimes you want to extend the UI of  work items capability to display data and this requires both server side and client side components to be deployed.
  4. Check-in Policy – These policies are evaluated at check-in both on the Client and on a Build Server as part of a Gated Check-in. They need to be registered in the system register to be executed but have no special folder.
  5. Soap Events – These are like TF Event Sinks but they are more disconnected from TFS. They do need to be registered with TFS, but it is a SOAP registration rather than integral to the server itself. With the introduction of TF Event Sinks there is little need for this, but if you want to have events from TFS 2008 or TFS 2010 then it may be a viable solution for backward compatibility.

With our Team Foundation Server more commonly being managed by infrastructure teams there is less access to those servers to install and update those extensions. In essence they are very rarely productionised. While it is a fantastic thing to have what amounts to better supported server we still need to be able to add these extensions.

I want to be able to go to a webpage on my Team Foundation Server that allows me to search for and find extensions that can then be selected and installed.

The Plan

This sounds simple, but in-fact it can be fairly complex. We plan to create this delivery mechanism and create documentation on how to create packages to do all of these things… will we have everything from day-one? No way… we will be iteratively adding functionality  we get feedback on what we have delivered and changing our roadmap to incorporate that feedback.

  1. DONE – Create ability to publish and manage packages

    We decided to use myget as it provides a lot of services including permissions and a web UI that we do not need to build.

    image
    Figure: Using MyGet to provide hosted NuGet-as-a-service

  2. DONE – Create ability to search for and install packages

    We have already added some features to the application and it will already allow installs of packages and pass the information required for deployment to the packages.

    image
    Figure: Search for Team Foundation Server extensions

  3. Create ability to customise configuration
  4. Create ability to create custom configurations

We plan on having the first release soon with #1 & #2 above and include everything that you can install server side. As Extension creators and Extension users express a need for additional features we will prioritise them and include those requests over time. This will be a single install for your TFS server that makes all of the available extensions just a click away.

The Team

I have a couple of folks helping me on this little project and we are always looking for others that can help add value.

  •  
    James Tupper
    , ALM Consultant & ALM Champ

  • Andrew Clear
    , ALM Developer

I am open for others to join and you would only need to contribute around 2 hours a week to participate.

The TFS Automation Platform is dead, long live the TfPlugable was last modified: January 31st, 2013 by Martin Hinshelwood

-Every company deserves working software that successfully and consistently meets their customers needs on a regular cadence. We can help you get working software with continuous feedback so that your lean-agile teams can deliver continuous value with Visual Studio ALM, Team Foundation Server & Scrum. We have experts on hand to help improve your process and deliver more value at higher quality.

  • Betty

    I still like the idea, but don’t think you’re going about it quite right.

    Personally I think it makes more sense to make a couple of install helpers for chocolatey instead (see your chocolateyInstallhelpersfunctions directory), then create chocolatey packages which depend on the helpers to do the install. MyGet supports chocolatey last I checked so you could still use it as the package backend, although it may just be worth sticking them in the main chocolatey repo.

    Then the web interface should also be an extension to chocolatey which allows remote package installation, seems like a far more useful/reusable project. If you add an api to it then you could also have it on developer boxes as well as the TFS server. Imagine installing any chocolatey package (eg checkin policies) by using a simple POST request to any machine that needs it.

    More powershell cmdlets for TFS commands could be really useful, the tfs powertools started this but are missing a lot. Although this sounds like a totally separate project again (which could be installed via chocolatey)

    • http://blog.hinshelwood.com/ Martin Hinshelwood

      I am extending the NuGet.Core as I want to deliberately have a specific package form. This is slightly different from NuGet as we have to support multiple versions of Team Foundation Server rather than multiple frameworks…

      • Betty

        You could handle that in a similar way to the way Chocotely does 32 vs 64bit. Although I guess that wouldn’t give you server side filtering which I’m guessing you want.

        • http://blog.hinshelwood.com/ Martin Hinshelwood

          Most of what I am installing does not have an installer. No MSI, only a collection of files that need to be dropped into folders under the Team Foundation Server install location…

          • Betty

            Which is why I suggested writing a Chocolatey helper function, just a powershell script that can copy files anywhere you want. But can have the smarts in it to check install directorys and required components.

          • http://blog.hinshelwood.com/ Martin Hinshelwood

            Do you have documentation on how to do that? I only have little knowledge of PowerShell and the API’s for NuGet were a lot more accessible.. I did look at Chocolatey but I could not find any entrypoints or documentation…

          • Betty

            Sadly I haven’t found much documentation, it’s normally a mix of copying other packages + asking Rob for help.

          • ferventcoder

            Hey folks, Rob here. Is using the github wiki really that bad? If so we can start migrating the documentation to the website. Let me know.

          • Betty

            The docs aren’t too bad imo, they just don’t cover advanced topics like creating and installing helpers for other packages (unless I just can’t find it?). @Rob Was hoping you could give some thoughts on chocolatey targeting different versions of already installed software (in this case tfs 2008/2010/2012) and reactiing accordingly

          • ferventcoder

            PowerShell can definitely target different version of already installed software (registry lookups in most cases). Since choco is just a nice wrapper for running powershell, you can do pretty much anything ;)

      • Betty

        Other benefits? Packages could have dependencies, eg auto install TFS power tools, a windows service, or setup some TFS features via powershell scripts. Chocolately already has a number of TFS related packages (although not plugins like you’re planning) – http://chocolatey.org/packages?q=tfs

  • http://www.xavierdecoster.com/ Xavier Decoster

    Wow! Great to see you’re leveraging NuGet as a protocol for distributing TFS plug-ins. Even more awesome you’re using MyGet for that!

    MyGet indeed supports Chocolatey out-of-the-box. Basically, you could use the MyGet interface on top of Chocolatey, as you can create any feed and hook up some package sources underneath, such as Chocolatey.org which is a preset. We have a blog post on how to do that: http://blog.myget.org/post/2012/03/01/MyGet-tops-Vanilla-NuGet-feeds-with-a-Chocolatey-flavor.aspx

    Don’t hesitate to reach out to us if you need assistance or want to share your valuable feedback.

  • Pingback: Visual Studio ALM Links–Week 5 2013()

  • Daniel Schroeder

    This sounds great! Adding these types of TFS extensions has always been a pain. Like you said, even little things like the checkin policies. Why does it have to be so hard! I’m really looking forward to this project and it streamlining the process of installing TFS extensions……..and being able to find extensions in a common store :) Great news; I can’ wait!

  • http://profiles.google.com/john.ludlow.uk John Ludlow

    I definitely need the SOAP events. We have some extensions which use the dll extension mechanism, but there’s no way of debugging or configuring them without getting onto the TFS box, and because of new corporate guidelines, only IT are allowed on the TFS box.

    Edit: is this available to play with? I’d like to see how the SOAP event sink works

  • Kevin Treadwell

    Any update? Any downloadable bits?

    • http://blog.hinshelwood.com/ Martin Hinshelwood

      Soon… I am working on getting a first beta really soon… its a spare time project so…

    • http://blog.hinshelwood.com/ Martin Hinshelwood

      So I am planning to release this to Chocolatey real soon. I have a few bugs to work out and some automation issues but what I have so far works. It then becomes about the packages :)