Выполнение тестовой миграции

Теперь ваша команда готова начать процесс тестовой миграции и затем приступить к полной производственной миграции. На этом этапе мы обсудим окончательные шаги по очереди миграции в дополнение к другим задачам, которые обычно приходят в конце проекта миграции.

Предварительные условия

Завершите этап подготовки тестового запуска перед началом миграции тестового прогона.

Внимание

Чтобы обеспечить плавный процесс миграции, выполните один или несколько тестового импорта. Тестовый импорт длится 45 дней для тестирования и проверки. Через 45 дней тестовый запуск завершается и удаляется, при необходимости вам нужно будет начать заново. Чем больше времени проходит между тестовым и рабочим запуском, тем больше может измениться служба, и могут возникнуть ошибки, которые бы выявил свежий тестовый запуск. Вы можете повторно запустить тестовое выполнение импорта столько раз, сколько необходимо. Каждый импорт начинается с начального состояния импортированной базы данных, так как изменения из одного импорта не могут сохраняться в другую. Обратите внимание на следующие моменты:

• Вы не можете продлить тестовый запуск на неопределенный срок
• Вы не можете повысить уровень тестового запуска до продуктивного запуска
• Тестовый запуск удаляется при возникновении любого из следующих действий:
  • Время выполнения теста истекло
  • Выполняется новый тестовый запуск с тем же именем.
  • Запуск производственного цикла
  • Организация удаляется вручную с помощью параметров организации

Проверка коллекции

Проверьте каждую коллекцию, которую требуется перенести в Azure DevOps Services. Этап валидации исследует различные аспекты вашей коллекции, включая, но не ограничиваясь, размер, сортировку, идентификацию и процессы.

Запустите проверку с помощью средства миграции данных.

1. Скачайте средство миграции данных.

2. Скопируйте ZIP-файл на один из уровней приложений Azure DevOps Server.

3. Распакуйте файл . Вы также можете запустить средство с другого компьютера без установленного сервера Azure DevOps Server, если компьютер может подключиться к базе данных конфигурации экземпляра Сервера Azure DevOps.

4. Откройте окно командной строки на сервере и введите команду cd, чтобы перейти в каталог, в котором хранится средство миграции данных. Выделите несколько минут, чтобы просмотреть справочное содержание инструмента.

   a. Чтобы просмотреть справку и руководство верхнего уровня, выполните следующую команду.

    Migrator /help
   

   б. Просмотрите справочный текст команды.

    Migrator validate /help 
   

5. При первой проверке вашей коллекции команда должна иметь следующую простую структуру.

    Migrator validate /collection:{collection URL} /tenantDomainName:{name} /region:{region}
   

   Где {name} указано имя вашего клиента Microsoft Entra, например, чтобы выполнить запрос к DefaultCollection и к клиенту fabrikam, команда будет выглядеть следующим образом.

    Migrator validate /collection:http://localhost:8080/DefaultCollection /tenantDomainName:fabrikam.OnMicrosoft.com /region:{region}
   

6. Чтобы запустить средство с компьютера, отличного от сервера Azure DevOps Server, требуется параметр /connectionString . Параметр строки подключения указывает на базу данных конфигурации вашего сервера Azure DevOps. Например, если проверенная команда выполняется корпорацией Fabrikam, команда будет выглядеть следующим образом.

    Migrator validate /collection:http://fabrikam:8080/DefaultCollection /tenantDomainName:fabrikam.OnMicrosoft.com /region:{region} /connectionString:"Data Source=fabrikam;Initial Catalog=Configuration;Integrated Security=True"
   

   Внимание

   Средство миграции данных не редактирует данные или структуры в коллекции. Он считывает коллекцию только для выявления проблем.

7. После завершения проверки можно просмотреть файлы журнала и результаты.

   

   Во время валидации вы получите предупреждение, если некоторые из ваших конвейеров содержат индивидуальные правила хранения. Azure DevOps Services использует модель хранения на основе проекта и не поддерживает политики хранения на основе конвейера. Если вы решите продолжить миграцию, политики не будут перенесены в хостируемую версию. Вместо этого применяются политики хранения на уровне проекта по умолчанию. Сохраняйте важные для вас сборки, чтобы они не были утеряны.

После прохождения всех проверок можно перейти к следующему шагу процесса миграции. Если средство миграции данных помечает все ошибки, исправьте их перед продолжением. Рекомендации по исправлению ошибок проверки см. в разделе «Устранение неполадок миграции и ошибок миграции».

Импорт файлов журнала

Когда вы откроете каталог журнала, вы можете заметить несколько файлов ведения журнала.

Основной файл журнала называется DataMigrationTool.log. Он содержит сведения обо всём, что было выполнено. Чтобы упростить вам задачу сосредоточиться на конкретных областях, для каждой основной операции проверки создается журнал.

Например, если TfsMigrator сообщает об ошибке на шаге "Проверка процессов проекта", можно открыть файл ProjectProcessMap.log , чтобы просмотреть все, что было запущено для этого шага, а не прокручивать весь журнал.

Просмотрите файл TryMatchOobProcesses.log только если вы пытаетесь осуществить миграцию процессов вашего проекта для использования унаследованной модели. Если вы не хотите использовать унаследованную модель, эти ошибки можно игнорировать, так как они не препятствуют импорту в Azure DevOps Services. Подробнее см. в этапе проверки миграции.

Создание файлов миграции

