Best Practice for Rules Configurations

[jprettyman]

This is more of a question for clarification as opposed to a feature request.

I am looking on guidance on best practices on setting up and implementing rules. Because my rules need to traverse the hierarchy both up and down, I would like to ensure that I implement these rules in the most efficient manner. The question is: Should I implement a rule per work item or have a single rule with both worktime methods in them? My Current Task rule looks like this:

if (self.Parent != null && self.WorkItemType == "Task")
{
    var parent = self.Parent;
    var children = parent.Children;
        foreach (var child in children )
	{
		// Only get values from tasks
		if (child.WorkItemType == "Task")
		{
			totValue +=  Convert.ToDouble(child["Microsoft.VSTS.Scheduling.CompletedWork"]);
			remainValue +=  Convert.ToDouble(child["Microsoft.VSTS.Scheduling.RemainingWork"]);
		}
	}
	// only write if there is a summed value
	if (totValue > 0)
	{
		parent["Microsoft.VSTS.Scheduling.CompletedWork"] = totValue;
	}
	// only write if there is a summed value
	if (remainValue > 0)
	{
		parent["Microsoft.VSTS.Scheduling.RemainingWork"] = remainValue;
	}
}

I need to add another set of functionality for PBIs and Bugs such that some fields will be written to the tasks when the PBI or Bug is modified. I am looking to ensure that I do not get into a cyclical loop where the Task updates the Bug and then the bug updates the task. How to ensure calls do not get out of hand. So, Is it best to have the entire operation in a single rule or create a rule for each work item?

[BobSilent]

So let me start with some information and maybe at the end this is something which should be reflected in our documentation.

My Rules of Thumb

1. Execution Flow: First of all define criteria's, when the rule should not be executed (exit condition)
2. One Field should be updated only by one rule
3. A rule can update multiple fields
4. Try to update only self and work items in direct relation to self, or in other words do not update work items not in relation with self. As saving the changed items will lead to a new work item update event which will be handled. This way an information can ripple up or down and that's why the exit condition is so important

When writing the Rule

1. First step in rule execution is checking the exit conditions and exit if required
2. Start with checking simple exit conditions before getting more complex (means first check all on self before checking any related work item, as this also means a server roundtrip to get the data)

Look here for some more advanced examples.

...to be continued

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[BobSilent]

i just reopen it, to update documentation with this information