Reference Overview
This documentation is for a preview version of the Azure DevOps Migration Tools. If you are not using the preview version then please head over to the main documentation.
Overview > Reference
The system works by setting one or more Processors in the json
configuration file. This processor can have many ProcessorEnrichers that
enable aditional features, and must have at least two Endpoints;
a Source Endpoint
and a Target Endpoint
. Each Endpoint
may have additional EndpointEnrichers that add
additional Client specific functionality.
What types of things do we have
- Processors - Processors allow you to move diferent types of data between
Endpoints
and does not care whatEndpoint
you have on each end. - Processor Enrichers - Enrichers at the processor level allow you to add additional functionality to a processor without endangering the core functionality. Each Enricher should have a single responsabiity and can add funtionality to the following stages of the processor pipeline.
- Endpoints connect to the target system and load and save the data. Endpoint can load or save data from any system, but we are focusing on Azure DevOps & Github.
- Endpoint Enrichers - Because systems likely have different data shapes we also have EndpointEnrichers that can be added to
Endpoints
that allow loading and saving of specific data. - Mapping Tools -
We currently have a WorkItemTrackingProcessor
with Endpoints for InMemory (for testing), FileSystem, and Tfs. You can mix-and-match Endpoints so that you would be able to migrate your WorkItem
data from Tfs to FileSystem as needed.
The model should also work for other data Teams
, SharedQueries
, PlansAndSuits
.
How the Configuration file flows
{
"Version": "0.0",
"LogLevel": "Verbose",
"MappingTools": [
{
"$type": "MappingToolA",
"Enabled": true
},
{
"$type": "MappingToolA",
"Enabled": true
}
],
"Processors": [
{
"$type": "ProcessorA",
"Enabled": true,
"Enrichers": [
{
"$type": "EnricherA",
"Enabled": true
},
{
"$type": "EnricherB",
"Enabled": true
}
],
"Endpoints": [
{
"$type": "EndPointA",
"Direction": "Source",
"Enrichers": [
{
"$type": "EnricherA",
"Enabled": true,
},
{
"$type": "EnricherB",
"Enabled": true,
}
]
},
{
"$type": "EndPointB",
"Direction": "Target",
"Enrichers": [
{
"$type": "EnricherA",
"Enabled": true,
"AttachmentWorkingPath": "c:\\temp\\WorkItemAttachmentWorkingFolder\\",
"AttachmentMaxSize": 480000000
}
]
}
]
}
]
}
What was added here
- Moved to WorkItemData2 & RevisedItem2 as we needed more changes than the v1 architecture could support
- Enabled the configuration through Options and the loading of the objects for
Processors
,ProcessorEnrichers
,Endpoints
,EndpointEnrichers
. - Moved all services setup to the project that holds it using extension methods. e.g. ` services.AddMigrationToolServices();`
- Created new IntegrationTests with logging that can be used to validate autonomously the Processors. Started with
TestTfsToTfsNoEnrichers
to get a migration of just ID, & ReflectedWorkItemId. Still needs actual code inTfsWorkItemEndpoint
to connect to TFS but it runs, passes, and attaches the log to the test results.
While we still have a long way to go this is a strong move towards v2. It will add object confusion while we build within the context of the existing tool. However, I have marked many of the objects as [Obsolite("This is v1 *", false)
so that we can distinguish in the confusing areas.
Legacy Folders
VstsSyncMigrator.Core
- Everything in here must go :)MigrationTools\_EngineV1\*
- These will me refactored away and into v2.MigrationTools.Clients.AzureDevops.ObjectModel\_EngineV1\*
- Clients model is being abandoned in favour ofEndpoints