Средство миграции данных проверило коллекцию и возвращает результат проверки всех коллекций. Прежде чем перенести коллекцию в автономном режиме, создайте файлы миграции. При выполнении prepare команды создается два файла миграции:

• IdentityMapLog.csv: Описывает сопоставление удостоверений между Active Directory и Microsoft Entra ID.
• migration.json. Требуется заполнить спецификацию миграции, которую вы хотите использовать для запуска миграции.

Подготовка команды

Эта prepare команда помогает создавать необходимые файлы миграции. По сути, эта команда сканирует коллекцию, чтобы найти список всех пользователей, чтобы заполнить журнал карты удостоверений, IdentityMapLog.csv, а затем пытается подключиться к идентификатору Microsoft Entra, чтобы найти совпадение каждого удостоверения. Для этого вашей компании необходимо использовать средство Microsoft Entra Connect (прежнее название — средство синхронизации каталогов, средство синхронизации каталогов или средство DirSync.exe).

Если синхронизация каталогов настроена, средство миграции данных должно обнаружить соответствующие удостоверения и пометить их как активные. Если совпадений нет, идентификатор помечается как Historical в журнале карты идентификаторов, поэтому необходимо выяснить, почему пользователь не включен в синхронизацию вашего каталога. Файл спецификации миграции, migration.json, должен быть заполнен перед миграцией.

В отличие от команды validate, prepareдействительно требуется подключение к Интернету, потому что для заполнения файла журнала карты удостоверений нужно подключение к Microsoft Entra ID. Если у экземпляра Azure DevOps Server нет доступа к Интернету, запустите средство с компьютера, который имеет доступ. Если вы можете найти компьютер с подключением интрасети к экземпляру Azure DevOps Server и интернет-подключению, вы можете выполнить эту команду. Чтобы помочь с командой prepare , выполните следующую команду:

Migrator prepare /help

В справочной документации приведены инструкции и примеры выполнения команды Migrator с самого экземпляра Azure DevOps Server и с удаленного компьютера. Если вы выполняете команду из одного из уровней приложений экземпляра Azure DevOps Server, ваша команда должна иметь следующую структуру:

Migrator prepare /collection:{collection URL} /tenantDomainName:{name} /region:{region}

Migrator prepare  /collection:{collection URL} /tenantDomainName:{name} /region:{region} /connectionString:"Data Source={sqlserver};Initial Catalog=Configuration;Integrated Security=True"

Параметр connectionString — это указатель на базу данных конфигурации экземпляра Azure DevOps Server. Например, если корпорация Fabrikam выполняет prepare команду, команда выглядит следующим образом:

Migrator prepare /collection:http://fabrikam:8080/DefaultCollection /tenantDomainName:fabrikam.OnMicrosoft.com /region:{region} /connectionString:"Data Source=fabrikam;Initial Catalog=Configuration;Integrated Security=True"

Когда средство миграции данных запускает prepare команду, она выполняет полную проверку, чтобы убедиться, что ничего не изменилось с вашей коллекции с момента последней полной проверки. Если обнаружены новые проблемы, файлы миграции не создаются.

Вскоре после запуска команды откроется окно входа Microsoft Entra. Войдите с удостоверением, принадлежащим домену клиента, который указан в команде. Убедитесь, что указанный арендатор Microsoft Entra — это тот, с которым вы хотите, чтобы ваша будущая организация была связана. В нашем примере Fabrikam пользователь вводит учетные данные, аналогичные следующему снимку экрана.

Внимание

Не используйте тестовый клиент Microsoft Entra для тестовой миграции и рабочего клиента Microsoft Entra для рабочего запуска. Использование тестового клиента Microsoft Entra может привести к проблемам с миграцией удостоверений при начале работы с производственным клиентом Microsoft Entra вашей организации.

При успешном prepare выполнении команды в средстве миграции данных в окне результатов отображается набор журналов и два файла миграции. В каталоге журнала найдите папку журналов и два файла:

• migration.json — это файл спецификации миграции. Мы рекомендуем вам уделить время, чтобы заполнить его.
• IdentityMapLog.csv содержит созданное сопоставление Active Directory с идентичностями Microsoft Entra. Просмотрите его для полноты перед началом миграции.

Эти два файла подробно описаны в следующих разделах.

Файл спецификации миграции

Спецификация миграции, migration.json, представляет собой JSON-файл, предоставляющий параметры миграции. Она содержит требуемое имя организации, сведения о учетной записи хранения и другие сведения. Большинство полей автоматически заполнены, а некоторые поля требуют ввода перед попыткой миграции.

Отображаемые поля файла migration.json и необходимые действия описаны в следующей таблице:

Поле	Описание	Необходимые действия
Источник	Сведения о расположении и именах исходных файлов данных, используемых для миграции.	Действия не требуется. Изучите информацию о действиях в подполе, которые следует выполнить.
Расположение	Ключ подписанного URL-адреса для общего доступа к учетной записи хранения Azure, в которой размещен пакет приложения уровня данных (DACPAC).	Действия не требуется. Это поле рассматривается на следующем шаге.
Файлы	Имена файлов, содержащих данные миграции.	Действия не требуется. Изучите информацию о действиях в подполе, которые следует выполнить.
DACPAC	Файл DACPAC, упаковывающий базу данных коллекции для переноса данных при миграции.	Действия не требуется. На следующем шаге вы создадите этот файл с помощью коллекции, а затем отправьте его в учетную запись хранения Azure. Обновите файл в соответствии с именем, которое вы будете использовать при его создании на следующем этапе этого процесса.
Цель	Свойства новой организации, в которую осуществляется миграция.	Действия не требуется. Изучите информацию о действиях в подполе, которые следует выполнить.
Имя.	Имя организации, которую необходимо создать во время миграции.	Введите имя. Имя можно быстро изменить позже после завершения миграции. ПРИМЕЧАНИЕ. Не создавайте организацию с этим именем перед запуском миграции. Организация создается в рамках процесса миграции.
Тип импорта	Тип миграции, которую требуется выполнить.	Действия не требуется. На следующем шаге выберите тип миграции для выполнения.
Данные проверки	Сведения, необходимые для поддержки вашего процесса миграции.	Средство миграции данных создает раздел "ValidationData". Она содержит сведения, помогающие облегчить процесс миграции. Не изменяйте значения в этом разделе, иначе миграция может не начаться.

