This document discusses syncing work items between multiple Azure DevOps team projects. It describes a scenario where work items from a master project are synced to a derived project using web hooks and REST APIs. The solution works but has limitations including a lack of documentation, missing functionality for some work item operations, and basic error handling. Real-time or scheduled sync approaches are suggested for a "full" two-way sync between projects.

1. saturday 2018
SYNC WORK ITEMS BETWEEN
MULTIPLE TEAM PROJECTS:
THE GOOD, THE BAD, THE UGLY...
Lorenzo Barbieri
@_geniodelmale
lorenzo.barbieri@microsoft.com
#vssatpn

2. WORK ITEMS SYNC
It’s not in the product…
• Too many edge cases, but you’ve «most of» the building blocks.
There are different kind of Work Items…
• Test related ones are «strange beasts».
• You can use them as «Work Items» but to work with Test items you need VS
Enterprise or Test Management license.
Sometimes we need to make assumptions…
• APIs are not «well documented».
2

3. OUR SCENARIO
3
Master
Team
Project
Source of Work
Items
Receives Test Runs
and Test Results
Derived
Team
Project
Receives Work
Items (filtered?)
Executes Test Runs
that are exported
(with Test Results)
One-way Workitem Sync (mostly test related)
Azure
Pipelines

4. OUR SCENARIO
4
Master
Team
Project
Source of Work
Items
Receives Test Runs
and Test Results
Derived
Team
Project
Receives Work
Items (filtered?)
Executes Test Runs
that are exported
(with Test Results)
Web Hooks:
- CreateWI
- UpdateWI
- DeleteWI
REST APIWeb Hooks JSON
REST API
Azure
Pipelines
PAT
Personal Access Token

5. OUR SCENARIO
5
Master
Team
Project
Source of Work
Items
Receives Test Runs
and Test Results
Derived
Team
Project
Receives Work
Items (filtered?)
Executes Test Runs
that are exported
(with Test Results)
Web Hooks:
- CreateWI
- UpdateWI
- DeleteWI
Http API:
- MigrateTestRun
REST APIWeb Hooks JSON
REST API
Azure
PipelinesHTTP CALL
PAT
Personal Access Token
Master and Derived Team Projects could be on different Azure DevOps Hosts

6. WHAT IS NOT PART OF THIS
SOLUTION
Code sync
• Could be «easily» done with GIT, could be harder with TFVC
Users, groups, iterations, areas, boards, artifacts, etc…
• This solution «works» but everything else should be set-up manually
• Links to code, wiki, etc… are not handled, they can work on the same host, on
multiple hosts some work is required.
Process templates MUST be equal.
• No on-the-fly transformation of different templates.
6

7. WE USE A CUSTOM TAG TO TRACK
THE ORIGINAL WORK ITEM ID
PRO:
 No need to create a custom process
CON:
 Could be «modified» by the users if not blocked
in some ways
 Difficult to read in the Work Items list
7

8. DEMO
AND BEWARE…
THIS CODE IS A PROOF OF
CONCEPT…
IT’S VERY FAR FROM BEING
PERFECT!
8

9. SERVICE HOOKS SUBSCRIPTION –
WEB HOOKS
9
It uses a «standard»
message. My code
doesn’t handle it and
returns a HTTP 500

10. SERVICE HOOKS
You’ve to «monitor» this tab. If the functions fail for too many calls the corresponding Service
Hook will be suspended, and should be enabled again manually.
10

11. WEB HOOKS – HISTORY AND
«DEBUGGING»
11

12. TEST PLANS, SUITES AND CASES
(AND TEST POINTS)
Derived Team Project
(where test are executed)
Master Team Project
(not updated yet)
12

13. INVOKE AZURE FUNCTION DURING
A RELEASE
https://docs. microsoft.com/en-
us/azure/devops/pipelines/tasks/uti
lity/azure-function?view=vsts
If you have a «normal»
HTTP REST API:
https://docs.microsoft.com/en-
us/azure/devops/pipelines/tasks/uti
lity/http-rest-api?view=vsts
13

14. HOW TO MONITOR FUNCTION
EXECUTION
14

15. FINAL RESULT
15

16. SOME NOTES REGARDING TEST
RUN MIGRATIONS
To update the corresponding Test Case, a Test Point should be
associated to the destination Test Run and Test Case.
• When creating the Test Point, a Test Result is automatically created for us, so we don’t
need to create a new one but update the existing one.
Automatic Tests need a Build also on the «source» Team Project.
• At the moment we’re changing it to a Manual Test.
• The evolution could be having a «fake» Build inside the Master Team Project and pass
the Build Definition ID to the Azure Function that could queue the «empty» build, wait
for it and associate the Test Run/Results to it.
16

17. REALTIME WORKITEM SYNC…
17
It
Could
Work!

18. THE GOOD
It works
It solved partner and customer problem
We discovered a lot of things, and learned a lot of the «internals» of Work Items and
especially Test items and APIs
Azure Functions offer 1M free executions per month, with 400.000Gb*s total memory
usage… well enough also for «crowded» Team Projects…
Did I already say that «It works!»? 
18

19. THE BAD
APIs are not «wery vell» documented. Perhaps we should step in and propose PRs for
docs.microsoft.com… (if we could find 48hrs days ).
Most of the time we made some trade-offs to simplify the code, especially in the Test sync
code.
• It worked on our scenarios,a full-fledged solution could be much more complex.
• Some cases (i.e., Work Item Restore, Work Item Delete from Recycle Bin) were ignored.
• Certain things are not, yet, aligned: i.e., Test Plans are visible as Work Items in the Derived TP
We’re still on Azure Functions v1, with manual HTTP calls because of issues with Azure
DevOps SDK on Functions (at least when we started the project).
Areas and Iterations should be updated manually, there aren’t Service Hooks on those ones
(we have thought about some workarounds but didn’t implement any).
19

20. THE UGLY
My code! 
Error handling, monitoring, etc… is very basic and very limited.
We need to figure out how to «restart» a working environment after a failure. Now it’s a
manual process.
• It’s not a big problem for this project, considering the low volume of new/updated Work Items.
PAT should be updated manually… every year or so.
• A «service account» user should be used, not an actual user like in this demo.
• We’re using a single PAT for both Team Projects, also if they’re on different hosts.
TestMethod association to Test Case is available only from Visual Studio 2017 15.9 Preview
2 or later:
• https://docs.microsoft.com/en-us/azure/devops/pipelines/test/reference-qa?view=vsts#test-types
20

21. WHAT ABOUT A «FULL» TWO WAY
SYNC
One could
extend this
approach for a
«full» two way
sync
- You need to remove «fixed»
paths inside the code
- Workitem IDs should be
tracked on both sides
•- Beware of «circular loops»
Realtime
Sync
An easier option
could be using a
«traditional
sync» and
scheduling it
- You should handle the
scheduler, on-premise or in
the cloud (timed functions?)
- External tool could be
difficult to set-up
Scheduled
Sync
21

22. CAN I HAVE THE CODE?
IT DEPENDS…
IT’S NOT ON GITHUB, YET…
BUT I’M NOT SURE IF AND
WHEN IT COULD BE READY
FOR PUBLICATION...
22

23. saturday 2018
THANKS!!! Lorenzo Barbieri
@_geniodelmale
lorenzo.barbieri@microsoft.com
#vssatpn