Проверка и объединение изменений в Bicep
Вы узнали, как использовать ветви компонентов и как применить защиту ветви, чтобы убедиться, что изменения проверяются перед объединением. Теперь необходимо следовать согласованному процессу, чтобы предложить и просмотреть изменения, прежде чем они объединены.
В этом уроке вы узнаете больше о pull requests, включая то, как их создавать и использовать. Вы также узнаете, как использовать pull-реквесты для проверки кода Bicep.
Запросы на слияние
запрос на вытягивание — это запрос от вас, разработчик функции, в поддержку основной ветви. Вы просите сопровождающего влить ваши изменения в основную ветку репозитория.
Пул-реквесты и защита веток
При настройке защиты ветвей можно установить требование, чтобы владельцы кода проверяли pull-реквест. Например, вы можете включить руководителей проекта в качестве рецензентов для всех пул-реквестов или указать, что определенное количество людей должно проверять каждый пул-реквест.
Пулл-реквесты и политики ветви
При настройке политик ветвей можно требовать конкретных пользователей или группу людей для проверки запроса на вытягивание. Например, вы можете включить лидеров проекта в качестве ревьюеров для всех ваших пулл-реквестов или указать, что определенное количество человек должно проверять каждый пулл-реквест.
Вы также можете требовать, чтобы каждый запрос на вытягивание был связан с рабочим элементом. С помощью этой конфигурации можно выполнить трассировку из рабочего элемента, содержащего запрос компонента в код, реализующий изменение, вплоть до развертывания в рабочей среде.
Создание пул-реквеста
Пулл-реквест можно создать с помощью веб-интерфейса GitHub. Вы выбираете исходную ветвь, где вы внесли изменения, и целевую ветвь, которая обычно является основной ветвью репозитория.
Вы можете создать pull request, используя веб-интерфейс Azure DevOps. Вы выбираете исходную ветвь, где вы внесли изменения, и целевую ветвь, которая обычно является основной ветвью репозитория.
При создании пулреквеста необходимо указать его имя. Рекомендуется делать названия пулл-реквестов ясными и понятными. Эта практика помогает членам команды понять контекст того, что им предлагается проверить. Если у них есть разные области специализации, хорошее имя может помочь им находить pull requests, в которых они могут внести значимый отзыв, и пропускать те, которые не имеют отношения.
Кроме того, имена запросов на вытягивание часто становятся частью истории репозитория Git, поэтому рекомендуется сделать их понятными, когда кто-то будет просматривать историю.
Вы также можете добавить описание к pull-запросам. Вы можете упомянуть конкретных людей или ссылаться на проблемы в описаниях. Многие команды создают стандартизированные шаблоны для описания пулл-реквестов, чтобы было ясно, какие изменения внесены.
Вы также можете дать pull-реквестам описание. Вы можете упомянуть конкретных пользователей или ссылаться на рабочие элементы в описаниях. Многие команды создают стандартизированные шаблоны для описания pull-реквестов, чтобы было понятно, какое изменение внесено.
При создании запроса на вытягивание, вы можете пригласить людей для проверки изменений.
Иногда вы создаете пулл-реквест, чтобы получить отзывы от коллег. В этих ситуациях можно указать, что запрос на вытягивание является черновиком. Рецензенты будут знать, что вы по-прежнему работаете над изменениями. Рецензенты по-прежнему могут предоставлять отзывы, но ясно, что изменения еще не готовы к слиянию. Когда вы удовлетворены изменениями, вы можете удалить состояние черновика.
Даже после создания pull request вы можете вносить изменения в код в фича-ветке. Эти изменения входят в pull request.
Просмотр пулл-реквеста
При просмотре запроса на слияние вы можете увидеть все изменения. Вы можете оставить комментарий на весь запрос на вытягивание или на конкретные части измененных файлов. Автор запроса на вытягивание может отвечать на комментарии, а другие рецензенты могут участвовать в обсуждениях. Эти функции комментариев делают совместную работу с запросами на вытягивание интерактивным опытом.
При просмотре кода Bicep найдите следующие ключевые элементы:
- Можно ли развернуть файл? Разверните и проверьте код Bicep перед объединением. Убедитесь, что нет предупреждений линтера и что развертывание в Azure успешно выполнено. В будущем модуле Microsoft Learn вы узнаете о подходах к автоматическому развертыванию и проверке изменений.
- Является ли код Bicep ясным и понятным? Важно, чтобы все в вашей команде понимали код Bicep. При просмотре Bicep-файла в pull-запросе убедитесь, что вы точно понимаете, для чего каждое изменение. Называются ли переменные и параметры хорошо? Использовались ли комментарии для объяснения каких-либо сложных разделов кода?
- Завершено ли изменение? Если этот pull request представляет собой часть более крупной задачи, убедитесь, что ваша среда будет функционировать после слияния и развертывания этого изменения. Например, если pull request перенастраивает ресурс Azure при подготовке к последующему изменению, убедитесь, что ресурс продолжает правильно работать на протяжении всего процесса. Если запрос на вытягивание добавляет новый ресурс Azure, который еще не нужен, рассмотрите, следует ли временно добавить условие, чтобы ресурс не развертывался до тех пор, пока он не понадобится.
- Соответствует ли изменение хорошим практикам Bicep? В других модулях Microsoft Learn вы узнали об элементах качественного кода на языке Bicep. Убедитесь, что код, который вы просматриваете, соответствует тем же рекомендациям.
- Соответствует ли изменение описанию? Рекомендуется включать описательный заголовок для пулов запросов на внесение изменений. Многие команды также требуют, чтобы pull-реквесты включали описание изменений и их цель. Убедитесь, что изменения в вашем коде Bicep соответствуют сведениям о запросе на объединение. Если автор pull request связал рабочие элементы или проблемы, убедитесь, что изменения в pull request соответствуют критериям выполнения, определенным рабочими элементами.
Завершите пулл-реквест
После утверждения запроса на вытягивание его можно завершить. Это означает, что содержимое pull request объединяется в главную ветвь.
В некоторых командах автор pull request также должен его завершить. Этот процесс помогает гарантировать, что автор контролирует время слияния и может присутствовать, чтобы следить за любыми автоматизированными развертываниями. В других командах одобряющие завершают пулреквест. Ваша команда должна решить, кто объединяет pull-запросы и когда.
В некоторых командах автор пул-реквеста также должен его завершить. Этот процесс помогает гарантировать, что автор контролирует, когда происходит слияние, и может следить за любыми автоматизированными развертываниями. В других командах одобряющие завершают пулл-реквест. Вы даже можете использовать Azure DevOps для автоматического завершения pull request, когда он соответствует критериям утверждения. Ваша команда должна решить, кто и когда объединяет pull request.
Процесс вашей команды
После начала использования веток функций и pull requests процесс вашей команды может измениться следующим образом:
Член группы клонирует общий репозиторий.
Они вносят локальные изменения на ветке в своей локальной копии репозитория.
Когда они заканчивают свои изменения, они переносят свою локальную ветвь в общий репозиторий.
В общем репозитории они создают пул-реквест, чтобы объединить ветвь с главным.
Другие члены команды просматривают изменения. Когда они удовлетворены, они утверждают запрос на вытягивание и объединяются с главной ветвью общего репозитория.
Они удаляют ветви в общем репозитории и в локальной копии репозитория.
В некоторых сценариях push-отправка удаленного репозитория активирует автоматизированный конвейер для проверки, тестирования и развертывания кода. Дополнительные сведения о конвейерах см. в других модулях Microsoft Learn.
На следующей схеме показан измененный процесс.