После завершения предыдущего процесса у вас должен быть файл, который выглядит следующим образом.

На предыдущем изображении планировщик миграции Fabrikam добавил имя организации fabrikam-import и выбрал CUS (Центральные США) в качестве географического расположения для миграции. Другие значения были оставлены без изменений, чтобы их модифицировать непосредственно перед тем, как планировщик переведет коллекцию в автономный режим для миграции.

Примечание.

В тестовом запуске к имени организации автоматически добавляется суффикс "-dryrun", который можно изменить после миграции.

Поддерживаемые регионы Azure для миграции

Azure DevOps Services доступна в нескольких географических расположениях Azure. Но не все регионы, в которых доступны службы Azure DevOps Services, поддерживаются для миграции. В следующей таблице перечислены географические расположения Azure, которые можно выбрать для миграции. Кроме того, это значение, которое необходимо поместить в файл спецификации миграции для назначения этой географической области для миграции.

Географическое расположение	Географическое расположение Azure	Значение спецификации импорта
Соединенные Штаты	Центральная США	CUS
Европа	Западная Европа	WEU
Соединенное Королевство	Соединенное Королевство (юг)	UKS
Австралия	Восточная Австралия	EAU
Южная Америка	Южная Бразилия	SBR
Азиатско-Тихоокеанский регион	Центральная Индия	магистр искусств
Азиатско-Тихоокеанский регион	Юго-Восточная Азия (Сингапур)	Юго-Восточная Азия
Канада	Центральная Канада	CC

Журнал карты удостоверений

Журнал карты удостоверений имеет равное значение фактическим данным, которые вы переносите в Azure DevOps Services. При просмотре файла важно понимать, как работает миграция идентификационных данных и какие потенциальные результаты могут повлечь за собой. При миграции удостоверения оно может стать активным или историческим. Активные учетные записи могут входить в Azure DevOps Services, но исторические учетные записи не могут.

Активные идентичности

Активные идентичности обозначают идентичности пользователей в Azure DevOps Services после миграции. В Azure DevOps Services эти учетные записи имеют лицензию и отображаются в организации как пользователи. Удостоверения помечены как активные в столбце Ожидаемый статус импорта в файле журнала карты удостоверений.

Исторические идентичности

Исторические идентичности сопоставляются следующим образом в столбце "Ожидаемый статус импорта" в файле журнала карты идентичностей. Удостоверения без записи строки в файле также становятся историческими. Пример личности без записи может быть сотрудник, который больше не работает в компании.

В отличие от активных идентичностей, исторические идентичности:

• Отсутствует доступ к организации после миграции.
• У вас нет лицензий.
• Не отображайтесь как пользователи в организации. Все, что сохраняется, — это сведения о названии той идентичности в организации, чтобы ее историю можно было исследовать позже. Рекомендуется использовать исторические удостоверения для пользователей, которые больше не работают в компании или не нуждаются в дальнейшем доступе к организации.

Примечание.

После импорта удостоверения как исторического, оно не может стать активным.

Понимание файла журнала карты идентичности

Файл журнала идентификационной карты аналогичен примеру, представленному здесь:

Столбцы в файле логов карты идентификации описаны в следующей таблице.

Вы и администратор Microsoft Entra должны исследовать пользователей, помеченных как "Нет совпадения" (проверка синхронизации идентификаторов Microsoft Entra ID), чтобы понять, почему они не являются частью синхронизации Microsoft Entra Connect.

Столбец	Описание
Active Directory: пользователь (Azure DevOps Server)	Удобное отображаемое имя, используемое идентификатором в Azure DevOps Server. Это имя упрощает определение того, какой пользователь ссылается на строку в карте.
Active Directory: идентификатор безопасности	Уникальный идентификатор для локальной службы Active Directory в Azure DevOps Server. Этот столбец используется для идентификации пользователей в коллекции.
Идентификатор Microsoft Entra: пользователь, ожидающий импорта (Azure DevOps Services)	Ожидаемый адрес входа пользователя, который скоро станет активным, или совпадение не найдено (проверьте синхронизацию Microsoft Entra ID), что указывает на потерю удостоверения при синхронизации Microsoft Entra ID и его последующий импорт как исторической записи.
Ожидаемое состояние импорта	Ожидаемое состояние миграции пользователей: Активно, если между вашим Active Directory и идентификатором Microsoft Entra ID есть совпадение, или Исторический, если совпадения нет.
Дата проверки	Последняя проверка журнала карты идентификации.

При чтении файла обратите внимание, является ли значение в столбце "Ожидаемый импорт состояния" активным или историческим. Active указывает, что удостоверение в этой строке правильно сопоставляется и при миграции становится активным. Исторические означают, что идентичности приобретают исторический характер при миграции. Важно просмотреть созданный файл сопоставления для полноты и правильности.

