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

  • Статья
  • Чтение занимает 39 мин

Azure DevOps Services | Azure DevOps Server 2022 - 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 голосовать за его утверждение. В противном случае создатель по-прежнему может проголосовать за утверждение на pr, но их голосование не будет рассчитывать на минимальное количество рецензентов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечание

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

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

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

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

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

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

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

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

Важно!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Если у вас есть значение "Немедленно при <обновлении имени ветви" или "Через 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-уведомление, которое переопределяет политику ветви, отправка автоматически обходит политику ветвей без шага или предупреждения о согласии.

Важно!

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

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

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

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

  • /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-запросу утверждать свои собственные изменения, которые не позволяют утверждать собственные изменения, даже если запрашивающие пользователи могут утверждать свои изменения .