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

Azure Repos | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018-TFS 2015

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

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

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

  • чтобы задать политики ветви, необходимо быть членом группы безопасности Project администраторы или иметь разрешения на изменение политик на уровне репозитория. Дополнительные сведения см. в разделе Set Git Repository Permissions.

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

  • чтобы задать политики ветви, необходимо быть членом группы безопасности Project администраторы или иметь разрешения на изменение политик на уровне репозитория. Дополнительные сведения см. в разделе Set Git Repository Permissions.

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

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

Screenshot that shows the Branches menu item.

кроме того, вы можете перейти к параметрам политики ветви с Project Параметрыполитикрепозитория ветвь имя > ветви.

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

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

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

Screenshot that shows Open the branch policies from the context menu.

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

Screenshot that shows the Branches page.

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

Screenshot that shows Open the branch policies from the context menu.

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

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

Screenshot that shows the Policies tab.

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

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

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

Screenshot that shows the Enable the Require Code Reviews policy.

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

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

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

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

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

Check the Require Code Reviews box

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

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

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

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

Чтобы задать политику, в разделе политики ветвиустановите флажок проверять связанные рабочие элементы на вкл. Этот параметр требует, чтобы рабочие элементы были связаны с запросом на включение внесенных изменений (PR). Сделайте параметр необязательным , чтобы предупредить о том, что связанные рабочие элементы отсутствуют, но допускают завершение запроса на включение внесенных изменений.

Screenshot of requiring linked work items in pull requests.

Require linked work items in your pull requests

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

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

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

Check for comment resolution

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

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

Check for comment resolution

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

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

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

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

Limit merge types

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

Применение стратегии слияния

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

Set merge requirements

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

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

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

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

Важно!

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

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

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

    Screenshot that shows the Add button next to Build validation.

  2. Заполните форму Set Build Policy (задать политику сборки ):

    Build policy settings

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

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

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

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

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

      • Немедленно при > обновлении имени ветви: этот параметр ЗАДАЕТ для политики сборки PR значение > в случае обновления ветви и последующей очередности сборки. Этот параметр обеспечивает успешную сборку изменений запроса на вытягивание даже при изменении защищенной ветви.

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

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

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

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

  3. Нажмите кнопку Сохранить.

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

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

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

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

Важно!

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

Add build policy

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

Build policy settings

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

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

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

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

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

  6. Нажмите кнопку Сохранить.

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

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

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

Require external services to approve

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

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

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

Require external services to approve

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

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

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

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

    Screenshot that shows Add required reviewers.

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

    Screenshot that shows the Add new reviewer policy screen.

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

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

      Или выберите значение обязательно , если запросы на вытягивание невозможно завершить до:

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

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

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

  3. Нажмите кнопку Сохранить.

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

Enter the path and required reviewers

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

Add automatic reviewers

Если выбран параметр обязательно, запрос на вытягивание нельзя будет завершить до:

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

Required reviewers are automatically added

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

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

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

Pull request status shows that reviewers have approved

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

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

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

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

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

Screenshot showing bypass policy enforcement permissions.

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

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

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

Важно!

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

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

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

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

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

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

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

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

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

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

вопрос & A

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

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

Что такое автозаполнение?

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

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

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

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

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

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

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

Примеры:

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

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

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

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

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

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

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

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

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

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

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

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

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