Внимание

Миграция не удается, если происходят значительные изменения в синхронизации идентификаторов безопасности Microsoft Entra Connect между попытками миграции. Вы можете добавить новых пользователей между тестовыми запусками и внести исправления, чтобы ранее импортированные учётные записи стали активными. Но вы не можете изменить существующего пользователя, который ранее импортировался как активный. Это приводит к сбою миграции. Пример изменения заключается в завершении тестовой миграции, удалении активно импортированного удостоверения из идентификатора Microsoft Entra ID, повторном создании пользователя в идентификаторе Microsoft Entra и попытке другой миграции. В этом случае предпринимаются активные попытки миграции удостоверений между Active Directory и вновь созданным удостоверением Microsoft Entra, но это приводит к сбою миграции.

1. Проверьте правильно соответствующие идентичности. Присутствуют ли все ожидаемые идентичности? Сопоставляются ли пользователи с правильным удостоверением Microsoft Entra?

   Если необходимо обновить любые значения, обратитесь к администратору Microsoft Entra, чтобы убедиться, что локальное удостоверение Active Directory синхронизировано с идентификатором Microsoft Entra и настроено правильно. Дополнительные сведения см. в разделе "Интеграция локальных удостоверений с идентификатором Microsoft Entra".

2. Затем просмотрите идентичности, помеченные как исторические. Эта метка подразумевает, что не удалось найти соответствующее удостоверение Microsoft Entra, по каким-либо из следующих причин:

   • Учетная запись не настроена для синхронизации между локальной Active Directory и Microsoft Entra ID.
   • Личность еще не создана в вашей системе Microsoft Entra ID (например, новый сотрудник).
   • Идентификатор не существует в вашем экземпляре Microsoft Entra.
   • Пользователь, которому принадлежит это удостоверение, больше не работает в компании.

Чтобы устранить первые три причины, настройте учетную запись в локальной службе Active Directory для синхронизации с Microsoft Entra ID. Дополнительные сведения см. в разделе "Интеграция локальных удостоверений с идентификатором Microsoft Entra". Чтобы удостоверения были импортированы как активные в Azure DevOps Services, необходимо настроить и запустить Microsoft Entra Connect.

Вы можете игнорировать четвертое основание, потому что сотрудники, которые больше не работают в компании, должны быть импортированы как исторические.

Исторические идентичности (маленькие команды)

Примечание.

Только небольшие команды должны рассматривать предложенную в этом разделе стратегию миграции идентификации.

Если Microsoft Entra Connect не настроен, все пользователи в файле журнала идентификационной карты помечаются как устаревшие. При выполнении миграции таким образом все пользователи импортируются как исторические. Настоятельно рекомендуется настроить Microsoft Entra Connect , чтобы убедиться, что пользователи импортируются как активные.

Выполнение миграции со всеми историческими удостоверениями связано с потенциальными последствиями, которые необходимо тщательно рассмотреть. Следует рассматривать только те команды, в которых немного пользователей и для которых стоимость настройки Microsoft Entra Connect считается слишком высокой.

Чтобы перенести все идентификаторы как исторические, выполните действия, описанные в последующих разделах. Когда вы ставите миграцию в очередь, удостоверение, используемое для этого, автоматически становится владельцем организации. Все остальные пользователи импортируются как исторические. Затем владельцы организации могут добавить пользователей обратно с помощью удостоверения Microsoft Entra. Добавленные пользователи рассматриваются как новые пользователи. У них нет своей истории, и невозможно переназначить эту историю для идентификации Microsoft Entra. Тем не менее, пользователи по-прежнему могут искать свою историю до миграции, выполнив поиск по \<domain>\<Active Directory username>.

Средство миграции данных отображает предупреждение, если оно обнаруживает сценарий с историческими идентификаторами полностью. Если вы решите следовать этому миграционному пути, вам нужно согласиться с ограничениями в инструменте.

Подписки на Visual Studio

Средство миграции данных не может обнаружить подписки Visual Studio (ранее известные как преимущества MSDN) при создании файла журнала идентификации. Вместо этого рекомендуется применить функцию автоматического обновления лицензий после миграции. Если рабочие учетные записи пользователей связаны правильно, Azure DevOps Services автоматически применяет преимущества подписки Visual Studio при первом входе после миграции. Вам никогда не начисляются сборы за лицензии, назначенные во время миграции, поэтому вы можете безопасно администрировать подписки после этого.

Вам не нужно повторять тестовую миграцию, если подписки Visual Studio пользователей не обновляются автоматически в Azure DevOps Services. Связывание подписок Visual Studio происходит вне сферы миграции. Если рабочая учетная запись связана правильно до или после миграции, лицензии пользователей автоматически обновляются при следующем входе в систему. После успешного обновления лицензий при следующем запуске миграции пользователи автоматически обновляются при первом входе в организацию.

Подготовка к переносу

Теперь у вас есть все необходимое для выполнения пробного запуска миграции. Запланируйте время простоя в команде, чтобы перенести коллекцию в автономный режим для миграции. Когда вы согласитесь на время выполнения миграции, отправьте необходимые ресурсы, созданные вами, и копию базы данных в Azure. Подготовка к миграции состоит из следующих пяти шагов.

