Процессы проверки и импорта

  • Статья

Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019

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

Необходимые компоненты

  • Необходимо настроить клиент Microsoft Entra, как описано в microsoft Entra Подключение Sync: внесите изменения в конфигурацию по умолчанию. Средство миграции данных настраивает ссылку на клиент Microsoft Entra при создании организации Azure DevOps Services в рамках процесса импорта. При синхронизации локальная служба Active Directory с идентификатором Microsoft Entra участники команды могут использовать те же учетные данные для проверки подлинности, а администраторы Azure DevOps Services могут использовать группы Active Directory для настройки разрешений в организации Azure DevOps Services. Чтобы настроить синхронизацию, используйте технологию Microsoft Entra Подключение.
  • Перед началом задач импорта проверка, чтобы убедиться, что вы используете поддерживаемую версию Azure DevOps Server.
  • Мы рекомендуем использовать пошаговое руководство по миграции для выполнения импорта. Руководство содержит ссылки на техническую документацию, инструменты и рекомендации.

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

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

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

  1. Скачивание средства

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

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

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

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

     Migrator /help

    b. Просмотрите текст справки для команды:

     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 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"

    Внимание

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

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

    Снимок экрана: результаты проверки и журналы в окне командной строки.

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

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

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

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

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

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

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

Создание файлов импорта

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

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

Команда подготовки

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

Если синхронизация каталогов настроена, средство миграции данных должно найти соответствующие удостоверения и пометить их как активные. Если совпадений нет, удостоверение помечается как "Журнал " в журнале карты удостоверений, поэтому необходимо изучить, почему пользователь не включен в синхронизацию каталогов. Файл спецификации импорта, import.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 выполнении команды в средстве миграции данных в окне результатов отображается набор журналов и два файла импорта. В каталоге журнала найдите папку журналов и два файла:

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

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

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

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

Снимок экрана: созданный файл спецификации импорта.

Отображаемые поля файла import.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), чтобы понять, почему они не являются частью microsoft Entra Подключение Sync.

Столбец 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 Подключение синхронизация идентификаторов безопасности между попытками импорта. Вы можете добавить новых пользователей между сухими запусками и внести исправления, чтобы ранее импортированные исторические удостоверения стали активными. Однако изменение существующего пользователя, который ранее импортировался как активный, в настоящее время не поддерживается. Это приводит к сбою импорта. Примером изменения может быть завершение импорта с использованием сухого запуска, удаление удостоверения из идентификатора Microsoft Entra, импортированного активного, повторное создание нового пользователя в идентификаторе Microsoft Entra для этого же удостоверения, а затем попытка другого импорта. В этом случае активная попытка импорта удостоверений между Active Directory и только что созданным удостоверением Microsoft Entra, но приводит к сбою импорта.

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

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

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

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

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

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

Исторические удостоверения (небольшие команды)

Примечание.

Стратегия импорта удостоверений, предложенная в этом разделе, должна рассматриваться только небольшими командами.

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

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

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

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

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

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

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

Подготовка к импорту

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

Шаг 1. Отсоедините коллекцию в автономном режиме и отсоедините ее.

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

Шаг 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, предоставленного в импорте больших коллекций.

Если средство миграции данных не отображает предупреждение, используйте метод 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 [Foo] SET RECOVERY SIMPLE;

USE [Foo]
CREATE LOGIN fabrikam WITH PASSWORD = 'fabrikamimport1!'
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.

Теперь спецификация импорта настроена на использование виртуальной машины 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. В точке безопасности рекомендуется:

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

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

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

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

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

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

Снимок экрана: завершенный файл спецификации импорта.

Ограничение доступа только к IP-адресам Azure DevOps Services

Дополнительные сведения см. в разделе "Ограничить доступ только к IP-адресам Azure DevOps Services".

Вариант 1. Использование тегов службы

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

Вариант 2. Использование IpList

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

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

Migrator IpList /collection:{CollectionURI} /tenantDomainName:{name} /region:{region}

Список IP-адресов можно добавить в группы безопасности сети или брандмауэры через портал или программно.

Определение типа импорта

Импорт может быть помещен в очередь как сухой или рабочий запуск. Параметр ImportType определяет тип импорта:

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

Совет

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

Завершенный файл спецификации импорта с типом импорта

Организации, работающие в сухом режиме

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

Большинство организаций, работающих в сухом режиме, имеют 15 дней до их удаления. Организации, работающие в сухом режиме, также могут иметь 21-дневный срок действия, если во время импорта более 100 пользователей имеют базовую или большую лицензию. После указанного периода времени организация с сухим запуском удаляется. Перед выполнением рабочей миграции вы можете повторять импорты, выполняемые с использованием сухого запуска. Прежде чем пытаться создать новый, необходимо удалить предыдущие сухие запуски. Когда ваша команда готова выполнить рабочую миграцию, необходимо вручную удалить организацию, которая выполняется с использованием сухого запуска.

Дополнительные сведения о действиях после импорта см. в статье о последующем импорте.

При возникновении проблем с импортом см . статью "Устранение неполадок при импорте и миграции".

Запуск импорта

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

Примечание.

  • Если необходимо повторить завершенный импорт для коллекции, как и в случае отката, обратитесь в службу поддержки клиентов Azure DevOps Services перед очередями другого импорта.
  • Администраторы Azure могут запретить пользователям создавать новые организации Azure DevOps. Если включена политика клиента Microsoft Entra, импорт завершится ошибкой. Прежде чем начать, убедитесь, что политика не задана или есть исключение для пользователя, выполняющего миграцию. Дополнительные сведения см. в разделе "Ограничить создание организации с помощью политики клиента Microsoft Entra".
  • 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 import specification file}

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

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

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

Примечание.

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

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