Поделиться через

Политика и параметры ветви

  • Статья

Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019

Политики ветви помогают командам защитить важные ветви разработки . Политики обеспечивают качество кода и стандарты управления изменениями в команде. В этой статье описывается настройка политик ветви и управление ими. Общие сведения обо всех политиках и параметрах репозитория и веток см. в разделе Параметры и политики репозитория Git.

Ветвь с установленными обязательными политиками не может быть удалена и требует пул-реквестов (PR) для всех изменений.

Предварительные условия

  • Чтобы задать политики ветви, будьте членом группы безопасности "Администраторы проектов" или иметь уровня репозитория разрешение. Дополнительные сведения см. в разделе "Настройка разрешений репозитория Git".

  • Если вы хотите использовать Azure DevOps CLI az repos policy commands для управления политиками ветви, выполните действия, описанные в статье "Начало работы с Azure DevOps CLI".

  • Чтобы задать политики ветви, будьте членом группы безопасности "Администраторы проектов" или иметь уровня репозитория разрешение. Дополнительные сведения см. в разделе "Настройка разрешений репозитория Git".

Настройка политик ветви

Чтобы управлять политиками ветвей, выберите Репозитории>Ветви, чтобы открыть страницу Ветви на веб-портале.

Снимок экрана, показывающий пункт меню

Вы также можете добраться до параметров политики ветви через Параметры проекта>Репозиторий>Политики>Политики ветвей><Имя ветви>.

Отделения с политиками отображают значок политики. Вы можете выбрать значок, чтобы перейти непосредственно к параметрам политики ветви.

Чтобы задать политики ветвей, найдите ветвь, которую вы хотите управлять. Вы можете просмотреть список или найти свою ветвь в поле Поиск по названию ветви в правом верхнем углу.

Щелкните значок "Дополнительные параметры" рядом с ветвью и выберите политики ветви в контекстном меню.

Снимок экрана: открытие политик ветви из контекстного меню.

Настройте политики на странице параметров ветви. В следующих разделах приведены описания и инструкции для каждого типа политики.

Требовать минимального числа рецензентов

Проверки кода важны для проектов разработки программного обеспечения. Чтобы гарантировать, что команды просматривают и утверждают PR-ы, вы можете требовать утверждения от определенного количества рецензентов. Базовая политика требует, чтобы указанное число рецензентов одобрило код без отклонений.

Чтобы задать политику в разделе "Политики филиалов", установите минимальное количество рецензентов в значение "Вкл.". Введите необходимое количество рецензентов и выберите любой из следующих параметров:

Снимок экрана: включение политики

  • Выберите "Разрешить инициаторам запросов утверждать свои собственные изменения, чтобы создатель PR мог проголосовать за его утверждение. В противном случае создатель по-прежнему может проголосовать Одобрить по PR, но его голосование не учитывается в отношении минимального количества рецензентов.

  • Выберите Запретить автору последнего push-запроса утверждать собственные изменения, чтобы обеспечить разделение обязанностей. По умолчанию любой пользователь с правом на push в исходной ветви может как добавлять коммиты, так и голосовать за утверждение PR. Выбор этого параметра означает, что последнее голосование вносящего изменения не учитывается, даже если данный пользователь обычно может утверждать свои собственные изменения.

  • Выберите «Разрешить завершение, даже если некоторые рецензенты голосуют за ожидание или отклонение», чтобы разрешить завершение PR, даже если некоторые рецензенты голосуют против утверждения. Минимальное число рецензентов все еще должно дать одобрение.

  • В разделе " При отправке новых изменений":
    • Выберите "Требовать по крайней мере одно одобрение в последней итерации", чтобы потребовать хотя бы одного одобрения за последнее изменение исходной ветви.
    • Выберите "Сброс всех голосов утверждения" (не сбрасывает голоса за отклонение или ожидание), чтобы удалить все голоса утверждения, но сохранить голоса за отклонение или ожидание, как только изменяется исходная ветвь.
    • Выберите «Сброс всех голосов рецензентов кода», чтобы удалить все голоса рецензентов при каждом изменении исходной ветви, включая голоса за утверждение, отклонение или ожидание.
  • В разделе " При отправке новых изменений":
    • Выберите Требовать по крайней мере одно утверждение на каждой итерации, чтобы было необходимо как минимум одно одобрение для последнего изменения исходной ветви. Утверждение пользователя не учитывается в отношении предыдущей неутвержденной итерации, отправленной этим пользователем. В результате требуется еще одно утверждение последней итерации другим пользователем. Функция "Требовать минимум одно утверждение для каждой итерации" доступна в Azure DevOps Server 2022.1 и выше.
    • Выберите " Требовать по крайней мере одно утверждение" для последнего итерации , чтобы требовать хотя бы одного голосования за последнее изменение исходной ветви.
    • Выберите "Сброс всех голосов утверждения" (не сбрасывает голоса за отклонение или ожидание), чтобы удалить все голоса утверждения, но сохранить голоса за отклонение или ожидание в случае изменения исходной ветви.
    • Выберите "Сброс всех голосов рецензента кода", чтобы удалить все голосы рецензента при каждом изменении исходной ветви, включая голоса для утверждения, отклонения или ожидания.