Шаг 1: Переведите коллекцию в автономный режим и отсоедините ее. Шаг 2. Создание ФАЙЛА DACPAC из коллекции, которую вы собираетесь перенести.
Шаг 3. Отправка файлов DACPAC и файлов миграции в учетную запись хранения Azure.
Шаг 4. Создание маркера SAS для доступа к учетной записи хранения.
Шаг 5. Выполните спецификацию миграции.

Примечание.

Перед выполнением рабочей миграции настоятельно рекомендуется выполнить тестовую миграцию. Тестовое выполнение позволяет проверить, работает ли процесс миграции для коллекции и гарантирует отсутствие уникальных фигур данных или проблем, которые могут привести к сбою рабочей миграции.

Шаг 1. Отключение коллекции

Отключение коллекции является важным шагом в процессе миграции. Данные удостоверений для коллекции хранятся в базе данных конфигурации экземпляра Azure DevOps Server, пока коллекция подключена и находится онлайн. Когда коллекция отсоединяется от экземпляра Azure DevOps Server, она создает копию этих данных удостоверения и упаковывает ее вместе с коллекцией для переноса. Без этих данных идентификационная часть миграции не может быть выполнена.

Совет

Держите коллекцию отсоединенной, пока миграция не завершится, чтобы избежать потери изменений, внесенных во время миграции, иначе они не могут быть перенесены после этого. После резервного копирования коллекции для миграции её можно снова подключить. Однако любые изменения, внесенные после резервного копирования, не включаются в миграцию, что может вызвать озабоченность по поводу наличия наиболее актуальных данных. Вы можете использовать автономный отсоединение для тестовых запусков, но этот процесс может не соответствовать рекомендациям по миграции. Ознакомьтесь с документацией по автономному отсоединению, чтобы полностью понять его последствия и как оно соответствует стратегии миграции.

Важно взвесить затраты на то, чтобы обеспечить нулевое время простоя для тестового запуска. Для этого требуется создание резервных копий базы данных коллекции и конфигурации, их восстановление в экземпляре SQL, а затем создание отсоединяемой резервной копии. Анализ затрат может доказать, что несколько часов простоя, чтобы непосредственно выполнить отключённое резервное копирование, лучше в конечном итоге.

Шаг 2. Создание ФАЙЛА DACPAC

DACPACs предлагает быстрый и относительно простой способ перемещения коллекций в Azure DevOps Services. Однако после того, как размер базы данных коллекции превышает определенное пороговое значение, преимущества использования DACPAC начинают уменьшаться.

Примечание.

Если средство миграции данных отображает предупреждение о том, что метод DACPAC не используется, необходимо выполнить миграцию с помощью метода виртуальной машины SQL Azure. Пропустите шаги 2–5 в этом случае и следуйте инструкциям на этапе подготовки тестового выполнения, разделе "Миграция больших коллекций", а затем перейдите к определению типа миграции. Если средство миграции данных не отображает предупреждение, используйте метод DACPAC, описанный на этом шаге.

DACPAC — это функция SQL Server, которая позволяет упаковывать базы данных в один файл и развертывать их в других экземплярах SQL Server. Файл DACPAC также можно восстановить непосредственно в Azure DevOps Services, поэтому его можно использовать в качестве метода упаковки для получения данных коллекции в облаке.

Внимание

• При использовании SqlPackage.exe следует использовать версию платформы .NET Framework SqlPackage.exe для подготовки файла DACPAC. Установщик MSI должен использоваться для установки версии .NET Framework для SqlPackage.exe. Не используйте интерфейс командной строки dotnet или версии .zip (Windows .NET 6) для SqlPackage.exe, так как эти версии могут создавать DACPAC, которые несовместимы с Azure DevOps Services.
• Версия 161 SqlPackage шифрует подключения к базе данных по умолчанию и может не подключаться. Если вы получаете ошибку процесса входа, добавьте ;Encrypt=False;TrustServerCertificate=True в строку подключения инструкции SqlPackage.

Скачайте и установите SqlPackage.exe с помощью последнего установщика MSI из заметок о выпуске SqlPackage.

После использования установщика MSI SqlPackage.exe устанавливается в путь, подобный %PROGRAMFILES%\Microsoft SQL Server\160\DAC\bin\.

При создании DACPAC следует учитывать два соображения: диск, на котором сохраняется DACPAC, и место на диске компьютера, создающего DACPAC. Необходимо убедиться, что для выполнения операции достаточно места на диске.

По мере создания пакета SqlPackage.exe временно сохраняет данные из коллекции в временном каталоге на диске C компьютера, из которой вы инициируете запрос на упаковку.

Возможно, вы обнаружите, что диск C слишком мал, чтобы поддерживать создание DACPAC. Вы можете оценить объем необходимого пространства, найдите самую большую таблицу в базе данных коллекции. DACPACs создаются по одной таблице за раз. Максимальное требование к пространству для запуска поколения примерно эквивалентно размеру самой большой таблицы в базе данных коллекции. Если вы сохраните созданный DACPAC на диск C, учтите размер базы данных коллекции, указанный в файле DataMigrationTool.log в результате проверки.

Файл DataMigrationTool.log предоставляет список крупнейших таблиц в коллекции при каждом запуске команды. Пример размеров таблиц для коллекции см. в следующих выходных данных. Сравните размер самой большой таблицы с свободным пространством на диске, на котором размещается временный каталог.

Внимание

Прежде чем продолжить создание ФАЙЛА DACPAC, убедитесь, что коллекция отсоединена.

