Proposal: Dependency Replicator Changes

Whilst I was waiting at Changi Airport waiting for my flight to Cairo I created a new branch of the TFS Dependency Replicator code. The change that I have been making is changing the code so it uses IBuildDefinition and IBuildDetail instances instead of BuildData instances. In doing so I made it aware of the alternative configuration paths for the build directory (where the TFSBuild.proj file is located).

The implication is that the traditional location of the TeamBuildTypes folder may no longer be valid. Instead it will look for the DependencyReplicator.xml file in the same directory as the TFSBuild.proj file. The side effect (implications leading to side effects, is that like a double pointer?) is that the BuildType property on the Rule element is no longer required, rather it is implied by the location of the DependencyReplicator.xml file.

Before I unilaterally go and change the Trunk with this change I want to implement the code so it falls back to its original behaviour but I also wanted to know what others thought. There are a few other issues that I need to address in a future release:

  1. Performance, at the moment it is a very heavy poll mechanism. I avoided TFS evening because of previous reliability experiences, but and event based model would be better.
  2. Plug-ins. Birgir Stefansson is going to be working on the code base soon and wants the rule base system to be more configurable, I can grok that but I’d be interested in others thoughts about how plug-ins would be useful.

One thought on “Proposal: Dependency Replicator Changes

  1. Birgir Stefansson

    IIRC all tfs projects were scanned for DependencyReplicator.xml config files located in the TeamBuildTypes directory e.g. $/TeamProject/TeamBuildTypes. For each of the configuration files rules were extracted and if they matched the builddefinition they were triggered. This locating of config files enabled each config file to be stand-alone (independent of builddef) and rules for multiple builddefs could be defined in each config file.

    As I understand the proposal it seems to me that it changes the current behavior a bit as now there is a single config file for each builddef with all rules associated with that particular builddef.

    The contrast is basically pull vs push mechanisms whereas currently you can pull dependencies to teamprojects where a builddef is a dependency by way of defining rules in multiple config files – each located in each corresponding team project. The proposal implies pushing dependencies to the dependent teamprojects by associating the config file with the builddef.

    I think your proposed way of accomplishing this might be better than the current method in the sense that all replication rules are bundled together instead of being dispersed throughout TFS eliminating the locating of the config files problem as well as making organization easier. I could see a problem with this if users do not have access to all team projects and therefore not access to DependencyReplicator.xml for build definitions they want to replicate. Perhaps it is not a problem as it should only be a build master with full access that should be able to define dependency replication rules anyway?

    I think that this behaviour could be configurable to accommodate for both methods as well as perhaps a third option which could be a master DependencyReplicator.xml config file maintained outside of tfs by a build master. That way dependency replication could even cross tfs servers.

    What do you think?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s