-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathindex.xml
111 lines (111 loc) · 38.5 KB
/
index.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Aggregator</title><link>https://tfsaggregator.github.io/</link><description>Recent content on Aggregator</description><generator>Hugo -- gohugo.io</generator><language>en-us</language><atom:link href="https://tfsaggregator.github.io/index.xml" rel="self" type="application/rss+xml"/><item><title>How it Works</title><link>https://tfsaggregator.github.io/docs/v2/intro/how-it-works/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tfsaggregator.github.io/docs/v2/intro/how-it-works/</guid><description>Web Service # The Web Service is deprecated, use Aggregator CLI instead.
Visual Studio Team Services (VSTS) and TFS (2015 and later) can integrate with other systems through Service hooks. TFS Aggregator Web Service leverage the Web Hooks variant to receive notifications of work items changes in VSTS/TFS.
The common scenario is:
A user changes some work item&rsquo;s data using Visual Studio or TFS Web Interface, then presses the Save button (or hits Ctrl-S); VSTS/TFS validates the edit and saves the changes to the database; VSTS/TFS call the Aggregator Web Service using HTTPS, the message contains information on the type of change, the instance, project and work item; Aggregator see which Rules apply and execute them, which may call back the loading additional work items; Aggregator calls back VSTS/TFS using HTTPS to save any changed work item.</description></item><item><title>Code of Conduct</title><link>https://tfsaggregator.github.io/docs/v2/intro/slack-coc/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tfsaggregator.github.io/docs/v2/intro/slack-coc/</guid><description>TFS Aggregator Slack - Code of Conduct # Be polite: there is a person on the other side, not a machine, could be a 12-years old developer (yes, it happened). Think before writing.</description></item><item><title>Common options</title><link>https://tfsaggregator.github.io/docs/v3/commands/common-options/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tfsaggregator.github.io/docs/v3/commands/common-options/</guid><description>Verbose option # All commands accept the --verbose option (or -v in the short form) to print additional messages for troubleshooting.
Naming Templates # With --namingTemplate, you can specify affixes for all Azure resource that will be created or used. follows
{ &#34;ResourceGroupPrefix&#34;: &#34;aggregator-&#34;, &#34;ResourceGroupSuffix&#34;: &#34;-sfx&#34;, &#34;FunctionAppPrefix&#34;: &#34;fp&#34;, &#34;FunctionAppSuffix&#34;: &#34;fs&#34;, &#34;HostingPlanPrefix&#34;: &#34;hp&#34;, &#34;HostingPlanSuffix&#34;: &#34;hs&#34;, &#34;AppInsightPrefix&#34;: &#34;aip&#34;, &#34;AppInsightSuffix&#34;: &#34;ais&#34;, &#34;StorageAccountPrefix&#34;: &#34;strg&#34;, &#34;StorageAccountSuffix&#34;: &#34;31415&#34; } If you use the --namingTemplate option, the --resourceGroup option is mandatory.</description></item><item><title>Writing Rules and Policies</title><link>https://tfsaggregator.github.io/docs/v2/using/writing-rules/writing-rules/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tfsaggregator.github.io/docs/v2/using/writing-rules/writing-rules/</guid><description>The samples\TFSAggregator2.ServerPlugin.policies should be your starting point. This file contains a no-harm policy: it simply logs an &ldquo;Hello, World&rdquo; message when invoked. The comments remind the syntax.
Editing a policy # The XML Schema definition is in file Aggregator.Core\Configuration\AggregatorConfiguration.xsd. This is the ultimate truth: policy file is checked against XSD before being used.
It can also help you editing the policy file in Visual Studio. Open TfsAggregator2 solution in Visual Studio, open a policy file using built-in Xml editor, Select XML from the main menu, then Schemas.</description></item><item><title>Authentication commands</title><link>https://tfsaggregator.github.io/docs/v3/commands/authentication-commands/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tfsaggregator.github.io/docs/v3/commands/authentication-commands/</guid><description>The first step for using Aggregator CLI is to logon into both Azure and Azure DevOps. You can a single command, logon.env, or two separate commands, logon.azure and logon.ado. The former is most useful in an automated scenario, while the other two can be more practical in an interactive session. Use the logoff command to remove any cached authentication data.
logon.azure # Logon into Azure. This must be done before other verbs.</description></item><item><title>Configuration XML syntax</title><link>https://tfsaggregator.github.io/docs/v2/using/policy-syntax/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tfsaggregator.github.io/docs/v2/using/policy-syntax/</guid><description>This page describes the content of a policy file.
&lt;?xml version=&quot;1.0&quot; encoding=&quot;utf-8&quot;?&gt; This is the basic beginning to an XML file. Do not change it.
&lt;AggregatorConfiguration&gt; AggregatorConfiguration: The main node for all the configuration options. (Single)
runtime section # This section controls general behaviour for TFS Aggregator, e.g. authentication, credentials or logging level.
&lt;runtime debug=&quot;False&quot;&gt; runtime: Configure generic behavior. (Once, Optional)
debug: turns on debugging options (Optional, default: False) &lt;rateLimiting interval=&quot;00:00:10.</description></item><item><title>Instance commands</title><link>https://tfsaggregator.github.io/docs/v3/commands/instance-commands/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tfsaggregator.github.io/docs/v3/commands/instance-commands/</guid><description>Azure Resource Names # Aggregator CLI has three ways of generating names for Azure Resources. Keep in mind, that Azure Function App and Storage resources must have unique names in Azure.
Basic template # This template is used when you do not specify the --resourceGroup option.
In this scenario Aggregator tries to create an Azure Resource Group for each instance. The name of the resource group derives from the instance name.</description></item><item><title>Scripting the Rules</title><link>https://tfsaggregator.github.io/docs/v2/using/scripting/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tfsaggregator.github.io/docs/v2/using/scripting/</guid><description>Script languages # You can use C# and VB.Net to write your rules. Powershell also works but we had little tested it.
C# and VB # You can use only types from these assemblies:
System System.Core Microsoft.TeamFoundation.WorkItemTracking.Client Aggregator.Core Any other reference will result in compile errors. The following namespaces are imported (C# using, VB Imports):
Microsoft.TeamFoundation.WorkItemTracking.Client System.Linq Microsoft.TeamFoundation.WorkItemTracking.Client.CoreFieldReferenceNames Aggregator.Core and descendants Code # You can make your code more modular, using macro snippets or functions.</description></item><item><title>Rule commands</title><link>https://tfsaggregator.github.io/docs/v3/commands/rule-commands/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tfsaggregator.github.io/docs/v3/commands/rule-commands/</guid><description>add.rule # Add a rule to existing Aggregator instance in Azure. It requires three mandatory options.
Option Short form Description --instance -i The name of an existing Aggregator instance (Azure Function App). --name -n The name of the new Rule. This will be the name of the Azure Function. --file -f Relative or absolute path to the file with the Rule code.</description></item><item><title>self Object</title><link>https://tfsaggregator.github.io/docs/v2/using/objects-reference/self-object/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tfsaggregator.github.io/docs/v2/using/objects-reference/self-object/</guid><description>Represents the work item that triggered the rule and corresponds to the IWorkItemExposed interface.
Fields collection # You can directly access a Field using its name:
self.Fields[&quot;field_name&quot;] Prefer using Reference names e.g. System.Title as they do not depend on localization and are more resilient to Process template changes.
To simply access a field value, you can use self[&quot;field_name&quot;] as a shorthand for self.Fields[&quot;field_name&quot;].Value
For numeric and dates you may prefer using</description></item><item><title>Field Object</title><link>https://tfsaggregator.github.io/docs/v2/using/objects-reference/field-object/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tfsaggregator.github.io/docs/v2/using/objects-reference/field-object/</guid><description>Fields collection # You can iterate over the Field collection of a work item.
foreach (var f in self.Fields) { logger.Log(&quot;{0} #{1} has {2} field&quot;, self.TypeName, self.Id, f.Name); } You can directly access a Field using its name:
self.Fields[&quot;Title&quot;] Prefer using Reference names, e.g. System.Title, as they do not depend on localization and are more resilient to Process template changes.
Field Object # The Field object exposes the following properties:</description></item><item><title>store Object</title><link>https://tfsaggregator.github.io/docs/v2/using/objects-reference/store-object/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tfsaggregator.github.io/docs/v2/using/objects-reference/store-object/</guid><description>Represents the current Collection&rsquo;s Work Items and corresponds to the IWorkItemRepositoryExposed interface. It exposes these methods:
GetWorkItem MakeNewWorkItem GetGlobalList AddItemToGlobalList (v2.3) RemoveItemFromGlobalList (v2.3) GetWorkItem method # Retrieves a work item from the current Collection by ID.
var myWorkitem = store.GetWorkItem(42); MakeNewWorkItem methods # Add a new WorkItem to current Collection.
var newWorkItem = store.MakeNewWorkItem((string)self[&quot;System.TeamProject&quot;], &quot;Bug); This syntax will create the new work item in the same TeamProject as self.</description></item><item><title>logger Object</title><link>https://tfsaggregator.github.io/docs/v2/using/objects-reference/logger-object/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tfsaggregator.github.io/docs/v2/using/objects-reference/logger-object/</guid><description>Allows to add a trace message to the log output via the Log method.
Log method # It works like Console.WriteLine, accepting a format string followed by optional arguments. If you do not specify the importance, the message will be logged at Verbose level.
Examples # logger.Log(&quot;Hello, World from {1} #{0}!&quot;, self.Id, self.TypeName); logger.Log(LogLevel.Warning, &quot;Unexpected work item state!&quot;); Possible LogLevel values are:
Critical Error Warning Information Verbose Diagnostic Each message goes to</description></item><item><title>Library Objects</title><link>https://tfsaggregator.github.io/docs/v2/using/objects-reference/library-objects/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tfsaggregator.github.io/docs/v2/using/objects-reference/library-objects/</guid><description>Library of utility functions. (v2.2) It exposes two static methods SendMail and GetEmailAddress.
GetEmailAddress # Retrieve the email address for a user.
Caveat: This method works only in the Server Plugin
You can use the DOMAIN\user form,
string email = Library.GetEmailAddress(&quot;WIN-3H7CMUV7KDM\\User1&quot;, &quot;[email protected]&quot;); or the User Display name.
string email = Library.GetEmailAddress(&quot;User One&quot;, &quot;[email protected]&quot;); SendMail # Send an email using TFS current configuration.
Caveat: This method works only in the Server Plugin</description></item><item><title>Mapping commands</title><link>https://tfsaggregator.github.io/docs/v3/commands/map-commands/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tfsaggregator.github.io/docs/v3/commands/map-commands/</guid><description>map.rule # Maps an Aggregator Rule to existing Azure DevOps Projects. In other words it creates a webhook in Azure DevOps for the selected event and project.
These parameters identify the Rule.
Option Short form Description --instance -i The name of an existing Aggregator instance (Azure Function App). --resourceGroup -g Azure Resource Group that contains the Aggregator instance. --namingTemplate n/a Specify affixes for Azure resources.</description></item><item><title>Accumulate to grand-parent example</title><link>https://tfsaggregator.github.io/docs/v2/using/examples/accumulate-to-grand-parent/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tfsaggregator.github.io/docs/v2/using/examples/accumulate-to-grand-parent/</guid><description>Process template: Any
Add the AccumulatedWork from Tasks up to grand-parent, i.e. Feature.
&lt;rule name=&quot;updateFeatureScrumAccrued&quot; appliesTo=&quot;Task&quot; hasFields=&quot;CustomField.AccumulatedWork&quot;&gt;&lt;![CDATA[ IWorkItemExposed topFeature = self.FollowingLinks(&quot;System.LinkTypes.Hierarchy-Reverse&quot;).WhereTypeIs(&quot;Feature&quot;).AtMost(5).FirstOrDefault(); if (topFeature != null) { logger.Log(&quot;Feature {0}&quot;, topFeature.Id); var taskChildren = topFeature.FollowingLinks(&quot;System.LinkTypes.Hierarchy-Forward&quot;).WhereTypeIs(&quot;Task&quot;).AtMost(5); var sum = 0.0; foreach (var task in taskChildren) { sum += task.GetField&lt;double&gt;(&quot;CustomField.AccumulatedWork&quot;, 0.0); } topFeature[&quot;CustomField.ScrumAccrued&quot;] = sum; } ]]&gt;&lt;/rule&gt;</description></item><item><title>Auto-Create Children example</title><link>https://tfsaggregator.github.io/docs/v2/using/examples/auto-create-children/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tfsaggregator.github.io/docs/v2/using/examples/auto-create-children/</guid><description>Example: Auto-Create Children # Process template: Any
This example can serve to create a set of standard tasks for work items of a certain type. Say:
Analyze issue Fix issue Test issue &lt;!-- WorkItems --&gt; &lt;rule name=&quot;NewTask&quot; appliesTo=&quot;Bug&quot;&gt; &lt;![CDATA[ var parent = self; if (!self.HasChildren()) { // use self to pass in the Team Project Context var child = store.MakeNewWorkItem(self, &quot;Task&quot;); child[&quot;Title&quot;] = &quot;Task auto-generated for &quot; + parent[&quot;Title&quot;]; // use the name of the relationship or one of the pre-defined static values // by adding the link to the child, you don't change the parent in this script.</description></item><item><title>Auto-Open and Auto-Close example</title><link>https://tfsaggregator.github.io/docs/v2/using/examples/auto-open-auto-close/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tfsaggregator.github.io/docs/v2/using/examples/auto-open-auto-close/</guid><description>Applies to Scrum Process template
&lt;rule name=&quot;AutoOpen&quot; appliesTo=&quot;Task&quot;&gt; &lt;!-- Update Work Item to Committed if a task became &quot;active&quot; --&gt; &lt;![CDATA[ if (new[] {&quot;In Progress&quot;, &quot;To Do&quot;}.Contains((string)self[&quot;System.State&quot;])) { if(self.HasParent() &amp;&amp; ((string)self.Parent[&quot;System.State&quot;]) != &quot;Committed&quot;) { self.Parent.TransitionToState(&quot;Committed&quot;, &quot;Auto Activated&quot;); } } ]]&gt; &lt;/rule&gt; &lt;rule name=&quot;AutoClose&quot; appliesTo=&quot;Task&quot;&gt; &lt;!-- Update Work Item to Done if a all child tasks are Done or Removed --&gt; &lt;![CDATA[ if ((string)self[&quot;System.State&quot;] == &quot;Done&quot; &amp;&amp; self.HasParent() &amp;&amp; ((string)self.Parent[&quot;System.State&quot;]) != &quot;Done&quot;) { if (self.</description></item><item><title>Remaining Work and Completed Work synchronization for Task WI</title><link>https://tfsaggregator.github.io/docs/v2/using/examples/log-time-synch/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tfsaggregator.github.io/docs/v2/using/examples/log-time-synch/</guid><description>This is an example of automation that allows keep consistency between Remaining Work and Completed Work for Task WI
General Flow:
Remaining Work decreased (and Completed Work not changed) =&gt; then increase Completed Work accordingly Completed Work increased (and remainin Work not changed) =&gt; then decrease Remaining Work accordingly All other cases don&rsquo;t require any modifications as they are threated as re-estimation and should follow user decision Process template: Agile or any template that has RemainingWork and CompletedWork fields for Task WI</description></item><item><title>Rollup examples</title><link>https://tfsaggregator.github.io/docs/v2/using/examples/rollup/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tfsaggregator.github.io/docs/v2/using/examples/rollup/</guid><description>Using Linq to Aggregate # Applies to Scrum or CMMI Process templates.
&lt;rule name=&quot;RollupTask&quot; appliesTo=&quot;Task&quot;&gt;&lt;![CDATA[ if (self.HasParent()) { var parent = self.Parent; parent[&quot;Microsoft.VSTS.Scheduling.CompletedWork&quot;] = parent.Children.Sum(task =&gt; task.GetField&lt;double&gt;(&quot;Microsoft.VSTS.Scheduling.CompletedWork&quot;, 0d)); parent[&quot;Microsoft.VSTS.Scheduling.RemainingWork&quot;] = parent.Children.Sum(task =&gt; task.GetField&lt;double&gt;(&quot;Microsoft.VSTS.Scheduling.RemainingWork&quot;, 0d)); parent[&quot;Microsoft.VSTS.Scheduling.OriginalEstimate&quot;] = parent.Children.Sum(task =&gt; task.GetField&lt;double&gt;(&quot;Microsoft.VSTS.Scheduling.OriginalEstimate&quot;, 0d)); } ]]&gt;&lt;/rule&gt; This rule updates a Product Backlog Item or Bug whenever any child Task is added or changes. The Completed Work, Remaining Work and Original Estimate on the parent become the sum of the corresponding fields of children Tasks.</description></item><item><title>Informational commands</title><link>https://tfsaggregator.github.io/docs/v3/commands/info-commands/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tfsaggregator.github.io/docs/v3/commands/info-commands/</guid><description>list.instances # Lists Aggregator instances, that is Azure Function Apps, within the Azure Subscription.
You should specify at least one of these options to limit the search scope.
Option Short form Description --location -l Name of Azure region hosting the Aggregator instance. --resourceGroup -g Azure Resource Group that contains the Aggregator instance. --namingTemplate n/a Specify affixes for Azure resources.</description></item><item><title>Tricks & Tips</title><link>https://tfsaggregator.github.io/docs/v2/using/scripting-tricks-n-tips/scripting-tricks-n-tips/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tfsaggregator.github.io/docs/v2/using/scripting-tricks-n-tips/scripting-tricks-n-tips/</guid><description>The examples are in C#
Use Fields&rsquo; Reference Names # Write your rules using the Reference name for fields, e.g. Microsoft.VSTS.Common.Priority. That way your rules will work on process templates in different languages: Priority becomes Priorität in a German template.
Also the name may change in different template or newer version of the same template. Your rules are more likely to survive TFS upgrades unharmed.
Use Link Types&rsquo; Reference Names # Write your rules using the Reference name for link types, e.</description></item><item><title>Common Pitfalls</title><link>https://tfsaggregator.github.io/docs/v2/using/scripting-pitfalls/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tfsaggregator.github.io/docs/v2/using/scripting-pitfalls/</guid><description>Null # Any field can return null. Casting null to a numeric value or a date throws a NullReferenceException. The following C# code
(double)self.Parent[&quot;Microsoft.VSTS.Scheduling.OriginalEstimate&quot;] may succeed or throw.
There are many ways to overcame this issue: the null-coalescing operator, use the GetField helper function or check the Valid property. See Tricks&amp;Tips for examples.
History # The History and Revision properties are tricky.
Imagine this sequence:
A user opens a work item, whose Revision property values 7 She edits the Description field and saves TFS save the changes to the database and increments Revision to 8 Aggregator is notified of the change At this point self.</description></item><item><title>History field</title><link>https://tfsaggregator.github.io/docs/v2/using/field-history/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tfsaggregator.github.io/docs/v2/using/field-history/</guid><description>History field # The History field always appends a new message, the property allows to edit the message until work item is saved.
For example, this code causes an infinite loop (eventually stopped by rateLimiting feature).
self.History = &quot;Hello&quot;; Aggregator is triggered again and again for the same work item.
Some background information # The TFS aggregator only updates a work item if any field has changed by its calculations.</description></item><item><title>Examples</title><link>https://tfsaggregator.github.io/docs/v3/commands/command-examples/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tfsaggregator.github.io/docs/v3/commands/command-examples/</guid><description>Sample Aggregator CLI usage # This page will show you increasing complex examples of using Aggregator CLI.
To run Aggregator CLI type aggregator-cli.exe on Windows, ./aggregator-cli on Linux or dotnet aggregator-cli.dll on any followed by the command and options. In the examples, we will use aggregator-cli. In PowerShell you can define an alias to exactly match the examples:
Set-Alias aggregator-cli (Resolve-Path .\aggregator-cli.exe) IMPORTANT: Please avoid naïve copy&amp;paste of the examples, or other user will not be able to run the same.</description></item><item><title>Upgrading from v1</title><link>https://tfsaggregator.github.io/docs/v2/using/upgrade-from-v1/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tfsaggregator.github.io/docs/v2/using/upgrade-from-v1/</guid><description>Migrating from v1 # TFS Aggregator 2 is a full rewrite of the plugin. The old rule syntax is no longer supported. In case you&rsquo;re looking for the latest version of version 1.01, you can still find it here (including a large number of fixes and security updates).
If you want to upgrade to 2.x you&rsquo;ll have to rewrite your rules in the new format, the installation and upgrade process are explained below.</description></item><item><title>Directives</title><link>https://tfsaggregator.github.io/docs/v3/rules/directives/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tfsaggregator.github.io/docs/v3/rules/directives/</guid><description>Directives # The directives must appear in the first lines of a Rule file. They are parsed by Aggregator and removed before compiling the code.
language directive # .lang=C# .language=Csharp
Currently the only supported language is C#. You can use the .lang directive to specify the programming language used by the rule. If no language is specified: C# is default.
reference directive # Loads the specified assembly in the Rule execution context</description></item><item><title>Installing the Server Plugin</title><link>https://tfsaggregator.github.io/docs/v2/admin/install/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tfsaggregator.github.io/docs/v2/admin/install/</guid><description>This information does not apply to the Web Service version.
Pre-requisites # TFS # The TFS Aggregator works with the following versions of TFS:
TFS 2013 update 2,3,4,5 TFS 2015 RTM TFS 2015 update 1,2,3 TFS 2017 RTM TFS 2017 update 1 Azure DevOps Server 2019 Azure DevOps Server 2020 Azure DevOps Server 2022 The installer will detect the correct TFS version and will install the appropriate binary.</description></item><item><title>Using the console to test Policies</title><link>https://tfsaggregator.github.io/docs/v2/admin/console-app/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tfsaggregator.github.io/docs/v2/admin/console-app/</guid><description>The TFSAggregator2.ConsoleApp.exe command line tool is extremely useful to test and validate your policy files before applying to TFS.
BEWARE Any changed workitem is written to TFS database! Use a test TFS instance.
Syntax # TFSAggregator2.ConsoleApp.exe &lt;command&gt; [&lt;options&gt;] The only supported command is run.
If you launch the command without arguments, it will display an help screen.
Options # The available options are:
Option (short form) Option (long form) Usage -h --help Shows help message and exit -f --policyFile=VALUE Policy file to test -c --teamProjectCollectionUrl=VALUE TFS Team Project Collection Url, e.</description></item><item><title>WorkItem event objects</title><link>https://tfsaggregator.github.io/docs/v3/rules/workitem/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tfsaggregator.github.io/docs/v3/rules/workitem/</guid><description>These objects are available only for Work Items events.
WorkItem Object # The initial WorkItem object, the one which triggered the rule, is contained in the self variable.
Revisions # Navigate to previous versions of the work item.
WorkItem PreviousRevision Returns a read-only copy of the previous revision of this work item.
IEnumerable&lt;WorkItem&gt; Revisions Returns a read-only copy of all revisions of this work item.
Relations # Navigate to related work items.</description></item><item><title>Common objects</title><link>https://tfsaggregator.github.io/docs/v3/rules/common-rule-objects/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tfsaggregator.github.io/docs/v3/rules/common-rule-objects/</guid><description>The following objects are not event specific and can be used in any Rule.
Event variable [v0.9.11] # The event variable describes what triggered the rule. It can hold one of the following string constants.
&#34;workitem.created&#34; &#34;workitem.updated&#34; &#34;workitem.commented&#34; &#34;workitem.deleted&#34; &#34;workitem.restored&#34; This makes easier to write a single rule which reacts to multiple events.
Logger Object # The Function logger object is contained in the logger variable. It support four methods:</description></item><item><title>Logging</title><link>https://tfsaggregator.github.io/docs/v2/admin/logging/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tfsaggregator.github.io/docs/v2/admin/logging/</guid><description>TFS Aggregator logging is quite rich but the exact configuration depends on your environment.
Logging levels # The possible Logging levels are: Critical, Error, Warning, Information or Normal, Verbose, and Diagnostic.
Enable Debug Logging # To control the verbosity in TFS Aggregator, you have to set a level attribute to the logging element in your TFSAggregator2.ServerPlugin.policies file. Use a value like Verbose or Diagnostic.
&lt;?xml version=&quot;1.0&quot; encoding=&quot;utf-8&quot;?&gt; &lt;AggregatorConfiguration&gt; &lt;runtime&gt; &lt;logging level=&quot;Diagnostic&quot;/&gt; &lt;/runtime&gt; Note that you can use the logger object in your rules to trace execution and values.</description></item><item><title>Troubleshooting</title><link>https://tfsaggregator.github.io/docs/v2/admin/troubleshooting/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tfsaggregator.github.io/docs/v2/admin/troubleshooting/</guid><description>So you setup TFS Aggregator and it just sits there&hellip;. doing nothing&hellip;
Well, this is a check list of things to double check.
Server Plugin Checklist # You are using it on a TFS 2013 update 2 or later server You installed the right version for your TFS server You can verify if assembly version matches TFS version using this Powershell code $pathToAssemblyFile = &quot;C:\Program Files\Microsoft Team Foundation Server 15.</description></item><item><title>Support</title><link>https://tfsaggregator.github.io/docs/v2/admin/support/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tfsaggregator.github.io/docs/v2/admin/support/</guid><description>If you checked everything in Troubleshooting and it still does not work, create a new Issue on GitHub or send an email to [[email protected]](mailto:[email protected]?subject=Support Request). Please add any useful information like:
Aggregator version TFS version or VSTS Content of your TFSAggregator2.ServerPlugin.policies file (e.g. save it on https://gist.github.com/ and copy the link in the Issue) Definition of your work item types (use witadmin exportwitd) If you built the assemblies yourselves, they take a fixed 2.</description></item><item><title>Security</title><link>https://tfsaggregator.github.io/docs/v2/admin/security/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tfsaggregator.github.io/docs/v2/admin/security/</guid><description>We strove to limit the API exposed to Rules and the chance of unwanted access.
It is up to the TFS Administrator validate and deploy the policy file on production TFS.
Test the policy file on a TFS staging environment with a single Application Tier server. If you have more than one enabled, TFS can be turned temporarily off on a server using TFSServiceControl quiesce command.
Use the Rate Limit feature to reduce the chance of infinite loops.</description></item><item><title>Basic examples</title><link>https://tfsaggregator.github.io/docs/v3/rules/rule-examples-basic/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tfsaggregator.github.io/docs/v3/rules/rule-examples-basic/</guid><description>Basic Rule examples # To start with simple rules you can see here some examples, for more usage please see Advanced Examples
Hello World # A trivial rule that returns some core fields of the work item which triggered the rule.
$&#34;Hello { self.WorkItemType } #{ self.Id } - { self.Title }!&#34; Auto-close parent # This is more similar to classic TFS Aggregator. It moves a parent work item to Closed state, if all children are closed.</description></item><item><title>Advanced examples</title><link>https://tfsaggregator.github.io/docs/v3/rules/rule-examples-advanced/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tfsaggregator.github.io/docs/v3/rules/rule-examples-advanced/</guid><description>Advanced Rule examples # Backlog work items: Auto-activate parent # This is a more advanced version which has no hard coded work item type names. It moves a parent work item to active state (activates parent), if a child gets activated and both parent and child are backlog work items
//Method to check if a &#39;workItem&#39; is in a &#39;Progress&#39; state bool IsInProgress(WorkItemWrapper workItem, BacklogWorkItemTypeStates workItemType) { var concreteStateNames = workItemType?</description></item><item><title>Caveats</title><link>https://tfsaggregator.github.io/docs/v3/design/caveat/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tfsaggregator.github.io/docs/v3/design/caveat/</guid><description>Azure DevOps behavior # Azure DevOps may do a few revisions when creating a new Work Item, backlog ordering service and few other things may cause the aggregator to receive the first notification as an edit and not a create event (see events). Or you may get the create event and the save may fail, because the backlog ordering (sparsification) has triggered. In which case you&rsquo;ll also get ae edit event right after, so you can ignore the failure.</description></item><item><title>Introduction to Contributors</title><link>https://tfsaggregator.github.io/docs/v2/contrib/developer-intro/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tfsaggregator.github.io/docs/v2/contrib/developer-intro/</guid><description>So, you want to build yourself the binaries or want to fix a bug.
To enhance or fix bugs, please read Source code page to introduce yourself to the code. In Local build, we describe the build process: a mandatory read. Useful tips are contained in Debugging and Troubleshooting pages.
TFS Breaking changes # TFS Server API changed frequently in the past: TFS Aggregator contains specific checks for the TFS version.</description></item><item><title>Source Code</title><link>https://tfsaggregator.github.io/docs/v2/contrib/source-code/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tfsaggregator.github.io/docs/v2/contrib/source-code/</guid><description>This page explains the design and internal organization of TFS Aggregator v2&rsquo;s code. If you want to rebuild, customize, submit changes this is the place to start.
Major Components # The Aggregator.Core assembly contains the logic to process a Work Item and run the aggregate scripts. It is normally used by Aggregator.ServerPlugin which intercept the TFS server side events and forward them to Aggregator.Core. Aggregator.ConsoleApp is a simple console app that helps users in developing and testing policies without installing the server plugin.</description></item><item><title>Local Build</title><link>https://tfsaggregator.github.io/docs/v2/contrib/local-build/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tfsaggregator.github.io/docs/v2/contrib/local-build/</guid><description>Building the Solution # To rebuild, edit or debug the code you must use Visual Studio 2017, Community or Professional Edition at a minimum. In addition you must install the following extensions from Visual Studio Gallery:
xUnit.net 1.0 WiX 3.10 (optional) TFS is not required to build nor debugging if you copy locally the required DLLs (for this latter you can use Remote Debugging). WiX is not required if you use the build-installer.</description></item><item><title>Debugging</title><link>https://tfsaggregator.github.io/docs/v2/contrib/debugging/debugging/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tfsaggregator.github.io/docs/v2/contrib/debugging/debugging/</guid><description>For the best development experience, use a TFS Virtual Machine with Visual Studio 2017 installed and work directly on the machine.
Do not ever debug on a production server!
Server Plugin # You can then set the output folder for the project to C:\Program Files\Microsoft Team Foundation Server 12.0\Application Tier\Web Services\bin\Plugins\ or use the deploy.cmd file in Aggregator.ServerPlugin project to refresh Aggregator&rsquo;s assembly on a target test system.</description></item><item><title>Continuous Integration</title><link>https://tfsaggregator.github.io/docs/v2/contrib/continuous-integration/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tfsaggregator.github.io/docs/v2/contrib/continuous-integration/</guid><description>We moved to VSTS for Continuous Integration.
CI Builds for:
develop feature/* do not produce artifacts, i.e. the MSI file. Builds that actually generate artifacts:
master release/* hotfix/* The Reference folder is filled with files from $/TfsAggregator2/References as the assemblies are not redistributable. As explained in Local build these assemblies are tied to the target TFS version.
The script build Debug and Release configuration of TFS-Aggregator-2.sln and run tests.</description></item><item><title>Documentation</title><link>https://tfsaggregator.github.io/docs/v2/contrib/documentation/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tfsaggregator.github.io/docs/v2/contrib/documentation/</guid><description>The source for documentation is tfsaggregator-docs-hugo. Note that you need to pull down also the theme submodule.
The master branch content must match the latest release. To prepare documentation for a future release, use a branch as in the code repository.
Get Hugo Hugo v0.18.1.
Run hugo server to test the changes locally.
Read the full details in this blog post.</description></item><item><title>Pipelines</title><link>https://tfsaggregator.github.io/docs/v3/contrib/pipelines/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tfsaggregator.github.io/docs/v3/contrib/pipelines/</guid><description>Build and deploy # The build-and-deploy.yml pipeline is encompassing all steps required to publish all Aggregator components. This build is triggered by any push of commits or tags as long as they touch the /src/ directory or a workflow.
Some steps and jobs runs only for a tag starting with v, others when the build is run on the default master branch: you see a label v or m or both aside each conditional phase.</description></item><item><title/><link>https://tfsaggregator.github.io/docs/v2/changelog/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tfsaggregator.github.io/docs/v2/changelog/</guid><description>History of Changes # See the releases on GitHub.</description></item><item><title>Parallelism</title><link>https://tfsaggregator.github.io/docs/v3/design/parallelism/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://tfsaggregator.github.io/docs/v3/design/parallelism/</guid><description>Normal flow # The diagram shows the normal Azure DevOps and Aggregator interaction.
mermaid.initialize({ flowchart: { useMaxWidth:true } }); sequenceDiagram User -+ AzDO : New Work Item AzDO --- User : Work Item(id=42, ver=1) activate Aggregator AzDO -+ Aggregator : event(workitem.created, id=42) Aggregator -+ AzDO : readWorkItem(id=42) AzDO --- Aggregator : ver=1 Aggregator - DataModel : new(WorkItem, id=42, ver=1) Aggregator -+ ruleA : triggers ruleA - DataModel : get(WorkItem, id=42) ruleA - DataModel : update(WorkItem, id=42) ruleA --- Aggregator : returns Aggregator - AzDO : updateWorkItem(id=42, ver=1) AzDO -- Aggregator : ver=2 deactivate Aggregator opt Cycle until exahustion activate Aggregator AzDO -+ Aggregator : event(workitem.</description></item></channel></rss>