Примечание: первоначально я опубликовал эту статью на Medium 6/6/2019
В Blue Chip Consulting Group , нас часто приводят, чтобы помочь компаниям с слияниями и поглощениями. Иногда это означает перемещение Azure DevOps Проекты от одной организации в другую.
Есть несколько надежных инструментов, которые помогут с этим типом работы. Инструменты миграции Azure DevOps Проект — это приличный вариант с открытым исходным кодом, который очень хорошо обрабатывает несколько ключевых аспектов миграции. К сожалению, это не хорошо задокументировано и Требуется глубокое понимание как настроить каждую задачу. Opshub имеет хорошее коммерческое предложение который мы использовали с большим успехом, но он фокусируется в основном на миграции рабочих элементов и ожидает, что основные предметы, такие как области, итерации и учетные записи пользователей, будут настроены заранее.
Недавнее взаимодействие имело проект с десятками пользовательских общих запросов, которые необходимо было перенести. Я попытался использовать инструмент миграции DevOps для достижения этого, но после нескольких попыток был безуспешным Итак, я пошел в Azure DevOps Rest Documentation Чтобы увидеть, что нужно, чтобы что -то написать сам. Оказывается, что запрос и создание полезных нагрузок выглядели очень похожими, поэтому я решил свернуть свое собственное решение.
Я обычно работаю в C#, но решил пойти с PowerShell из -за Динамическая обработка полезных нагрузок JSON что он предлагает. Это было очевидно из документации и некоторых образцов запросов, которые я протестировал в Почтальон что рекурсивное перечисление Получите результат Было бы легко вписаться в экземпляр Target DevOps, чтобы Создайте запросы в целевой организации.
Сценарий требует нескольких предметов, чтобы быть на месте, прежде чем запустить его
- Название проекта : Сценарий предполагает, что вы перемещаете запросы в проект с тем же названием в организации DevOps. Если вы нацелены на другой экземпляр, это должно быть легким настройкой сценария PowerShell, чтобы представить другое имя целевого проекта
- Источники и целевые имена организаций : Это пользовательские сегменты URL, которые идентифицируют организацию и следуют Dev.visualStudio.com в базовом URL. Этот скрипт будет работать, даже если вы используете старый формат URL -адреса .visualstudio.com.
- Личные токены доступа для каждой организации : Организация источника требует чтения рабочих элементов и целевой организации, необходимой для чтения/записи рабочего элемента. Вот статья, которая показывает, как создать PAT в экземпляре DevOps Анкет
Вы захотите настроить области и итерации В целевой организации перед выполнением этого сценария, если ваши запросы зависят от них. Инструменты миграции DevOps хорошо справляются с этим, если вы включите процессор NodestructuresMigrationConfig. Это так же просто, как использовать эти настройки для configuration.json :
"Processors": [
{
"ObjectType": "VstsSyncMigrator.Engine.Configuration.Processing.NodeStructuresMigrationConfig",
"PrefixProjectToNodes": false,
"Enabled": true
},
…
]
И это все. Сценарий может быть выполнен несколько раз. Он пропустит запросы с тем же названием и местоположением иерархии папок в организации назначения.
Сценарий можно найти в этот репозиторий GitHub Анкет
Оригинал: «https://dev.to/jkewley/migrate-azure-devops-work-item-queries-to-a-new-organization-2ogb»