Автоматизация платформы и DevOps для акселератора целевой зоны Управление API

В этой статье приводятся рекомендации по автоматизации платформы и DevOps при использовании акселератора целевой зоны Управление API. Автоматизация платформы и DevOps предоставляют возможности для модернизации подхода к развертыванию в среде с помощью вариантов "инфраструктура как код".

Узнайте больше об автоматизации платформы и области разработки DevOps .

Рекомендации по проектированию

  • Каждая команда API может отправлять обновления из собственного репозитория разработчиков в собственный экземпляр Управление API разработки.
    • Что это означает с точки зрения планирования сети?
    • Как насчет других непроизводственных сред (например, контроля качества или промежуточного хранения)?
  • Подумайте, как следует управлять продуктами и другими сущностями или управлять версиями, особенно если несколько команд используют одни и те же продукты.
  • Рассмотрите стратегию тестирования для API и политик.

Рекомендации по проектированию

  • Центральная команда (например, команда администраторов Управление API) управляет рабочей Управление API средой.
  • Управление API конфигурации представлены в виде Resource Manager шаблонов или эквивалентных шаблонов Bicep или Terraform, и следует использовать установку на инфраструктуру как код.
  • Команда администраторов Управление API опубликует изменения конфигурации в рабочей среде Управление API из репозитория Git (репозитория издателя), принадлежащего команде администраторов Управление API.
  • Каждая отдельная команда API может создать вилку репозитория издателя, чтобы иметь собственный репозиторий разработчиков для работы.
  • Каждая команда может использовать Управление API APIOps или расширение Управление API для Visual Studio Code для извлечения соответствующих артефактов из экземпляра Управление API разработки. Эти артефакты основаны на azure Resource Manager и должны быть зафиксированы в репозитории Git команды API.

    Примечание

    Не используйте интеграцию Управление API Git.

  • Шаблоны служб и общие шаблоны должны находиться в отдельных репозиториях.
  • Изменения артефактов следует вносить в извлеченные артефакты, а затем фиксировать в Git. Они должны быть развернуты в среде разработки.
  • Чтобы повысить уровень до централизованных сред (промежуточных, рабочих и т. д.), команды API могут отправить запрос на вытягивание (PR) для объединения изменений в репозиторий издателя.
  • Команда администраторов Управление API проверяет запрос на вытягивание.
    • В идеале большинство проверок автоматизировано в рамках отправки запроса на вытягивание.
  • Шаблоны инфраструктуры как кода должны находиться в другом репозитории и развертываться в конвейере развертывания.
    • Разделить развертывание инфраструктуры и развертывание приложения. Базовая инфраструктура меняется реже, чем приложения. Рассматривайте каждый тип развертывания как отдельный поток и конвейер.
  • После успешного утверждения и объединения изменений команда администраторов Управление API может развернуть изменения в централизованно управляемой среде (промежуточной, рабочей) в соответствии с согласованными расписаниями команды api.

Допущения корпоративного уровня

Ниже приведены предположения, которые были включены в разработку акселератора целевой зоны Управление API:

  • Использование файлов Bicep "инфраструктура как код" для развертывания Управление API инфраструктуры и серверных компонентов.
  • Развертывание шаблонов инфраструктуры с помощью конвейеров.

Дальнейшие действия