[Info   @08:23:59.539] Table name                               Size in MB
[Info   @08:23:59.539] dbo.tbl_Content                          38984
[Info   @08:23:59.539] dbo.tbl_LocalVersion                     1935
[Info   @08:23:59.539] dbo.tbl_Version                          238
[Info   @08:23:59.539] dbo.tbl_FileReference                    85
[Info   @08:23:59.539] dbo.Rules                                68
[Info   @08:23:59.539] dbo.tbl_FileMetadata                     61

Убедитесь, что на диске, на котором размещается временный каталог, имеется как минимум столько же свободного места. Если это не так, необходимо перенаправить временный каталог, задав переменную среды.

SET TEMP={location on disk}

Еще одно соображение заключается в сохранении данных DACPAC. Указание сохраненного расположения на отдаленный удаленный диск может привести к более продолжительному времени генерации. Если быстрый диск, например твердотельный накопитель (SSD), доступен локально, рекомендуется использовать диск в качестве расположения сохранения DACPAC. В противном случае всегда быстрее использовать диск, расположенный на компьютере, где находится база данных коллекции, а не удаленный диск.

Теперь, когда вы определили целевое расположение для DACPAC и убедились, что у вас достаточно места, пришло время создать DACPAC-файл.

Откройте окно командной строки и перейдите в расположение SqlPackage.exe. Чтобы создать DACPAC, замените значения заполнителей необходимыми значениями, а затем выполните следующую команду:

SqlPackage.exe /sourceconnectionstring:"Data Source={database server name};Initial Catalog={Database Name};Integrated Security=True" /targetFile:{Location & File name} /action:extract /p:ExtractAllTableData=true /p:IgnoreUserLoginMappings=true /p:IgnorePermissions=true /p:Storage=Memory

• Источник данных: экземпляр SQL Server, на котором размещена база данных сбора Azure DevOps Server.
• Исходный каталог: имя базы данных коллекции.
• targetFile: расположение на диске и имя ФАЙЛА DACPAC.

Команда создания DACPAC, которая выполняется на самом уровне данных Azure DevOps Server, показана в следующем примере:

SqlPackage.exe /sourceconnectionstring:"Data Source=localhost;Initial Catalog=Foo;Integrated Security=True" /targetFile:C:\DACPAC\Foo.dacpac /action:extract /p:ExtractAllTableData=true /p:IgnoreUserLoginMappings=true /p:IgnorePermissions=true /p:Storage=Memory

Выходные данные команды — это DACPAC-файл, созданный из базы данных коллекции Foo под названием Foo.dacpac.

Настройте коллекцию для миграции

После восстановления базы данных коллекции на виртуальной машине Azure настройте вход SQL, чтобы разрешить Azure DevOps Services подключаться к базе данных для переноса данных. Этот вход разрешает доступ только для чтения к одной базе данных.

Чтобы начать, откройте SQL Server Management Studio на виртуальной машине, затем откройте новое окно запроса к базе данных, которую нужно импортировать.

Установите простой режим восстановления базы данных.

ALTER DATABASE [<Database name>] SET RECOVERY SIMPLE;

Создайте учетную запись входа SQL для базы данных и назначьте этой учетной записи роль 'TFSEXECROLE'.

USE [<database name>]
CREATE LOGIN <pick a username> WITH PASSWORD = '<pick a password>'
CREATE USER <username> FOR LOGIN <username> WITH DEFAULT_SCHEMA=[dbo]
EXEC sp_addrolemember @rolename='TFSEXECROLE', @membername='<username>'

В следующем примере Fabrikam две команды SQL будут выглядеть следующим образом:

ALTER DATABASE [Fabrikam] SET RECOVERY SIMPLE;

USE [Foo]
CREATE LOGIN fabrikam WITH PASSWORD = 'fabrikampassword'
CREATE USER fabrikam FOR LOGIN fabrikam WITH DEFAULT_SCHEMA=[dbo]
EXEC sp_addrolemember @rolename='TFSEXECROLE', @membername='fabrikam'

Примечание.

Включите режим проверки подлинности SQL Server и Windows в SQL Server Management Studio на виртуальной машине. Если режим проверки подлинности не включен, миграция завершается сбоем.

Настройка файла спецификации миграции для целевой виртуальной машины

Обновите файл спецификации миграции, чтобы включить сведения о подключении к экземпляру SQL Server. Откройте файл спецификации миграции и внесите следующие обновления.

1. Удалите параметр DACPAC из объекта исходных файлов.

   Спецификация миграции перед изменением отображается в следующем коде.

   

   Спецификация миграции после изменения показана в следующем коде.

   

2. Заполните необходимые параметры и добавьте следующий объект свойств в исходный объект в файл спецификации.

   "Properties":
   {
       "ConnectionString": "Data Source={SQL Azure VM Public IP};Initial Catalog={Database Name};Integrated Security=False;User ID={SQL Login Username};Password={SQL Login Password};Encrypt=True;TrustServerCertificate=True" 
   }
   

После применения изменений спецификация миграции выглядит следующим образом.

Теперь спецификация миграции настроена на использование виртуальной машины SQL Azure для миграции. Выполните остальные действия по подготовке к миграции в Azure DevOps Services. После завершения миграции обязательно удалите вход SQL или смените пароль. Корпорация Майкрософт не сохраняет сведения о входе после завершения миграции.

Шаг 3. Отправка ФАЙЛА DACPAC

Примечание.

Если вы используете метод виртуальной машины SQL Azure, необходимо предоставить только строку подключения. Вам не нужно отправлять файлы, и вы можете пропустить этот шаг.

