Обзор миграции
Переход с 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. Мы также перенесли наши активные рабочие задачи и оставили все наши старые ошибки, завершенные пользовательские истории и задачи.
Процесс миграции вручную
- Определите наиболее важные ресурсы, которые необходимо перенести, как правило, исходный код, рабочие элементы или оба. Другие ресурсы в 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 Services в другую организацию Azure DevOps Services в настоящее время не поддерживается.
- Миграция с одного экземпляра Azure DevOps Server на другой не поддерживается.
Вы можете очистить данные, которые вам не нужны до или после миграции.
Процесс инструмента миграции
- Выполните необходимые условия, например обновление Azure DevOps Server до одного из двух последних выпусков.
- Проверьте каждую коллекцию, которую вы хотите переместить в Azure DevOps Services.
- Создайте файлы миграции.
- Подготовьте все для выполнения миграции.
- Выполнение тестового запуска.
- Выполните миграцию.
- Убедитесь, что пользователи и данные перенесены, и коллекция работает должным образом.
Вариант 3. Миграция на основе API
Если вы не можете использовать средство миграции данных, но по-прежнему требуется более высокая точность миграции, чем вариант 2, рассмотрите возможность использования различных средств, использующих общедоступные API для перемещения данных. Эти средства включают расширения, доступные в Visual Studio Marketplace.
Ограничения миграции на основе API
Следующие ограничения возникают при миграции на основе API:
- Миграция с низкой точностью:
- Ограничение: Средства на основе API обеспечивают более высокую точность, чем ручное копирование, но всё равно остаются относительно неточными.
- Последствия. Хотя эти средства обеспечивают некоторую достоверность, они не сохраняют все аспекты данных.
- Пример. Ни один из них не сохраняет исходные даты наборов изменений TFVC (система управления версиями Team Foundation).
- Многие не сохраняют измененные даты ревизий рабочих элементов.
- Потеря данных и изменения идентификатора
- Ограничение: Во время миграции средства выполняют изменения рабочих элементов, наборы изменений TFVC, каналы пакетов и артефакты конвейера.
- Последствия. Этот процесс может привести к потере данных, созданию новых идентификаторов и изменению дат создания, изменения и закрытия.
- Пример. Исторический контекст, связанный с определенными датами, может потеряться, влияя на отчеты и возможность трассировки.
Процесс миграции на основе API
Как правило, мы рекомендуем использовать этот подход, только если дополнительная точность за пределами ручной копии имеет решающее значение. Если вы решите принять этот подход, вы можете рассмотреть вопрос о найме консультанта, который имеет опыт работы с одним или несколькими инструментами и выполнить тестовую миграцию до окончательной миграции.
Многие организации нуждаются в высокоточной миграции только для части их задач. Новая работа может начаться непосредственно в Azure DevOps Services. Другие действия, с менее строгими требованиями к точности, могут быть перенесены с помощью одного из других подходов.
Поддерживаемые модели процессов
Azure DevOps Services поддерживает следующие модели процессов:
По умолчанию в Azure DevOps Services Управляемый XML отключен. Мы включаем модель процесса Hosted XML во время миграции, только если вы настроили проект в Azure DevOps Server. Когда ваш проект размещен в Hosted 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), чтобы воспользоваться преимуществами модели процесса наследования. Дополнительные сведения о типах проверки процесса в нашей документации.