Обзор миграции
Переход с Azure DevOps Server на Azure DevOps Services является важным шагом для организаций, которые хотят воспользоваться преимуществами облачной совместной работы, масштабируемости и расширенных функций. В этом обзоре мы рассмотрим варианты передачи ценных данных из локального сервера Azure DevOps Server в облачные службы Azure DevOps Services.
Сведения о основных различиях между локальным сервером Azure DevOps Server и облачными службами Azure DevOps Services см. в статье "Сравнение Azure DevOps Services с Azure DevOps Server — Azure DevOps.
Независимо от выбранного варианта миграции рекомендуется определить наиболее важные ресурсы, такие как исходный код и рабочие элементы. Вы должны думать о размере данных, сложности организации и убедиться, что у вас достаточно времени для тестирования перед фактической миграцией для плавного и успешного перехода.
Подходы к миграции
Важно оценить преимущества и недостатки каждого подхода к миграции на основе конкретных мотивов внедрения Azure DevOps Services. Правильная стратегия зависит от уникального контекста и требований.
| Параметры | Рекомендуемые сценарии | Ограничения |
|---|---|---|
| 1. Миграция вручную | Используется для небольших проектов или определенных подмножеств данных. | Не все данные могут быть перенесены с полной точностью и подвержены регулированию. Эта миграция не поддерживает перенос XML-шаблонов, поэтому необходимо повторно создать шаблоны процессов в качестве унаследованных шаблонов. |
| 2. Средство миграции данных Azure DevOps | Используется для средних и крупномасштабных миграций с различными типами данных и сложными структурами. | Вы можете только "поднять и переместить" одну коллекцию Azure DevOps Server в одну новую организацию Azure DevOps Services без изменений. Дополнительные сведения см. в разделе "Ограничения". |
| 3. Миграция на основе API | Обеспечивает гибкость и настройку для организаций с уникальными требованиями к миграции или потребностями автоматизации. | Может произойти низкая точность, потеря данных и изменения идентификатора. Дополнительные сведения см. в разделе "Ограничения". |
Вариант 1. Миграция вручную
Например, когда команда Azure DevOps в Майкрософт решила перейти с Azure DevOps Server на Azure DevOps Services, мы также решили перейти с система управления версиями Team Foundation (TFVC) на Git. Миграция требует большого количества планирования, но при переносе мы создали новый репозиторий Git с помощью версии "tip" наших источников TFVC и оставили историю в Azure DevOps Server. Мы также переехали наши активные рабочие элементы и оставили позади все наши старые ошибки, завершенные истории пользователей и задачи, и т. д.
Процесс миграции вручную
- Определите наиболее важные ресурсы, которые необходимо перенести, как правило, исходный код, рабочие элементы или оба. Другие ресурсы в Azure DevOps Server — конвейеры сборки, планы тестирования и т. д. — сложнее перенести вручную.
- Определите подходящее время для перехода.
- Подготовьте целевые организации. Создайте необходимые организации и командные проекты, подготовьте пользователей и т. д.
- Перенесите данные.
- Рассмотрите возможность создания исходных развертываний Azure DevOps Server только для чтения. Это можно сделать следующим образом:
- Настройте разрешения на уровне проекта: задайте разрешения для всех пользователей или групп только для чтения на уровне проекта, которые можно сделать, изменив роли безопасности в параметрах проекта.
- Изменение параметров репозитория. Для каждого репозитория можно изменить параметры, чтобы сделать их доступными только для чтения, что включает настройку разрешений для каждого пользователя или группы, чтобы разрешить только действия чтения.
- Используйте встроенные группы безопасности: используйте встроенные группы безопасности для более эффективного управления разрешениями. Вы можете назначить пользователей таким группам, как "Читатели", чтобы предоставить доступ только для чтения.
- Изменения разрешений на скрипты: если у вас много проектов или репозиториев, их может потребоваться выполнить. Расширение Azure CLI DevOps можно использовать для перечисления всех разрешений и их обновления по мере необходимости.
- Отключить функцию репозитория: отключает доступ к репозиторию, включая сборки и запросы на вытягивание, но позволяет обнаружить репозиторий с предупреждением. Перейдите в раздел "Параметры>проекта" репозитория> и рядом с параметром "Отключить репозиторий", переместите переключатель в "Вкл.".
Вариант 2. Средство миграции данных Azure DevOps
Средство миграции данных Azure DevOps — это набор служебных программ, предоставляемых корпорацией Майкрософт для упрощения миграции данных из Azure DevOps Server в Azure DevOps Services. Эти средства обеспечивают упрощенный подход к переносу различных артефактов, включая исходный код, рабочие элементы, тестовые варианты и другие данные, связанные с проектом.
Перед началом процесса миграции средства могут выполнить анализ предварительной подготовки для оценки готовности исходной среды и выявления потенциальных проблем или зависимостей, которые могут повлиять на миграцию. Оцените готовность, чтобы заранее спланировать и устранить потенциальные проблемы.
Ограничения средства миграции
Это средство позволяет "поднять и переместить" одну коллекцию серверов Azure DevOps в одну новую организацию Службы Azure DevOps, без изменений по следующим причинам:
- Целостность и согласованность данных:
- При переносе данных важно поддерживать целостность и согласованность. Разрешение изменений во время миграции может привести к повреждению данных или несоответствиям.
- Это средство гарантирует, что данные остаются нетронутыми во время процесса передачи, минимизируя риск ошибок.
- Сохранение исходных данных:
- Средство миграции стремится точно реплицировать исходные данные в целевой среде.
- Изменения могут изменить исходные данные, что может привести к расхождениям между перенесенными данными и исходными данными.
- Предсказуемое поведение:
- Ограничивая изменения, средство обеспечивает предсказуемое поведение во время миграции.
- Пользователи могут полагаться на согласованные результаты без непредвиденных изменений.
- Фокус миграции, а не преобразование:
- Основной целью средства миграции является перемещение данных из одного расположения в другое.
- Преобразование данных (например, изменение значений) обычно обрабатывается отдельно после миграции.
Вы можете очистить данные, которые вам не нужны до или после миграции.
Процесс средства миграции
- Выполните необходимые условия, например обновление Azure DevOps Server до одного из двух последних выпусков.
- Проверьте каждую коллекцию, которую вы хотите переместить в Azure DevOps Services.
- Создайте файлы миграции.
- Подготовьте все для выполнения миграции.
- Выполнение тестового запуска.
- Выполните миграцию.
- Убедитесь, что пользователи и данные перенесены, и коллекция работает должным образом.
Вариант 3. Миграция на основе API
Если по какой-то причине вы не можете использовать средство миграции данных, но по-прежнему требуется более высокая точность миграции, чем вариант 2, можно выбрать различные инструменты, использующие общедоступные API для перемещения данных.
Ограничения миграции на основе API
Следующие ограничения возникают при миграции на основе API:
- Миграция с низкой точностью:
- Ограничение. Средства на основе API обеспечивают более высокую точность, чем ручное копирование, но по-прежнему относительно низкой точности.
- Последствия. Хотя эти средства обеспечивают некоторую достоверность, они не сохраняют все аспекты данных.
- Пример. Ни один из них не сохраняет исходные даты наборов изменений TFVC (система управления версиями Team Foundation).
- Многие не сохраняют измененные даты редакций рабочих элементов.
- Изменения потери данных и идентификатора:
- Ограничение. Во время миграции средства выполняют изменения рабочих элементов, наборы изменений TFVC, веб-каналы пакетов и артефакты конвейера.
- Последствия. Этот процесс может привести к потере данных, созданию новых идентификаторов и изменению дат создания, изменения и закрытия.
- Пример. Исторический контекст, связанный с определенными датами, может потеряться, влияя на отчеты и возможность трассировки.
Процесс миграции на основе API
Как правило, мы рекомендуем использовать этот подход, только если дополнительная точность за пределами ручной копии имеет решающее значение. Если вы решите принять этот подход, вы можете рассмотреть вопрос о найме консультанта, который имеет опыт работы с одним или несколькими инструментами и выполнить тестовую миграцию до окончательной миграции.
Многие организации нуждаются в очень высокой точности миграции только для подмножества своей работы. Новая работа может начаться непосредственно в Azure DevOps Services. Другие действия, с менее строгими требованиями к точности, могут быть перенесены с помощью одного из других подходов.
Поддерживаемые модели процессов
Azure DevOps Services поддерживает следующие модели процессов:
По умолчанию размещенный XML отключен в Azure DevOps Services. Мы включите модель процесса размещенного XML во время миграции, только если вы настроили проект в Azure DevOps Server. После того как проект находится в размещенном XML, его можно обновить до унаследованного после миграции.
Ключевые принципы
При миграции в Azure DevOps Services помните о следующих ключевых принципах и ограничениях:
- Azure DevOps Services является только английским: Azure DevOps Server поддерживает несколько языков, однако сегодня Azure DevOps Services поддерживает только английский. Если в вашей коллекции используется язык, отличный от английского или используемый в прошлом, и вы преобразовали язык на английский во время обновления, вы не можете использовать средство миграции данных.
- Наследование: проект, созданный на основе шаблона процесса Agile, Scrum или CMMI и никогда не был настроен, находится в модели процесса наследования после миграции.
- Размещенный XML: любой проект с настройками использует модель процесса размещенного XML.
- Процесс для каждого настраиваемого проекта. Хотя Azure DevOps Services позволяет проектам совместно использовать процесс, средство миграции данных создает размещенный XML-процесс для каждого настраиваемого командного проекта. Например, если у вас есть 30 настраиваемых проектов, у вас есть 30 размещенных XML-процессов для управления. Если вы хотите дополнительно настроить размещенный XML-процесс для всех проектов, необходимо отдельно обновить каждый размещенный XML-процесс.
- Проверка процесса. Проверка процесса средства миграции данных обнаруживает целевую модель процесса для каждого проекта. Прежде чем выполнить миграцию, необходимо исправить все ошибки проверки процесса для размещенных XML-проектов. Вам может потребоваться обновить процесс проектов, чтобы он соответствовал одному из наших процессов (Agile, Scrum или CMMI), чтобы воспользоваться преимуществами модели процесса наследования. Дополнительные сведения о типах проверки процесса в нашей документации.