Разработка стратегии конвейера и управления версиями
Когда вы начинаете публиковать повторно используемый код Bicep, вы, вероятно, пользуетесь ручным подходом. Вам легко определить, какой файл Bicep необходимо опубликовать, и вполне вероятно, что у вас есть ручной процесс для повышения номера версии.
При автоматизации процесса публикации необходимо учитывать, как автоматизировать эти действия. В этом уроке вы узнаете, как внедрить систему управления версиями, которая передает изменения, внесенные в код. Кроме того, вы узнаете, как ограничить область применения конвейеров, чтобы публиковать только ожидаемый вами код.
Номера версий
В предыдущих модулях обучения Microsoft Learn вы узнали о важности управления версиями для спецификаций шаблонов и модулей Bicep. Вы можете выбрать различные подходы к настройке версий. Во многих ситуациях рекомендуется использовать многосоставную систему управления версиями. Система многокомпонентного версионирования состоит из основной версии, минорной версии и номера редакции, аналогично следующему примеру:
В предыдущем примере основная версия — 1, дополнительная версия — 4, а номер редакции — 106.
Изменения в разных частях номеров версий сообщают важные сведения о типах изменений в коде:
Всякий раз, когда вы вносите критическое изменение, следует увеличить основной номер версии. Например, предположим, что вы добавите новый обязательный параметр или удалите параметр из файла Bicep. Это примеры критических изменений, поскольку Bicep требует указания обязательных параметров в момент развертывания и не позволяет задавать значения для несуществующих параметров. Таким образом, вы обновите основной номер версии.
Каждый раз, когда вы добавляете что-то новое в код, но это не критическое изменение, следует увеличивать минорный номер версии. Например, предположим, что вы добавляете новый необязательный параметр со значением по умолчанию. Необязательные параметры не являются разрушающими изменениями, поэтому следует обновить микроверсию.
Всякий раз, когда вы вносите исправления ошибок с обратной совместимостью или другие изменения, которые не влияют на работу кода, следует увеличить номер редакции. Например, предположим, что вы рефакторингируете код Bicep, чтобы лучше использовать переменные и выражения. Если рефакторинг совершенно не изменяет поведение кода Bicep, обновите номер редакции.
Конвейер также может автоматически задать номер ревизии. Номер сборки в конвейере можно использовать в качестве номера ревизии. Это соглашение помогает гарантировать, что номера версий всегда уникальны, даже если вы не обновляете другие компоненты номеров версий.
Например, предположим, что вы используете ранее опубликованный модуль Bicep с номером версии 2.0.496. Вы видите, что новая версия модуля доступна с номером версии 2.1.502. Единственным значительным изменением является дополнительный номер версии, который указывает, что при использовании новой версии не следует ожидать критического изменения.
Заметка
Семантическое версионирование — это формализованная структура версионирования, аналогичная многокомпонентному версионированию. Семантическое версионирование включает дополнительные компоненты в версионный номер, а также строгие правила о том, когда следует установить или сбросить каждый компонент. Мы даем ссылку на дополнительную информацию о семантическом версионировании в сводке.
Ваша команда должна решить, как определить критическое изменение для управления версиями. Например, предположим, что вы создаете модуль Bicep, который развертывает учетную запись хранения. Теперь вы обновляете файл Bicep, чтобы активировать приватные конечные точки на учетной записи хранения. Вы добавляете частную зону DNS в файл Bicep одновременно.
В этом примере вы можете внести изменения, не влияя на параметры или выходные данные файла Bicep. Таким образом, любой, кто развертывает файл, может не заметить, что что-либо отличается. Но это изменение представляет значительную разницу в поведении ваших ресурсов, поэтому вы можете решить рассматривать его как основное обновление версии независимо от того,
Вы также можете использовать более простую стратегию управления версиями, например использовать номер сборки конвейера в качестве номера версии. Хотя этот подход проще реализовать, это означает, что вы не можете эффективно обмениваться различиями между версиями любому, кто использует код.
Версии и конвейеры
При интерактивной публикации кода, например с помощью Azure CLI, вы, вероятно, думаете о номере версии, который вы назначаете спецификации шаблона или модулю при публикации. Но в конвейере автоматического развертывания необходимо изменить подход, чтобы назначить номера версий. Конвейер не может автоматически обнаруживать критические изменения или советовать вам, когда следует увеличить основной или дополнительный номер версии. Тщательно рассмотрите версионирование перед публикацией спецификации шаблона или модуля.
Один из подходов — хранение файла метаданных с кодом Bicep, как показано на следующей схеме:
При обновлении кода Bicep вы обновляете сведения о версии в соответствующем файле метаданных. Убедитесь, что вы правильно определите критические и неразрывные изменения, чтобы можно было правильно увеличить номера версий.
Совет
Если ваша команда проверяет код Bicep с помощью pull-запросов, попросите рецензентов проверить, требуют ли изменения в вашем коде изменения мажорной или минорной версии.
Вы увидите, как использовать файл метаданных в следующем упражнении.
Сколько конвейеров?
Обычно создается коллекция спецификаций шаблонов и модулей. Часто этот код имеет смысл хранить в одном репозитории Git.
Используя фильтры путей в Azure Pipelines, вы можете создать отдельные конвейеры для каждого модуля или шаблона в вашем репозитории. Этот подход позволяет избежать публикации новой версии каждого файла Bicep в репозитории при каждом изменении одного файла. Вы можете использовать шаблоны конвейеров для определения шагов конвейера в централизованном файле, который обеспечивает упрощение конвейера каждого модуля и спецификации шаблонов.
Например, предположим, что у вас есть структура файлов, аналогичная приведенной ранее. Можно настроить три отдельных конвейера, один для каждого файла Bicep. Выберите каждую вкладку, чтобы просмотреть соответствующее определение конвейера и его фильтр пути:
- модуль-1
- модуль-2
- шаблон-спецификация-1
trigger:
batch: true
branches:
include:
- main
paths:
include:
- 'module-1/**'
stages:
- template: pipeline-templates/publish-module.yml
parameters:
path: 'module-1/main.bicep'
Предположим, что вы изменяете только файл модуля-2/main.bicep. Выполняется только конвейер для модуля 2. Но при изменении нескольких файлов в одном коммите запускается каждый из соответствующих конвейеров.
Заметка
Подход, при котором для каждого из повторно используемых файлов Bicep создаётся отдельный конвейер, прост и гибок. Но это может стать громоздким, если у вас большое количество файлов Bicep или если вы не хотите поддерживать отдельные конвейеры для каждого модуля и спецификации шаблона.
Вы также можете написать скрипты в конвейере, чтобы найти измененный код и опубликовать только эти файлы. Это более сложный подход, и он выходит за рамки этого модуля Microsoft Learn.
Среды для повторного использования кода Bicep
При развертывании в Azure с помощью Bicep часто используются несколько сред, которые помогут вам протестировать и оценить код перед его публикацией в продуктивной среде. В предыдущих модулях обучения Microsoft Learn вы узнали, как работать с несколькими средами из конвейера развертывания.
Некоторые организации применяют те же принципы к модулям Bicep и спецификациям шаблонов. Например, сначала можно опубликовать новые версии модулей в непроизводном реестре, чтобы пользователи каждого модуля могли попробовать новые версии. После того как они утвердят изменения, вы можете опубликовать модули в производственном реестре вашей организации.
Как и обычные развертывания, можно использовать задания и шаблоны конвейеров для определения последовательности развертываний в средах. В данном модуле Microsoft Learn мы публикуем в одну среду для упрощения конвейера.
При использовании модулей из реестра или использовании спецификации шаблона в качестве модуля Bicep можно использовать псевдонимы . Вместо указания имени реестра или расположения спецификации шаблона при каждом определении модуля используется его псевдоним.
Используя псевдонимы, вы можете легко осуществить процесс развертывания в нескольких средах. Например, при определении модуля можно использовать псевдоним вместо имени реестра. Затем можно создать конвейер развертывания, чтобы настроить псевдоним для сопоставлений с:
- Реестр модулей для разработки при развертывании в тестовой среде.
- Рабочий реестр при развертывании в других средах.
Заметка
Псевдонимы не применяются при публикации. Они функционируют только при использовании спецификаций шаблонов или модулей в файле Bicep.