Если все остальные политики пройдены, создатель может завершить PR, когда необходимое число рецензентов одобряет его.

Проверять наличие связанных рабочих элементов

Для отслеживания управления рабочими элементами можно требовать связи между PR и рабочими элементами. Связывание рабочих элементов обеспечивает больше контекста изменений и гарантирует, что обновления проходят через процесс отслеживания рабочих элементов.

Чтобы задать политику, в разделе Политики веток установите Проверка связанных рабочих элементов в положение Включено. Для этого параметра требуется, чтобы рабочие элементы были связаны с PR, чтобы он мог быть объединён. Настройте параметр необязательное, чтобы предупреждать, когда нет связанных рабочих элементов, но разрешить завершение pull request.

Снимок экрана, показывающий требование связанных рабочих элементов в пул-реквестах.

Проверка устранения комментария

Проверка политики разрешения комментариев проверяет, разрешены ли все комментарии pr.

Настройте политику разрешения комментариев для вашей ветки, установив параметр Проверка разрешения комментариев в положение Включено. Затем выберите, нужно ли сделать политику обязательной или необязательной.

Снимок экрана: проверка разрешения комментариев.

Для получения дополнительной информации о работе с комментариями к запросу на вытягивание смотрите раздел «Обзор запросов на вытягивание».

Ограничение типов слияний

Azure Repos имеет несколько стратегий слияния, и по умолчанию все они разрешены. Вы можете поддерживать последовательную историю веток, применяя стратегию слияния для завершения PR.

Установите параметр Ограничить типы слияний в положение Вкл., чтобы ограничить, какие типы слияний допускаются в вашем репозитории.

Снимок экрана «Ограничить типы слияний».

  • Базовое слияние (без быстрого переадресации) создает фиксацию слияния в целевом объекте, родители которого являются целевыми и исходными ветвями.
  • Слияние Squash создает линейную историю с одной фиксацией в целевой ветви с изменениями из исходной ветви. Узнайте больше о сквош-слиянии и о том, как оно влияет на историю ветвей.
  • Перебаза и быстрая переадресация создают линейную историю путем повторного размещения исходных фиксаций в целевой ветви без фиксации слияния.
  • Перебаза с фиксацией слияния воспроизводит исходные фиксации в целевом объекте, а также создает фиксацию слияния.

Проверка сборки

Вы можете установить политику, требующую от изменений в PR успешной сборки, прежде чем PR может быть завершен. Политики построения сокращают перерывы и обеспечивают успешное выполнение тестов. Политики сборки полезны даже в том случае, если вы используете непрерывную интеграцию (CI) на ваших ветках разработки, чтобы заблаговременно выявлять проблемы.

Политика проверки сборки ставит в очередь новую сборку, когда создается новый запрос на включение изменений или изменения отправляются в существующий запрос, который направлен на ветвь. Политика сборки оценивает результаты сборки, чтобы определить, можно ли завершить PR.

Внимание

Перед указанием политики проверки сборки укажите конвейер сборки. Если у вас нет конвейера, см. Создать конвейер сборки. Выберите тип сборки, соответствующий типу проекта.

Добавить политику проверки сборки

  1. Нажмите кнопку + рядом с проверкой сборки.

    Снимок экрана: кнопка

  2. Заполните форму Set build policy:

    Снимок экрана: параметры политики сборки.

    • Выберите конвейер сборки.

    • При необходимости задайте фильтр пути. Узнайте больше о путевых фильтрах в политике ветвлений.

    • В разделе "Триггер" выберите "Автоматически" (при обновлении исходной ветви) или "Вручную".

    • В разделе "Требование политики" выберите "Обязательный" или "Необязательный". Если выбрано Обязательное, сборки должны завершиться успешно, чтобы завершить PR. Выберите "Необязательно" , чтобы предоставить уведомление о сбое сборки, но по-прежнему разрешить выполнение PR.

    • Задайте срок действия сборки, чтобы убедиться в том, что обновления в защищенной ветви не прерывают изменения для открытых пул-реквестов.

      • Немедленно при обновлении <имени> ветви: этот параметр задает состояние политики сборки PR на сбой при обновлении ветви и повторно ставит сборку в очередь. Этот параметр гарантирует успешную сборку изменений в pull request'ах, даже если защищенная ветвь изменяется.

        Этот вариант лучше всего подходит для команд, важные ветви которых имеют мало изменений. Командам, работающим в насыщенных ветках разработки, может быть неудобно ждать сборку каждый раз при обновлении ветки.

      • После <n> часов, если <имя> ветви было обновлено: этот параметр завершает действие текущей политики, если защищенная ветвь обновляется, и актуальная сборка старше, чем указанный порог. Этот параметр представляет собой компромисс между необходимостью всегда или никогда не требовать сборку при обновлении защищённой ветви. Этот выбор уменьшает количество сборок, когда защищенная ветвь имеет частые обновления.

      • Никогда: обновления защищенной ветви не изменяют состояние политики. Это значение уменьшает количество сборок, но может вызвать проблемы при завершении PR, которые не были обновлены в последнее время.

    • Введите необязательное отображаемое имя для этой политики сборки. Это название идентифицирует политику на странице Политики ветви. Если отображаемое имя не указано, политика использует название конвейера сборки.

  3. Выберите Сохранить.

