If you are like me for historic reasons you have multiple Azure DevOps organisations (instances) backed by the same Azure Active Directory (AAD). In my case for example: one was created when Azure DevOps was first released as TFSPreview.com and another is from our migration from on-prem TFS using the DB Migration Tools method; and I have others.
I make active use of all of these for different purposes, though one is primary with the majority of work done on it, and so I want to make sure the inherited process templates are the same on each of them. Using the primary organisation as the master customisation.
Note I have already converted all my old on-premises XML process models to inherited process templates.
There is no out the box way to do keep processes in syncs, but it is possible using a few tools. The main one is the Microsoft Process Migrator for Node on GitHub.
Firstly I cloned the Microsoft Process Migrator and built it as per the instructions on the repo.
I created a config file and then ran the tool. On one organisation it ran fine. However on another I had errors like:
[ERROR] [2018-11-26T14:35:44.880Z] Process import validation failed. Process with same name already exists on target account.
[ERROR] [2018-11-26T14:39:54.206Z] Import failed, see log file for details. Create field ‘Location’ failed, see log for details
This was because I had in the past manually duplicated the inherited process template onto this organisation, so there was a process with the same name and fields of the same names.
The first error was easy to fix, import the template with a new (temporary) name.
The second is more problematic. I had two choice
As I only had a few duplicated unused fields on a single organisation I picked the former. If I had many organisations to sort out I would picked the latter.
So my process ended up being
- Run the Microsoft Process Migrator to migrate ‘My Process’ on the source organisation to ‘My Process 1’ on the target organisation
- It gave an error, providing the name of the duplicated field
- I checked on the target organisation using a work item query that the field was empty or only had defaulted data (if it had not been I would have used Martin’s tool to migrate the data to a temporary field and then deleted the problem field, moving the data back to the correct field from the temporary field when the import of the process template was completed)
- I deleted the field from the work item type that referenced it
- I deleted the field
- I deleted the process template ‘My Process 1’, a failed import leaves a half created process
- I went back to step 1 and repeated until the import completed without error
- I tested my migrated inherited process was OK
- On the target organisation I then renamed ‘My Process’ to ‘My Process – Old’
- I then renamed ‘My Process 1’ to ‘My Process’
- In my case I also made ‘My Process’ as the default, you might not do this if another process is the default, but step 13 does require the process template is not the default
- I moved all the team projects using the process template now called ‘My Process – Old’ to ‘My Process’
- I was then able to delete the process template ‘My Process – Old’ as it has no associated team projects and was not the default
As I customise my primary organisation’s process templates I can repeat this process to keep the processes in sync between organisations. Note that in future migrations I won’t have to do steps 2..6 as there are no manually created duplicated fields. So it should be more straight forward.
So a valid solution until any similar functionality is built into Azure DevOps, and there is no sign of that on the roadmap.