Проектирование стратегии конвейера и управления версиями
Когда вы только приступаете к публикации повторно используемого кода 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 с помощью запросов на вытягивание, обратитесь к рецензентам с просьбой проверить, требуются ли изменения в коде, требующие изменения основного или дополнительного номера версий.
Вы увидите, как использовать файл метаданных, в следующем упражнении.
Выбор количества конвейеров
Обычно создается коллекция спецификаций шаблонов и модулей. Часто этот код имеет смысл хранить в одном репозитории Git.
С помощью фильтров путей в Azure Pipelines можно создавать отдельные конвейеры для каждого модуля или спецификации шаблона в репозитории. Этот подход позволяет избежать публикации новой версии каждого файла Bicep в репозитории при каждом изменении одного файла. Вы можете использовать шаблоны конвейеров для определения этапов конвейера в централизованном файле, что упрощает конвейер для каждого модуля и спецификации шаблона.
Например, предположим, что у вас есть структура файлов, аналогичная показанной ранее. Можно настроить три отдельных конвейера — по одному для каждого файла Bicep. Выберите каждую вкладку, чтобы просмотреть соответствующие определение конвейер и фильтр пути:
trigger:
batch: true
branches:
include:
- main
paths:
include:
- 'module-1/**'
stages:
- template: pipeline-templates/publish-module.yml
parameters:
path: 'module-1/main.bicep'
Предположим, вы изменяете только файл module-2/main.bicep. Выполняется только конвейер для модуля 2. Но при изменении нескольких файлов в одной фиксации запускается каждый из соответствующих конвейеров.
Примечание.
Подход к созданию конвейера для каждого из повторно используемых файлов Bicep является простым и гибким. Но это может стать проблематичным, если у вас есть большое количество файлов Bicep или если вам не нужны отдельные конвейеры для каждого модуля и спецификации шаблона.
Вы также можете написать скрипты в конвейере для поиска измененного кода и публикации только соответствующих файлов. Это более сложный подход, который выходит за рамки данного модуля Microsoft Learn.
Среды для повторно используемого кода Bicep
При развертывании в Azure с помощью Bicep часто используется несколько сред, которые помогут вам проверить и протестировать код перед публикацией в рабочей среде. В предыдущих модулях обучения Microsoft Learn вы узнали, как работать с несколькими средами из конвейера развертывания.
Некоторые организации применяют одни и те же принципы как к модулям Bicep, так и к спецификациям шаблонов. Например, сначала можно опубликовать новые версии модулей в непроизводном реестре, чтобы пользователи каждого модуля могли попробовать новые версии. После выхода изменений вы можете опубликовать модули в рабочем реестре вашей организации.
Как и в случае с обычными развертываниями, можно использовать задания и шаблоны конвейеров для определения последовательности развертывания в средах. В этом модуле Microsoft Learn мы выполняем публикацию в одной среде, чтобы обеспечить простоту конвейера.
При использовании модулей из реестра или при использовании спецификации шаблона в качестве модуля Bicep можно использовать псевдонимы. Вместо указания имени реестра или расположения спецификации шаблона при каждом определении модуля используется его псевдоним.
Благодаря псевдонимам процесс развертывания можно с легкость использовать в нескольких средах. Например, при определении модуля можно использовать псевдоним вместо имени реестра. Затем можно создать конвейер развертывания, чтобы настроить псевдоним для сопоставления с:
- реестром модулей разработки при развертывании в среде песочницы;
- рабочим реестром при развертывании в других средах.
Примечание.
Псевдонимы не применяются при публикации. Они работают только при использовании спецификаций шаблонов или модулей в файле Bicep.