My TFSAlertsDSL project has moved to GitHub and become VSTSServiceHookDsl

Introduction

A while ago I create the TFSAlertsDSL project to provide a means to script responses to TFS Alert SOAP messages using Python. The SOAP Alert technology has been overtaken by time with the move to Service Hooks.

So I have taken the time to move this project over to the newer technology, which is supported both on TFS 2015 (onwards) and VSTS. I also took the chance to move from CodePlex to GitHub and renamed the project to VSTSServiceHookDsl.

Note: If you need the older SOAP alert based model stick with the project on CodePlex, I don’t intend to update it, but all the source is there if you need it.

What I learnt in the migration

Supporting WCF and Service Hooks

I had intended to keep support for both SOAP Alerts and Service Hooks in the new project, but I quickly realised there was little point. You cannot even register SOAP based alerts via the UI anymore and it added a lot of complexity. So I decided to remove all the WCF SOAP handling.

C# or REST TFS API

The SOAP Alert version used the older TFS C# API, hence you had to distribute these DLLs with the web site. Whilst factoring I decided to swap all the TFS calls to using the new REST API. This provided a couple of advantages

• I did not need to distribute the TFS DLLs

• Many of the newer function of VSTS/TFS are only available via the REST API

  Exposing JObjects to Python

  I revised the way that TFS data is handed in the Python Scripts. In the past I hand crafted data transfer objects for consumption within the Python scripts. The problem with this way of working is that it cannot handle custom objects, customised work items are a particular issue. You don’t know their shape.

  I found the best solution was to just return the Newtonsoft JObjects that I got from the C# based REST calls. These are easily consumed in Python in the general form

  1workitem\["fields"\]\["System.State"\] 
  

  Downside is that this change does mean that any scripts you had created for the old SOAP Alert version will need a bit of work when you transfer to the new Service Hook version.

  Create a release pipeline

  As per all good projects, I created a release pipeline for my internal test deployment. My process was as follows

  • A VSTS build that builds the code from Github this
    • Complies the code
    • Run all the unit test
    • Packages as an MSDeploy Package
  • Followed by a VSTS release that
    • Sets the web.config entries
    • Deploys the MSDeploy package to Azure
    • Then uses FTP to uploaded DSL DLL to Azure as it is not part of the package

   

  Future Steps

  Add support for more triggers

  At the moment the Service Hook project supports the same trigger events as the old SOAP project, with the addition of support Git Push triggers.

  I need to add in the handlers for all the older support triggers in VSTS/TFS, specifically the release related ones. I suspect these might be useful.

  Create an ARM template

  At the moment the deployment relies on the user creating the web site. It would be good to add an Azure Resource Management (ARM) Template to allow this site to be created automatically as part of the release process

  Summary

  So we have a nice new Python and Service Hook based framework to help manage your responses to Service Hook triggers for TFS and VSTS.

  If you think it might be useful to you why not have a look at https://github.com/rfennell/VSTSServiceHookDsl.

  Interested to hear your feedback