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

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018

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

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

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

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

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

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

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

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

Снимок экрана: пункт меню

Вы такжеможете получить доступ к параметрам политики ветви с помощью имениветви><> политикрепозитория>> параметров > проекта.

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

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

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

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

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

Снимок экрана: страница

Нажмите кнопку ... . В контекстном меню выберите Branch policies (Политики ветви).

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

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

Настройте свои политики на странице Политики. Описание каждого типа политики см. в следующих разделах. Нажмите кнопку "Сохранить изменения ", чтобы применить новую конфигурацию политики.

Снимок экрана: вкладка

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

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

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

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

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

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

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

  • В разделе "При отправке новых изменений":

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

Установите флажок

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

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

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

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

Чтобы задать политику, в разделе "Политики ветвей" установите для параметра Check for linked work items to On(Вкл.). Для этого параметра требуется, чтобы рабочие элементы были связаны с запросом на вытягивание для слияния. Сделайте параметр необязательным , чтобы предупредить, если связанных рабочих элементов нет, но разрешить завершение запроса на вытягивание.

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

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

Проверка разрешения комментариев

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

Настройте политику разрешения комментариев для ветви, задав для параметра Check for comment resolution to On. Затем выберите, следует ли сделать политику обязательной или необязательной.

Проверка разрешения комментариев

Дополнительные сведения о работе с комментариями к запросу на вытягивание см. в разделе "Просмотр запросов на вытягивание".

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

Проверка разрешения комментариев

Дополнительные сведения о работе с комментариями к запросу на вытягивание см. в разделе "Просмотр запросов на вытягивание".

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

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

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

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

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

Примечание

Эта функция доступна для Azure DevOps Server 2020 и более поздних версий.

Принудительное применение стратегии слияния

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

Настройка требований к слиянию

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

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

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

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

Важно!

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

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

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

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

  2. Заполните форму политики сборки Set :

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

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

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

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

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

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

      • Немедленно при <обновлении имени> ветви: этот параметр задает состояние политики сборки ЗАПРОСА на сбой при каждом обновлении ветви и повторно отправляет сборку. Этот параметр гарантирует, что запрос на вытягивание успешно выполняет сборку, даже если защищенная ветвь изменяется.

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

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

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

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

  3. Щелкните Сохранить.

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

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

Примечание

Эта функция доступна для Azure DevOps Server 2020 и более поздних версий.

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

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

Важно!

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

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

Выберите "Добавить политику сборки " и настройте параметры в разделе "Добавить политику сборки".

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

  1. Выберите определение сборки.

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

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

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

    • Немедленно при branch name обновлении: этот параметр задает состояние политики сборки в запросе на включение внесенных изменений при обновлении защищенной ветви. Повторно создайте сборку, чтобы обновить состояние сборки. Этот параметр гарантирует, что изменения в запросах на вытягивание успешно создаются, даже если защищенная ветвь изменяется. Этот вариант лучше всего подходит для команд с важными ветвями с меньшим объемом изменений. Команды, работающие в занятых ветвях разработки, могут оказаться разрушительными для ожидания завершения сборки при каждом обновлении защищенной ветви.
    • Если обновление было обновлено через n несколько часовbranch name: этот параметр истечет текущее состояние политики при обновлении защищенной ветви, если передаваемая сборка старше введенного порогового значения. Этот параметр является компрометацией между всегда требующей сборки при обновлении защищенной ветви и никогда не требующей ее. Этот выбор отлично подходит для уменьшения числа сборок, когда защищенная ветвь имеет частые обновления.
    • Никогда: Обновления в защищенную ветвь не изменяют состояние политики. Это значение уменьшает количество сборок для ветви. Это может вызвать проблемы при закрытии запросов на вытягивание, которые не были обновлены в последнее время.
  5. Введите необязательное отображаемое имя для этой политики сборки. Это имя идентифицирует политику на странице политик ветви . Если отображаемое имя не указано, политика использует имя определения сборки.

  6. Щелкните Сохранить.

Когда владелец отправляет изменения, которые успешно создаются, состояние политики обновляется. Если выбрана политика сборки немедленно при branch name обновлении или n в нерабочее времяbranch name, состояние политики обновляется при обновлении защищенной ветви, если последняя сборка больше не действительна.

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

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

Требовать утверждения внешних служб

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

Требовать утверждения от внешних служб

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

Требовать утверждения внешних служб

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

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

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

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

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

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

    Снимок экрана: экран добавления новой политики рецензента.

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

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

      Или выберите "Обязательно" , если запросы на вытягивание не могут быть завершены до следующего:

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

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

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

  3. Щелкните Сохранить.

Примечание

Эта функция доступна для Azure DevOps Server 2020 и более поздних версий.

Выберите рецензентов для определенных каталогов и файлов в репозитории.

Введите путь и необходимые рецензенты

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

Добавление автоматических рецензентов

Если вы выберете "Обязательный", запрос на вытягивание не может быть завершен до тех пор, пока:

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

Обязательные рецензенты добавляются автоматически

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

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

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

Состояние запроса на вытягивание показывает, что рецензенты одобрили

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

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

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

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

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

Снимок экрана: разрешения на обход политики.

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

В TFS 2015–TFS 2018 с обновлением 2 разрешение на принудительное применение политики позволяет пользователям с этим разрешением выполнять следующие действия:

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

Важно!

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

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

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

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

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

Можно указать несколько путей с помощью ; разделителя. Пример

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примеры:

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

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

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

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

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

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

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

Почему не удается выполнить собственные запросы на вытягивание, если задан параметр "Разрешить запрашивателям утверждать свои изменения"?

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

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

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

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

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