DACPAC должен быть помещен в контейнер хранилища Azure, который может быть существующим контейнером или контейнером, созданным специально для вашей миграции. Важно убедиться, что контейнер создан в правильных географических расположениях.

Azure DevOps Services доступна в нескольких географических расположениях. При импорте в эти расположения важно правильно разместить данные, чтобы миграция могла успешно начаться. Данные должны размещаться в том же географическом расположении, в которое вы импортируете. Размещение данных в любом месте приводит к тому, что миграция не может начаться. В следующей таблице перечислены допустимые географические расположения для создания учетной записи хранения и отправки данных.

Требуемое географическое расположение миграции	Географическое расположение учетной записи хранения
Центральная США	Центральная США
Западная Европа	Западная Европа
Соединенное Королевство	Соединенное Королевство (юг)
Восточная Австралия	Восточная Австралия
Южная Бразилия	Южная Бразилия
Центральная Индия	Центральная Индия
Центральная Канада	Центральная Канада
Азиатско-Тихоокеанский регион (Сингапур);	Азиатско-Тихоокеанский регион (Сингапур);

Хотя Azure DevOps Services доступна в нескольких географических районах США, новые службы Azure DevOps Services принимаются только в центральном регионе США. Вы не можете перенести данные в другие расположения Azure в США в настоящее время.

Создайте контейнер объектов BLOB из портала Azure. После создания контейнера загрузите файл коллекции DACPAC.

После завершения миграции удалите контейнер и сопутствующую учетную запись хранения с помощью таких средств, как AzCopy или любое другое средство обозревателя хранилища Azure.

Примечание.

Если размер файла DACPAC превышает 10 ГБ, рекомендуется использовать AzCopy, так как она поддерживает многопоточные передачи для ускорения отправки.

Шаг 4. Создание маркера SAS

Маркер общей подписи (SAS) предоставляет делегированный доступ к ресурсам в учетной записи хранилища. Маркер позволяет предоставить корпорации Microsoft минимально необходимый уровень привилегий для доступа к вашим данным для выполнения миграции.

Маркеры SAS можно создать с помощью портал Azure. С точки зрения безопасности рекомендуется выполнять следующие задачи:

1. Выберите только чтение и список в качестве разрешений для вашего маркера SAS. Другие разрешения не требуются.
2. Установите срок действия не более семи дней в будущем.
3. Ограничить доступ только к IP-адресам Azure DevOps Services.
4. Рассматривайте ключ SAS как секрет. Не оставляйте ключ в небезопасном расположении, так как он предоставляет доступ для чтения и списка к любым данным, хранящимся в контейнере.

Шаг 5. Завершение спецификации миграции

В начале процесса вы частично заполнили файл спецификации миграции, известный как migration.json. На этом этапе достаточно информации, чтобы завершить все остальные поля, кроме типа миграции. Тип миграции рассматривается далее в разделе миграции.

В файле спецификации migration.json в разделе Source заполните следующие поля.

• Расположение. Вставьте ключ SAS, созданный из скрипта, а затем скопированный на предыдущем шаге.
• Dacpac: убедитесь, что файл, в том числе расширение DACPAC , имеет то же имя, что и файл DACPAC, отправленный в учетную запись хранения.

Окончательный файл спецификации миграции должен выглядеть следующим образом.

Определение типа миграции

Импорт может быть помещен в очередь как тестовый запуск (DryRun) или промышленный запуск (ProductionRun). Параметр ImportType определяет тип миграции:

• DryRun: также называется тестовым запуском. Используется для тестирования и проверки. Система удаляет тест через 45 дней.
• ProductionRun: используйте рабочий запуск, если вы хотите сохранить результирующий перенос и использовать организацию в Azure DevOps Services после завершения миграции.

Совет

Мы всегда рекомендуем сначала выполнить тестовую миграцию.

Организации для тестового запуска

Тестовые организации помогают командам тестировать миграцию своих коллекций. Перед запуском рабочей миграции все завершенные тестовые организации должны быть удалены. Все тестовые организации имеют ограниченное существование и автоматически удаляются после заданного периода времени. Сведения о том, когда организация удаляется, будет включена в сообщение об успешном выполнении миграции. Обязательно запишите эту дату и запланируйте соответствующим образом.

Тестовые организации существуют в течение 45 дней перед их удалением. После указанного периода времени тестовая организация запуска удаляется. Вы можете повторять тестовый импорт столько раз, сколько потребуется, прежде чем выполнять продуктивную миграцию.

Удаление тестового запуска

Удалите все предыдущие тестовые запуски перед попыткой пройти новый. Когда ваша команда готова выполнить рабочую миграцию, необходимо вручную удалить тестовую организацию запуска. Прежде чем запустить вторую тестовую миграцию или окончательную рабочую миграцию, удалите все предыдущие организации Azure DevOps Services, созданные в предыдущем тестовом запуске. Дополнительные сведения см. в разделе "Удаление организации".

Совет

Необязательная информация, которая поможет пользователю добиваться большего успеха. Любая миграция тестового прогона, следующая за первой, может занять больше времени из-за дополнительного времени, необходимого для очистки ресурсов из предыдущих тестовых запусков.

Имя организации может стать доступным через час после удаления или переименования. Дополнительные сведения см. в статье о задачах после миграции.

Если возникли проблемы с миграцией, смотри статью "Устранение неполадок миграции и ошибок миграции".

Запуск миграции