Когда владелец PR отправляет изменения, которые успешно создаются, состояние политики обновляется.

Если у вас есть политика сборки “немедленно при обновлении< названия ветки>” или “через <n> часов, если <название ветки> обновлено”, состояние политики обновляется при изменении защищенной ветки, если предыдущая сборка больше не действительна.

Проверки состояния

Внешние службы могут использовать API состояния PR для публикации подробного состояния на ваши PR. Политика филиала для дополнительных услуг позволяет внешним службам участвовать в рабочем процессе PR и определять требования политики.

Снимок экрана:

Инструкции по настройке этой политики см. в разделе "Настройка политики ветви" для внешней службы.

Автоматическое включение рецензентов кода

Вы можете автоматически добавлять рецензентов в pull-реквесты, которые изменяют файлы в определенных каталогах или файлы, либо во все pull-реквесты в репозитории.

  1. Нажмите кнопку +, расположенную рядом с автоматически включенными рецензентами.

    Снимок экрана: добавление необходимых рецензентов.

  2. Заполните экран «Добавить новое правило для рецензента».

    Снимок экрана: экран

    • Добавление пользователей и групп в рецензенты.

    • Выберите "Необязательно", если вы хотите автоматически добавить рецензентов, но не требовать их утверждения для завершения pull request.

      Или выберите "Обязательный", если pull request'ы не могут быть завершены до:

      • Каждый пользователь, добавленный в качестве рецензента, утверждает изменения.
      • По крайней мере один человек в каждой группе, добавленной в качестве рецензента, утверждает изменения.
      • Если требуется только одна группа, минимальное число участников, указанных вами, утверждают изменения.

    • Укажите файлы и папки, требующие автоматически включенных рецензентов. Оставьте это поле пустым, чтобы вызвать необходимость рецензентов для всех pull requests в ветке.

    • Выберите "Разрешить утверждать собственные изменения", если владельцы запросов на изменение могут голосовать за утверждение своих собственных запросов чтобы удовлетворить эту политику.

    • Вы можете указать сообщение ленты активности, которое отображается в pull request.

  3. Выберите Сохранить.

Обход политик ветки

В некоторых случаях может потребоваться обойти требования политики. Права на обход ограничений позволяют отправлять изменения в ветвь напрямую или завершать запросы на вытягивание, которые не соответствуют политикам ветви. Вы можете предоставить разрешения обхода пользователю или группе. Можно обойти разрешения для всего проекта, репозитория или одной ветви.

Два разрешения позволяют пользователям обойти политику ветви разными способами:

  • Обход политик при завершении pull-запросов применяется только к завершению pull-запросов. Пользователи с этим разрешением могут завершать pull-запросы, даже если они не удовлетворяют требованиям политик.

  • Обход политик при отправке применяется к пушам из локальных репозиториев и внесению изменений через веб. Пользователи с этим разрешением могут отправлять изменения непосредственно в защищенные ветви без соблюдения требований политики.

Скриншот, показывающий разрешения на обход соблюдения политики.

Дополнительные сведения об управлении этими разрешениями см. в разделе "Разрешения Git".

Внимание

Используйте осторожность при предоставлении возможности обхода политик, особенно на уровне репозитория и проекта. Политики являются краеугольным камнем безопасного и соответствующего управления исходным кодом.

Фильтры путей

Некоторые политики веток предлагают фильтрацию путей. Если задан фильтр пути, политика применяется только к файлам, соответствующим фильтру пути. Оставив это поле пустым, политика применяется ко всем файлам в ветви.

Можно указать абсолютные пути (путь должен начинаться либо с /, либо с подстановочного знака) и подстановочные знаки. Примеры:

  • /WebApp/Models/Data.cs
  • /WebApp/*
  • */Models/Data.cs
  • *.cs

