Rally Software

 View Only

What do you do with custom field handlers when you...

  • 1.  What do you do with custom field handlers when you...

    Posted Dec 17, 2014 12:52 PM
    What do you do with custom field handlers when you have a large number of projects to integrate between systems? In my environment, I have 18 sets of synchronizations, each of which averages 3 projects to be synchronized, each project synchronized user stories, test cases, and test case results.  This starts to get difficult to handle, particularly around custom field handlers and username mapping. Managing all of these files quickly becomes a nightmare, but I've come up with a way to simplify it a bit.  First off, each set of synchronizations are put into their own folder within a common parent folder.  This way, everything in the parent folder is related to the Rally Integrations to be performed.  happily, Rally solved the username mapping having to be in each of the relevant *_config.xml files with the advent of the CSV file, which I put into the parent folder and had the *_config.xml file refer to this one CSV file.  Whenever I update the CSV file, all integrations pick up the change immediately without having to copy it all over the place. The next big headache with files was the custom field handlers, which traditionally reside in the field_handlers folder within each folder for a set of synchronizations.  This is a lot of file copying whenever something changes (like going from a symbol to a string).  To solve this one, I did a bit of trickery.  I found the Rally ruby code that normally loads the custom field handlers and made a copy of it with a new name and set it to load from a folder in a well known place, followed by a call to the updated loader.  I, then, put this file in the field_handlers folder.  In the parent folder I created a folder called _field_Handlers, into which all my custom field handlers.  Now I have one place for my username mapping and one place for my custom field handlers.  I change either of these, then all 18 sets of synchronizations automatically pick up the changes, without the need to copy the updates 18 times. Now, if I can find a way to have a common set of *_config.xml files, I'd make this very easy to maintain.