Выполнение тестовой миграции
Теперь ваша команда готова начать процесс запуска тестового выполнения миграции, а затем, наконец, полную рабочую миграцию. На этом этапе мы обсудим окончательные шаги по очереди миграции в дополнение к другим задачам, которые обычно приходят в конце проекта миграции.
Необходимые компоненты
Завершите этап выполнения теста подготовки перед началом миграции тестового запуска.
Проверка коллекции
Проверьте каждую коллекцию, которую требуется перенести в Azure DevOps Services. Этап проверки проверяет различные аспекты коллекции, включая, но не ограничивается, размером, сортировкой, удостоверением и процессами.
Запустите проверку с помощью средства миграции данных.
Скачайте средство миграции данных.
Скопируйте ZIP-файл на один из уровней приложений Azure DevOps Server.
Распакуйте файл . Вы также можете запустить средство с другого компьютера без установленного сервера Azure DevOps Server, если компьютер может подключиться к базе данных конфигурации экземпляра Сервера Azure DevOps.
Откройте окно командной строки на сервере и введите команду cd, чтобы перейти в каталог, в котором хранится средство миграции данных. Несколько минут, чтобы просмотреть содержимое справки для средства.
a. Чтобы просмотреть справку и руководство верхнего уровня, выполните следующую команду.
Migrator /helpb. Просмотрите текст справки для команды.
Migrator validate /helpПри первом проверке коллекции команда должна иметь следующую простую структуру.
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}Чтобы запустить средство с компьютера, отличного от сервера Azure DevOps Server, требуется параметр /connectionString . Параметр строка подключения указывает на базу данных конфигурации Azure DevOps Server. Например, если проверенная команда выполняется корпорацией Fabrikam, команда будет выглядеть следующим образом.
Migrator validate /collection:http://fabrikam:8080/DefaultCollection /tenantDomainName:fabrikam.OnMicrosoft.com /region:{region} /connectionString:"Data Source=fabrikam;Initial Catalog=Configuration;Integrated Security=True"Внимание
Средство миграции данных не редактирует данные или структуры в коллекции. Он считывает коллекцию только для выявления проблем.
После завершения проверки можно просмотреть файлы журнала и результаты.
Во время проверки вы получите предупреждение, если некоторые из конвейеров содержат правила хранения для каждого конвейера. Azure DevOps Services использует модель хранения на основе проекта и не поддерживает политики хранения на основе конвейера. При переходе политики не переносились в размещенную версию. Вместо этого применяются политики хранения на уровне проекта по умолчанию. Сохраняйте сборки, важные для вас, чтобы избежать их потери.
После прохождения всех проверок можно перейти к следующему шагу процесса миграции. Если средство миграции данных помечает все ошибки, исправьте их перед продолжением. Рекомендации по исправлению ошибок проверки см. в разделе "Устранение неполадок при миграции и миграции".
Импорт файлов журнала
При открытии каталога журнала может появиться несколько файлов ведения журнала.
Основной файл журнала называется DataMigrationTool.log. Он содержит сведения обо всем, что было запущено. Чтобы упростить фокус на определенных областях, журнал создает журнал для каждой основной операции проверки.
Например, если TfsMigrator сообщает об ошибке на шаге "Проверка процессов проекта", можно открыть файл ProjectProcessMap.log , чтобы просмотреть все, что было запущено для этого шага, а не прокручивать весь журнал.
Просмотрите файл TryMatchOobProcesses.log , только если вы пытаетесь перенести процессы проекта для использования унаследованной модели. Если вы не хотите использовать унаследованную модель, эти ошибки можно игнорировать, так как они не препятствуют импорту в Azure DevOps Services. Дополнительные сведения см. на этапе проверки миграции.
Создание файлов миграции
Средство миграции данных проверило коллекцию и возвращает результат проверки всех коллекций. Прежде чем перенести коллекцию в автономном режиме, создайте файлы миграции. При выполнении prepare команды создается два файла миграции:
- IdentityMapLog.csv. Описывает сопоставление удостоверений между Active Directory и идентификатором Microsoft Entra.
- migration.json. Требуется заполнить спецификацию миграции, которую вы хотите использовать для запуска миграции.
Команда подготовки
Эта prepare команда помогает создавать необходимые файлы миграции. По сути, эта команда сканирует коллекцию, чтобы найти список всех пользователей, чтобы заполнить журнал карты удостоверений, IdentityMapLog.csv, а затем пытается подключиться к идентификатору Microsoft Entra, чтобы найти совпадение каждого удостоверения. Для этого вашей компании необходимо использовать средство Microsoft Entra Connect (прежнее название — средство синхронизации каталогов, средство синхронизации каталогов или средство DirSync.exe).
Если синхронизация каталогов настроена, средство миграции данных должно найти соответствующие удостоверения и пометить их как активные. Если совпадений нет, удостоверение помечается как "Журнал " в журнале карты удостоверений, поэтому необходимо изучить, почему пользователь не включен в синхронизацию каталогов. Файл спецификации миграции, 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 и необходимые действия описаны в следующей таблице:
| Поле | Description | Необходимые действия |
|---|---|---|
| Исходный код | Сведения о расположении и именах исходных файлов данных, используемых для миграции. | Действия не требуется. Просмотрите сведения о следующих действиях подполя. |
| Расположение | Ключ подписанного URL-адреса для учетной записи хранения Azure, в которой размещен пакет приложения уровня данных (DACPAC). | Действия не требуется. Это поле рассматривается на следующем шаге. |
| Файлы | Имена файлов, содержащих данные миграции. | Действия не требуется. Просмотрите сведения о следующих действиях подполя. |
| DACPAC | ФАЙЛ DACPAC, который упаковыв базу данных коллекции для переноса данных во время миграции. | Действия не требуется. На следующем шаге вы создадите этот файл с помощью коллекции, а затем отправьте его в учетную запись хранения Azure. Обновите файл на основе имени, используемого при его создании позже в этом процессе. |
| Назначение | Свойства новой организации для миграции. | Действия не требуется. Просмотрите сведения о следующих действиях подполя. |
| Имя. | Имя организации, которую необходимо создать во время миграции. | Введите имя. Имя можно быстро изменить позже после завершения миграции. ПРИМЕЧАНИЕ. Не создавайте организацию с этим именем перед запуском миграции. Организация создается в рамках процесса миграции. |
| ImportType | Тип миграции, которую требуется выполнить. | Действия не требуется. На следующем шаге выберите тип миграции для выполнения. |
| Данные проверки | Сведения, необходимые для обеспечения работы с миграцией. | Средство миграции данных создает раздел "ValidationData". Она содержит сведения, помогающие повысить возможности миграции. Не изменяйте значения в этом разделе или миграция может завершиться ошибкой. |
После завершения предыдущего процесса у вас должен быть файл, который выглядит следующим образом.
На предыдущем изображении планировщик миграции Fabrikam добавил имя организации fabrikam-import и выбранный CUS (Центральная США) в качестве географического расположения для миграции. Другие значения были оставлены без изменений непосредственно перед тем, как планировщик принял коллекцию в автономном режиме для миграции.
Примечание.
Импорт тестового запуска автоматически добавляется в конец имени организации, который можно изменить после миграции.
Поддерживаемые регионы Azure для миграции
Azure DevOps Services доступна в нескольких географических расположениях Azure. Но для миграции поддерживаются не все расположения, в которых доступны службы Azure DevOps Services. В следующей таблице перечислены географические расположения Azure, которые можно выбрать для миграции. Кроме того, это значение, которое необходимо поместить в файл спецификации миграции для назначения этой географической области для миграции.
| Географическое расположение | Географическое расположение Azure | Значение спецификации импорта |
|---|---|---|
| Соединенные Штаты | Центральная США | CUS |
| Европа | Западная Европа | WEU |
| Соединенное Королевство | Соединенное Королевство (юг) | UKS |
| Австралия | Восточная Австралия | EAU |
| Южная Америка | Южная Бразилия | SBR |
| Азиатско-Тихоокеанский регион | Индия (юг) | MA |
| Азиатско-Тихоокеанский регион | Юго-Восточная Азия (Сингапур) | SEA |
| Канада | Центральная Канада | CC |
Журнал карты удостоверений
Журнал карты удостоверений имеет равное значение фактическим данным, которые вы переносите в Azure DevOps Services. При просмотре файла важно понять, как работает миграция удостоверений и какие потенциальные результаты могут повлечь за собой. При переносе удостоверения он может стать активным или историческим. Активные удостоверения могут войти в Azure DevOps Services, но исторические удостоверения не могут.
Активные удостоверения
Активные удостоверения ссылаются на удостоверения пользователей в Azure DevOps Services после миграции. В Azure DevOps Services эти удостоверения лицензируются и отображаются как пользователи в организации. Удостоверения помечены как активные в столбце "Ожидаемый импорт состояния " в файле журнала карты удостоверений.
Исторические удостоверения
Исторические удостоверения сопоставляются как таковые в столбце "Ожидаемый импорт состояния " в файле журнала карты удостоверений. Удостоверения без записи строки в файле также становятся историческими. Пример удостоверения без записи строки может быть сотрудником, который больше не работает в компании.
В отличие от активных удостоверений, исторические удостоверения:
- Не имеет доступа к организации после миграции.
- У вас нет лицензий.
- Не отображайте пользователей в организации. Все, что сохраняется, — это понятие имени этого удостоверения в организации, чтобы его журнал можно было искать позже. Рекомендуется использовать исторические удостоверения для пользователей, которые больше не работают в компании или не нуждаются в дальнейшем доступе к организации.
Примечание.
После импорта удостоверения как исторического, он не может стать активным.
Общие сведения о файле журнала карты удостоверений
Файл журнала карты удостоверений аналогичен приведенному ниже примеру:
Столбцы в файле журнала карты удостоверений описаны в следующей таблице:
Вы и администратор Microsoft Entra должны исследовать пользователей, помеченных как "Нет совпадения" (проверка синхронизации идентификаторов Microsoft Entra ID), чтобы понять, почему они не являются частью синхронизации Microsoft Entra Connect.
| Столбец | Description |
|---|---|
| Active Directory: пользователь (Azure DevOps Server) | Понятное отображаемое имя, используемое удостоверением в Azure DevOps Server. Это имя упрощает определение того, какой пользователь ссылается на строку в карте. |
| Active Directory: идентификатор безопасности | Уникальный идентификатор удостоверения локальная служба Active Directory в Azure DevOps Server. Этот столбец используется для идентификации пользователей в коллекции. |
| Идентификатор Microsoft Entra: ожидаемый пользователь импорта (Azure DevOps Services) | Ожидаемый адрес входа соответствующего пользователя в ближайшее время к активному пользователю или no Match Found (Check Microsoft Entra ID Sync), который указывает, что удостоверение потеряно во время синхронизации идентификаторов Microsoft Entra ID и импортируется как исторический. |
| Ожидаемое состояние импорта | Ожидаемое состояние миграции пользователей: активен , если между Active Directory и идентификатором Microsoft Entra id или журналом , если совпадения нет. |
| Дата проверки | При последней проверке журнала карты удостоверений. |
При чтении файла обратите внимание, является ли значение в столбце "Ожидаемый импорт состояния" активным или историческим. Active указывает, что удостоверение в этой строке сопоставляется правильно при миграции. Исторические означают, что удостоверения становятся историческими при миграции. Важно просмотреть созданный файл сопоставления для полноты и правильности.
Внимание
Миграция завершается ошибкой, если основные изменения происходят в синхронизации идентификатора безопасности Microsoft Entra Connect между попытками миграции. Вы можете добавить новых пользователей между тестовых запусков и внести исправления, чтобы ранее импортированные исторические удостоверения стали активными. Но вы не можете изменить существующего пользователя, который ранее импортировался как активный. Это приводит к сбою миграции. Примером изменения может быть завершение тестовой миграции, удаление удостоверения из идентификатора Microsoft Entra, импортированного активного, повторное создание нового пользователя в идентификаторе Microsoft Entra для этого же удостоверения, а затем попытка другой миграции. В этом случае активная миграция удостоверений выполняется между Active Directory и вновь созданным удостоверением Microsoft Entra, но приводит к сбою миграции.
Проверьте правильно соответствующие удостоверения. Присутствуют ли все ожидаемые удостоверения? Сопоставляются ли пользователи с правильным удостоверением Microsoft Entra?
Если какие-либо значения необходимо изменить, обратитесь к администратору Microsoft Entra, чтобы убедиться, что удостоверение локальная служба Active Directory является частью синхронизации с идентификатором Microsoft Entra и правильно настроено. Дополнительные сведения см. в разделе "Интеграция локальных удостоверений с идентификатором Microsoft Entra".
Затем просмотрите удостоверения, помеченные как исторические. Эта метка подразумевает, что не удалось найти соответствующее удостоверение Microsoft Entra, по каким-либо из следующих причин:
- Удостоверение не настроено для синхронизации между локальная служба Active Directory и идентификатором Microsoft Entra.
- Удостоверение еще не заполняется идентификатором Microsoft Entra (например, есть новый сотрудник).
- Удостоверение не существует в экземпляре Microsoft Entra.
- Пользователь, которому принадлежит это удостоверение, больше не работает в компании.
Чтобы устранить первые три причины, настройте предполагаемое удостоверение локальная служба Active Directory для синхронизации с идентификатором Microsoft Entra. Дополнительные сведения см. в разделе "Интеграция локальных удостоверений с идентификатором Microsoft Entra". Необходимо настроить и запустить Microsoft Entra Connect для импорта удостоверений в качестве активных в Azure DevOps Services.
Вы можете игнорировать четвертую причину, потому что сотрудники, которые больше не находятся в компании, должны быть импортированы как исторические.
Исторические удостоверения (небольшие команды)
Примечание.
Стратегия миграции удостоверений, предложенная в этом разделе, должна рассматриваться только небольшими командами.
Если 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. Не используйте SqlPackage.exe dotnet CLI или .zip (Windows .NET 6), так как эти версии могут создавать DACPACs, несовместимые с 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. Откройте файл спецификации миграции и внесите следующие обновления.
Удалите параметр DACPAC из объекта исходных файлов.
Спецификация миграции перед изменением отображается в следующем коде.
Спецификация миграции после изменения показана в следующем коде.
Заполните необходимые параметры и добавьте следующий объект свойств в исходный объект в файл спецификации.
"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 доступна в нескольких географических расположениях. При импорте в эти расположения важно правильно разместить данные, чтобы убедиться, что миграция может успешно начаться. Данные должны размещаться в том же географическом расположении, в которое вы импортируете. Размещение данных в любом месте приводит к тому, что миграция не может начаться. В следующей таблице перечислены допустимые географические расположения для создания учетной записи хранения и отправки данных.
| Требуемое географическое расположение миграции | Географическое расположение учетной записи хранения |
|---|---|
| Центральная США | Центральная США |
| Западная Европа | Западная Европа |
| Соединенное Королевство | Соединенное Королевство (юг) |
| Восточная Австралия | Восточная Австралия |
| Brazil South | Южная Бразилия |
| Южная Индия | Южная Индия |
| Центральная Канада | Центральная Канада |
| Азиатско-Тихоокеанский регион (Сингапур); | Азиатско-Тихоокеанский регион (Сингапур); |
Хотя Azure DevOps Services доступна в нескольких географических расположениях в США, только центральное США расположение принимает новые службы Azure DevOps Services. Вы не можете перенести данные в другие расположения Azure в США в настоящее время.
Создайте контейнер BLOB-объектов из портал Azure. После создания контейнера отправьте файл DACPAC коллекции.
После завершения миграции удалите контейнер BLOB-объектов и сопутствующую учетную запись хранения с помощью таких средств, как AzCopy или любое другое средство обозревателя службы хранилища Azure, например обозреватель служба хранилища Azure.
Примечание.
Если размер ФАЙЛА DACPAC превышает 10 ГБ, рекомендуется использовать AzCopy. AzCopy поддерживает многопоточные отправки для ускорения отправки.
Шаг 4. Создание маркера SAS
Маркер подписанного URL-адреса (SAS) предоставляет делегированный доступ к ресурсам в учетной записи хранения. Маркер позволяет предоставить Корпорации Майкрософт самый низкий уровень привилегий, необходимый для доступа к данным для выполнения миграции.
Маркеры SAS можно создать с помощью портал Azure. С точки зрения безопасности рекомендуется выполнять следующие задачи:
- Выберите только разрешения для чтения и списка в качестве разрешений для маркера SAS. Другие разрешения не требуются.
- Установите срок действия не более семи дней в будущем.
- Ограничить доступ только к IP-адресам Azure DevOps Services.
- Рассматривайте ключ SAS как секрет. Не оставляйте ключ в небезопасном расположении, так как он предоставляет доступ для чтения и списка к любым данным, хранящимся в контейнере.
Шаг 5. Завершение спецификации миграции
Ранее в процессе частично заполнен файл спецификации миграции, известный как migration.json. На этом этапе достаточно информации, чтобы завершить все остальные поля, кроме типа миграции. Тип миграции рассматривается далее в разделе миграции.
В файле спецификации migration.json в разделе Source заполните следующие поля.
- Расположение. Вставьте ключ SAS, созданный из скрипта, а затем скопированный на предыдущем шаге.
- Dacpac: убедитесь, что файл, в том числе расширение DACPAC , имеет то же имя, что и файл DACPAC, отправленный в учетную запись хранения.
Окончательный файл спецификации миграции должен выглядеть следующим образом.
Определение типа миграции
Импорт может быть помещен в очередь в виде тестового запуска или рабочего запуска. Параметр ImportType определяет тип миграции:
- TestRun: используйте тестовый запуск для тестирования. Система удаляет тест через 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 на экземпляре Azure DevOps Server. Дополнительные сведения см. в разделе "Переместить коллекцию проектов" и "Отсоединить коллекцию".
Очередь миграции
Внимание
Прежде чем продолжить, убедитесь, что коллекция была отключена до создания ФАЙЛА DACPAC или отправки базы данных коллекции на виртуальную машину SQL Azure. Если этот шаг не выполнен, миграция завершается ошибкой. В случае сбоя миграции см. статью "Устранение ошибок миграции".
Запустите миграцию с помощью команды импорта средства миграции данных. Команда миграции принимает файл спецификации миграции в качестве входных данных. Он анализирует файл, чтобы убедиться, что указанные значения действительны и, если это успешно, он очереди миграции в 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 с удостоверением, членом того же клиента Microsoft Entra, что и файл журнала карты удостоверений. Пользователь, вошедшего в систему, является владельцем импортированной организации.
Примечание.
Каждый клиент Microsoft Entra ограничен пятью импортами за 24-часовый период. Только импорты, которые находятся в очереди, по отношению к этой крышке.
Когда ваша команда инициирует миграцию, уведомление по электронной почте отправляется пользователю, в очереди на миграцию. Примерно через 5–10 минут после очереди миграции ваша команда может отправиться в организацию, чтобы проверить состояние. После завершения миграции команда будет направлена на вход, а уведомление по электронной почте отправляется в владелец организации.
Средство миграции данных помечает ошибки, которые необходимо исправить перед миграцией. В этой статье описываются наиболее распространенные предупреждения и ошибки, которые могут возникнуть при подготовке к миграции. После исправления каждой ошибки выполните команду проверки миграции еще раз, чтобы проверить разрешение.