Можно указать несколько путей, используя ; в качестве разделителя. Пример:

  • /WebApp/Models/Data.cs;/ClientApp/Models/Data.cs

Пути с префиксом ! исключаются, если в противном случае они были бы включены. Пример:

  • /WebApp/*;!/WebApp/Tests/* включает все файлы в /WebApp, за исключением файлов в /WebApp/Tests
  • !/WebApp/Tests/* указывает, что файлы отсутствуют, поскольку сначала ничего не включено.

Порядок фильтров имеет важное значение. Фильтры применяются слева направо.

Вопросы и ответы

Можно ли отправлять изменения непосредственно в ветви с политиками ветви?

Вы не можете отправлять изменения непосредственно в ветви с обязательными политиками ветви, если у вас нет разрешений на обход политик ветвей. Изменения в этих ветвях можно вносить только с помощью pull requests. Вы можете отправлять изменения непосредственно в ветки с необязательными политиками, если у них нет обязательных политик.

Что такое автозавершение?

Запросы на вытягивание в ветки с настроенными политиками имеют кнопку «Автозавершение». Выберите этот параметр, чтобы автоматически завершить пул-реквест после выполнения всех правил. Автозавершение полезно, если вы не ожидаете никаких проблем с изменениями.

Когда проверяются условия политики ветви?

Политики ветки переоцениваются на сервере, когда владельцы запросов на вытягивание вносят изменения и когда рецензенты голосуют. Если политика активирует сборку, состояние сборки будет ожидать завершения сборки.

Можно ли использовать определения сборки XAML в политиках ветви?

Нет, нельзя использовать определения сборки XAML в политиках ветвей.

Какие подстановочные знаки можно использовать для обязательных рецензентов кода?

Один знак звездочки * соответствует любому количеству символов, включая как слэши /, так и обратные слэши \. Вопросительные знаки ? соответствуют любому одному символу.

Примеры:

  • *.sql соответствует всем файлам с расширением .sql .
  • /ConsoleApplication/* соответствует всем файлам в папке с именем ConsoleApplication.
  • /.gitattributes соответствует файлу.gitattributes* в корневом каталоге репозитория.
  • */.gitignore соответствует любому файлу gitignore в репозитории.

Учитывается ли регистр требуемых путей рецензента кода?

Нет, политики ветви не учитывают регистр.

Как настроить несколько пользователей в качестве необходимых рецензентов, но требовать только одного из них для утверждения?

Вы можете добавить пользователей в группу, а затем добавить группу в качестве рецензента. Затем любой член группы может утвердить выполнение требования политики.

У меня есть разрешения на обход политики. Почему я по-прежнему вижу сбои политики в статусе запроса на вытягивание?

Настроенные политики всегда оцениваются для изменений pull-реквеста. Для пользователей, имеющих разрешения на обход политики, состояние политики, о котором сообщается, является только информационным. Если пользователь с правами на обход одобряет это, статус сбоя не блокирует завершение pull request.

Почему я не могу выполнить собственные запросы на вытягивание, когда установлено «Разрешить запрашивающим утвердить свои изменения»?

Как политика "Требовать минимальное количество рецензентов", так и политика автоматического включения рецензентов имеют возможность разрешить запрашивающим пользователям утвердить свои собственные изменения. В каждой политике параметр применяется только к этой политике. Этот параметр не влияет на другую политику.

Например, для пулл-реквеста установлены следующие политики:

  • Требуется минимальное количество рецензентов требует по крайней мере одного рецензента.
  • Автоматически включенные рецензенты требуют, чтобы вы или команда, в которую вы входите, были рецензентами.
  • Автоматически включенные рецензенты имеют функцию "Разрешить запрашивателям утверждать свои собственные изменения" включенной.
  • Требуется минимальное количество рецензентов, в котором Разрешить запрашивающим утверждать свои изменения не включено.

В этом случае ваше утверждение удовлетворяет автоматически включенным рецензентам, но не требованию минимального количества рецензентов, поэтому вы не можете завершить запрос на вытягивание.

Кроме того, могут существовать и другие политики, например, запрет для последнего вносящего утверждать свои собственные изменения, которые не позволяют утверждать свои изменения, даже если установлено разрешение запрашивающим пользователям утверждать свои собственные изменения.

Что происходит, когда путь в фильтрах путей не начинается ни с /, ни с подстановочного знака?

Путь в фильтрах путей, который не начинается с / или подстановочного знака, не имеет эффекта, и фильтр пути оценивается так, как если бы этот путь не был указан. Такой путь не может соответствовать тому, с чем начинается абсолютный / путь к файлу.