Sync Work Items between Teams
•Download as PPTX, PDF•
0 likes•1,255 views
This document discusses syncing work items between multiple Azure DevOps team projects. It describes a scenario where work items from a master team project are synced one-way to a derived team project. The solution uses web hooks and REST APIs to sync work item creates, updates, and deletes. It also discusses syncing test runs and results between the projects. The document notes both benefits and limitations of this approach, such as the lack of documentation for APIs and issues with syncing additional work item fields and artifacts.
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Sync Work Items between Teams
Similar to Sync Work Items between Teams (20)
More from Lorenzo Barbieri
More from Lorenzo Barbieri (20)
Recently uploaded
Recently uploaded (20)
Sync Work Items between Teams
- 1. Sync Work Items between multiple Team Projects: the good, the bad, the ugly... Lorenzo Barbieri @_geniodelmale lorenzo.barbieri@microsoft.com
- 2. #DOH18 2 Organizers & sponsors GetLatestVersion.it
- 3. #DOH18 3 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».
- 4. #DOH18 4 Our scenario 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
- 5. #DOH18 5 Our scenario 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 PipelinesPAT Personal Access Token
- 6. #DOH18 6 Our scenario 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 CALLPAT Personal Access Token Master and Derived Team Projects could be on different Azure DevOps Hosts
- 7. #DOH18 7 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.
- 8. #DOH18 8 How do we «track» the Original WI? • We’ve added a custom Tag to the Work Items • 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
- 9. 9 DEMO And beware… This code is a Proof of Concept… It’s very far from being perfect!
- 10. #DOH18 10 Service Hooks Subscription – Web Hooks It uses a «standard» message. My code doesn’t handle it and returns a HTTP 500
- 11. #DOH18 11 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.
- 12. #DOH18 12 Web Hooks – History and «debugging»
- 13. #DOH18 13 Test Plans, Suites and Cases (and Test Points) Derived Team Project (where test are executed) Master Team Project (not updated yet)
- 14. #DOH18 14 Invoke Azure Function during a release • https://docs. microsoft.com/en- us/azure/devops/pipelines /tasks/utility/azure- function?view=vsts • If you have a «normal» HTTP REST API: https://docs.microsoft.co m/en- us/azure/devops/pipelines /tasks/utility/http-rest- api?view=vsts
- 15. #DOH18 15 How to monitor function execution
- 17. #DOH18 17 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.
- 18. #DOH18 18 Realtime Workitem Sync… It Could Work!
- 19. #DOH18 19 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!»?
- 20. #DOH18 20 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).
- 21. #DOH18 21 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
- 22. #DOH18 22 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
- 23. 23 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...
- 24. 24 Thank you!!! Please tweet about the session #DOH18 @_geniodelmale Lorenzo Barbieri lorenzo.barbieri@microsoft.com