Проектирование стратегии рабочего процесса и управления версиями
Когда вы только приступаете к публикации повторно используемого кода 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.
С помощью фильтров путей в GitHub Actions можно создавать отдельные рабочие процессы для каждого модуля или спецификации шаблона в репозитории. Этот подход позволяет избежать публикации новой версии каждого файла Bicep в репозитории при каждом изменении одного файла. Вы можете использовать повторно используемые рабочие процессы для определения шагов рабочего процесса в централизованном файле, что упрощает рабочий процесс для каждого модуля и спецификации шаблона.
Например, предположим, что у вас есть структура файлов, аналогичная показанной ранее. Можно настроить три отдельных рабочих процесса — по одному для каждого файла Bicep. Выберите каждую вкладку, чтобы просмотреть соответствующие определение рабочего процесса и фильтр пути:
name: 'publish-module-1'
on:
push:
branches:
- main
paths:
- 'module-1/**'
jobs:
publish:
uses: ./.github/workflows/publish-module.yml
with:
path: 'module-1/main.bicep'
Предположим, вы изменяете только файл module-2/main.bicep. Выполняется только рабочий процесс для модуля 2. Но при изменении нескольких файлов в одной фиксации запускается каждый из соответствующих рабочих процессов.
Примечание.
Подход к созданию рабочего процесса для каждого из повторно используемых файлов Bicep является простым и гибким. Но это может стать проблематичным, если у вас есть большое количество файлов Bicep или если вам не нужны отдельные рабочие процессы для каждого модуля и спецификации шаблона.
Вы также можете написать скрипты в рабочем процессе для поиска измененного кода и публикации только соответствующих файлов. Это более сложный подход, и он выходит за рамки этого учебного модуля Microsoft Learn.
Среды для повторно используемого кода Bicep
При развертывании в Azure с помощью Bicep часто используется несколько сред, которые помогут вам проверить и проверить код перед публикацией кода в рабочей среде. В предыдущих модулях обучения Microsoft Learn вы узнали, как работать с несколькими средами из рабочего процесса развертывания.
Некоторые организации применяют одни и те же принципы как к модулям Bicep, так и к спецификациям шаблонов. Например, сначала можно опубликовать новые версии модулей в непроизводном реестре, чтобы пользователи каждого модуля могли попробовать новые версии. Затем, после того как они отключились, вы можете опубликовать модули в рабочем реестре вашей организации.
Как и в случае с обычными развертываниями, можно использовать задания и повторно используемые рабочие процессы для определения последовательности развертывания в средах. В этом модуле обучения Microsoft Learn мы публикуем одну среду, чтобы обеспечить простоту рабочего процесса.
При использовании модулей из реестра или при использовании спецификации шаблона в качестве модуля Bicep можно использовать псевдонимы. Вместо указания имени реестра или расположения спецификации шаблона при каждом определении модуля используется его псевдоним.
Используя псевдонимы, процесс развертывания можно выполнять в нескольких средах. Например, при определении модуля можно использовать псевдоним вместо имени реестра. Затем можно создать рабочий процесс развертывания, чтобы настроить псевдоним для сопоставления с:
- реестром модулей разработки при развертывании в среде песочницы;
- рабочим реестром при развертывании в других средах.
Примечание.
Псевдонимы не применяются при публикации. Они работают только при использовании спецификаций шаблонов или модулей в файле Bicep.