Если вы являетесь членом организации, которая перешла с Azure DevOps на GitHub, это руководство объяснит изменения в ваших рабочих процессах, чтобы сделать миграцию максимально плавной.
Структура
В Azure DevOps репозитории встроены внутри командных проектов, поэтому структура вашей среды выглядит так:
- Организация
- Командный проект
- Репозитории
- Командный проект
- Репозитории
- Командный проект
Права и видимость появляются от командного проекта.
GitHub структурирован иначе. Репозитории встроены непосредственно внутри организаций, которые также включают команды:
- Корпоративная учетная запись
- Организация
- Команды
- Репозитории
- Организация
- Команды
- Репозитории
- Организация
Права и видимость определяются сочетанием членства в организации, команды и индивидуальных прав.
Концепция командного проекта, используемого для группировки репозиториев в Azure DevOps, отсутствует в GitHub, и не рекомендуется рассматривать организации в GitHub как эквивалент командных проектов.
Хотя изначально вы можете найти каждую мигрированную организацию на GitHub имеет длинный неорганизованный список репозиториев, доступ и разрешения можно предоставлять через команды членов организации, что значительно облегчает навигацию по репозиториям организации.
Аутентификация, права и команды
Существует два способа аутентификации по GitHub. Выбор метода будет зависеть от того, как настроен корпоративный аккаунт.
Если ваш корпоративный аккаунт использует Enterprise Managed Users, вы войдёте в GitHub через ваш идентификатор (например, Entra ID) и используете подготовленный аккаунт, привязанный к корпоративной учетной записи.
В противном случае вы будете использовать личный аккаунт GitHub. Этот аккаунт будет приглашён в корпоративный аккаунт и все организации, в которых вы будете работать. Если корпоративный аккаунт настроен с дополнительными ограничениями доступа к SAML, ваш личный аккаунт будет привязан к вашему IDP. Вам попросят пройти аутентификацию с помощью IDP, когда вам нужно получить доступ к ресурсам корпоративной учетной записи.
В предприятии на GitHub репозитории могут быть публичными, частными или внутренними. Приватные репозитории видны только людям и командам с явным доступом, а внутренние репозитории видны всем участникам вашего предприятия, но не для тех, кто вне предприятия. Внутренние репозитории полезны, когда нескольким организациям в одном предприятии необходимо найти и повторно использовать код. Если ваше предприятие использует Enterprise Managed Users, учетные записи пользователей не могут создавать публичные репозитории или другой публичный контент.
С помощью Git
Чтобы продолжать работать над репозиториями на Git, вам нужно внести некоторые изменения.
- Обновите удалённые URL на GitHub. См . раздел AUTOTITLE.
- Обновите способ аутентификации.
- Чтобы использовать HTTPS-аутентификацию, нужно создать personal access token. См . раздел AUTOTITLE.
- Чтобы использовать SSH-аутентификацию, вам нужно либо создать, либо добавить существующий SSH-ключ в GitHub. См . раздел AUTOTITLE.
- Если ваше предприятие или организация использует SAML single sign-on (SSO), вы должны авторизовать свой personal access token или SSH-ключ, прежде чем он сможет получить доступ к ресурсам.
Поток pull request
Теперь, когда ваша кодовая база размещена на GitHub, вы будете предлагать изменения с помощью pull-запросов, созданных в репозиториях GitHub.
Если в вашем предприятии есть интегрированные Azure Boards и Pipelines, они оба будут работать с GitHub. Вы можете продолжать ссылаться на рабочие элементы в коммит-сообщениях и pull requests. Например: Fix login bug (AB#1234).
Вы можете продолжать просматривать и управлять рабочими элементами на Azure Boards. Вы также можете связывать ветки, коммиты и pull requests с рабочими элементами внутри Azure. См. ссылки на коммиты GitHub, pull-запросы, ветки и задачи с рабочими элементами в Azure Boards на Microsoft Learn.
Защита ветвей
Люди с администраторским доступом к репозиторию могут настраивать правила защиты веток на GitHub. Они похожи на политики ветки в Azure DevOps и устанавливают правила, такие как минимальное количество одобряющих рецензентов, успешные проверки статуса и требование подписанных коммитов.
GitHub также поддерживает автоматическое назначение рецензентов на основе шаблонов файла, папки и глоба в файле CODEOWNERS репозитория. См . раздел AUTOTITLE.
Посылки и артефакты
В Azure DevOps вы, возможно, использовали Azure Artifacts для публикации и потребления пакетов (например, пакетов NuGet, npm или Maven) и для хранения артефактов сборки, созданных Azure Pipelines.
На GitHub пакеты обычно публикуются в формате GitHub Packages и связываются с репозиторием или организацией. В зависимости от того, как ваше предприятие завершило миграцию, вы можете продолжать публиковать пакеты в Azure Artifacts, перемещать пакеты в GitHub Packages или использовать комбинацию обоих методов.
Если после миграции вы больше не можете восстановить зависимости, проверьте конфигурацию исходного кода пакета. Например, вам может понадобиться обновить URL реестра или учетные данные в файлах вроде nuget.config, .npmrc, settings.xml, или в конфигурации вашего конвейера.
Дополнительные сведения см. в разделе Введение в GitHub Packages.
GitHub Copilot
Размещение ваших репозиториев на GitHub открывает полную мощь Copilot. Ваша кодовая база предоставляет Copilot весь необходимый контекст для ответов на вопросы в Копилот Чат, просмотра и внесения предложений в pull requests, а также для внесения изменений от вашего имени с помощью Агент кодирования Copilot.