Anatomy of an Automation for the TFS Automation Platform

we would really like for you to still be able to build out automations without the automation platform, but you would not have the delivery and management aspects. hopefully this post will guide you on how you can integrate your work with the tfs automation platform later.

note: this product is still under development and this document is subject to change. there is also the strong possibility that these are just rambling fantasies of a mad programmer with an architect complex.

well, we will be integrating integrating with many of the tfs elements as proxies so that we can leverage existing code without having to rewrite things. for a rough understanding of the architecture and where you can start building things now lets look at the generic scenario:

1. installation

   assemblies and other supporting files are dropped into the correct plugins folder on the server

2. configuration

   there is some settings stored somewhere that will control how the process runs

3. action
   there are three types of action:

   1. user action – the user deliberately setts a process running

   2. event – an event is raised on the server (e.g. workitemchangedevent)

   3. schedule – a particular time is reached

4. processing

   some amount of work is done

installation

there are a number of places that you need to put files on the tfs server to have them loaded effectively:

• event handlers (isubscribers) – c:\program files\microsoft team foundation server 2010\application tier\web services\bin\plugins
• tfs jobs (iteamfoundationjobextension) – c:\program files\microsoft team foundation server 2010\application tier\tfsjobagent\plugins\*

our installation will be two fold. first is the download of the ".zip” archive containing all of the require files and unpacking them, probably to:

c:\program files\microsoft team foundation server automation platform\automations\[automationname]

the second stage will occur when an administrator “activates” the plugin for your server. this will look for a manifest file in the automation folder that will tell it what components are part of the automation. the installer will know where on the server the files need to go and deploy them to that location.

configuration

for configuration we are probably going to have a class that holds the settings that is sterilised and stored in tfs as property’s. this will allow us to have both static and instance config, but i would not worry about were these are currently stored as you will probably need to have your own storage mechanism for now. however, if you are curious on the current thinking:

figure: where will the data be stored

any ui required to exit the plugin data will need to be included in the package and we have not yet decided how this should happen. with .net it is a little more difficult to inject ui and it will probably end up being silverlight.

figure: injecting ui in silverlight is easy

action

although there are a number of types of action, the goal is the same; to add a job to the job queue in tfs that will do the processing. the action can be triggered either by the user or when an event is fired in tfs.

server side actions

if it is a user interaction that caused the action then there was probably a silverlight ui assembly or package stored within the installable automation package. when it was unpacked the new ui became available.

it it was a server event driven action then an assembly with a class that implements isubscriber was installed to the plugins folder of the website where it was loaded into the pipeline for events.

the result is that configuration will be added to “tfsintegrationplatform-[automation]” that will be loaded by the tfs job next time it is run.

note: if you build normal server side event handlers then we will try to allow you to wrap them later with minimal code changes

client side actions

if the action was based on a check-in event on the client or server then the assembly that contained the check-in policy was loaded into the correct place and the correct registry entries added. there was previously some progress in this direction with the power tools, but it was difficult to implement and little known.

note: if you build normal checkin policies we will try to allow you to wrap them later and deploy as part of an automation package without having to change the code.

processing

the processing is where the magic happens and in order to provided some level of robustness this should be run on the  tfs job agent (iteamfoundationjobextension) that can be restarted when the server is rebooted. once the “action” has updated the correct settings for the automation the job will queued. when the job runs it will load its settings from at “tfsintegrationplatform-[automation]” and run through each configured instance as needed.

the only communication between the outside world and the job is through the settings stored as tfs properties.

note: if you build a iteamfoundationjobextension then we will try to allow you to wrap it later with minimal code changes

conclusion

it should be possible for you to create isubscribers, iteamfoundationjobextension and policybase classes that perform your needs and we will allow you to package them separately or together with space for a ui and other functionality later.

there is no reason not to extend tfs now and once the tfs automation platform releases there will be no need to ever install another extension again apart from the tfs automation platform itself…