Теперь ваша команда готова начать процесс выполнения миграции. Рекомендуется начать с успешной тестовой миграции, прежде чем пытаться выполнить миграцию в рабочей среде. С помощью импорта тестового запуска вы можете заранее увидеть, как выглядит миграция, определить потенциальные проблемы и получить опыт, прежде чем перейти к рабочему запуску.

Примечание.

• Если необходимо повторить завершённую производственную миграцию для коллекции, например, из-за отката, обратитесь в службу поддержки клиентов Azure DevOps Services , прежде чем ставить в очередь другую миграцию.

• Администраторы Azure могут запретить пользователям создавать новые организации Azure DevOps. Если включена политика тенанта Microsoft Entra, миграция не будет завершена. Прежде чем начать, убедитесь, что политика не задана или есть исключение для пользователя, выполняющего миграцию. Дополнительные сведения см. в разделе "Ограничить создание организации с помощью политики клиента Microsoft Entra".
• Azure DevOps Services не поддерживает политики удержания для каждой конвейерной линии, и они не переносятся в облачную версию.

Соображения относительно планов отката.

Распространенная озабоченность для команд, выполняющих финальный запуск в производство, — это план отката на случай, если что-то пойдет не так с миграцией. Мы настоятельно рекомендуем выполнить тестовый запуск, чтобы убедиться, что вы можете проверить параметры миграции, предоставляемые средством миграции данных для Azure DevOps.

Откат для окончательного рабочего запуска довольно прост. Перед очередью миграции отсоедините коллекцию командных проектов от Azure DevOps Server, что делает его недоступным для участников команды. Если по какой-либо причине необходимо откатить рабочий запуск и вернуть локальный сервер в режим "в сети" для участников команды, это можно сделать. Подключите на локальном сервере коллекцию проектов команды снова и сообщите команде, что они могут продолжать работу в обычном режиме, пока ваша команда перегруппируется, чтобы выяснить возможные сбои.

Затем вы можете обратиться в службу поддержки клиентов Azure DevOps Services, чтобы понять причину сбоя, если не удается определить причину. Дополнительные сведения см. в статье об устранении неполадок. Запросы в службу поддержки клиентов можно открыть на следующей странице https://aka.ms/AzureDevOpsImportSupport. Если проблема требует, чтобы инженеры группы продуктов занимались, эти случаи обрабатываются в течение обычных рабочих часов.

Отключите коллекцию проектов группы от Azure DevOps Server, чтобы подготовить ее к миграции.

Перед созданием резервной копии базы данных SQL необходимо полностью отсоединить коллекцию от Azure DevOps Server (а не SQL) с помощью средства миграции данных. Процесс отсоединения в Azure DevOps Server передает идентификационные данные пользователя, хранящиеся вне базы данных коллекции, что позволяет переносить их на новый сервер или, в данном случае, в Azure DevOps Services.

Отключение коллекции легко выполняется через консоль администрирования вашего экземпляра сервера Azure DevOps. Дополнительные сведения см. в разделе "Переместить коллекцию проектов" и "Отсоединить коллекцию".

Поставьте миграцию в очередь

Внимание

Прежде чем продолжить, убедитесь, что коллекция была отключена перед созданием файла DACPAC или отправкой базы данных коллекции на виртуальную машину SQL Azure. Если этот шаг не выполнен, миграция закончится неудачей. Если миграция завершается ошибкой, см. Устранение ошибок миграции.

Запустите миграцию с помощью команды import средства миграции данных. Команда импорта принимает файл спецификации миграции в качестве входных данных. Он анализирует файл, чтобы убедиться, что указанные значения действительны, и, если это удачно, ставит миграцию в очередь для Azure DevOps Services. Для команды импорта требуется подключение к Интернету, но не требуется подключение к экземпляру Azure DevOps Server.

Чтобы приступить к работе, откройте окно командной строки и измените каталоги на путь к средству миграции данных. Мы рекомендуем ознакомиться с текстом справки, предоставленным инструментом. Выполните следующую команду, чтобы просмотреть рекомендации и справку по команде импорта:

Migrator import /help

Команда для очереди миграции имеет следующую структуру:

Migrator import /importFile:{location of migration specification file}

В следующем примере показана завершенная команда импорта:

Migrator import /importFile:C:\DataMigrationToolFiles\migration.json

После прохождения проверки войдите в Microsoft Entra ID, используя учетные данные, связанные с тем же тенантом Microsoft Entra, для которого был создан файл журнала карты удостоверений. Пользователь, вошедшего в систему, является владельцем импортированной организации.

Примечание.

Каждый клиент Microsoft Entra ограничен пятью импортами за 24-часовый период. Только импорты, которые находятся в очереди, учитываются при вычислении этого лимита.

Когда ваша команда инициирует миграцию, уведомление по электронной почте отправляется пользователю, в очереди на миграцию. Примерно через 5–10 минут после очереди миграции ваша команда может отправиться в организацию, чтобы проверить состояние. После завершения миграции команда должна войти в систему, а уведомление по электронной почте отправляется владельцу организации.

Средство миграции данных помечает ошибки, которые необходимо исправить перед миграцией. В этой статье описываются наиболее распространенные предупреждения и ошибки, которые могут возникнуть при подготовке к миграции. После исправления каждой ошибки выполните команду migrator validate еще раз, чтобы подтвердить устранение.

Следующие шаги

Устранение ошибок миграции

Связанный контент

• Обзор миграции
• Задачи после миграции