VSTS: автоматическая перебазировка / слияние и повторная постановка в очередь проверки сборки в случае истечения срока сборки

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

Несмотря на то, что это изменение гарантирует, что мастер всегда точен / готов к сборке / исправен, это, похоже, имеет небольшое негативное влияние на продуктивность разработчика:

  1. Члены команды должны постоянно следить за своими PR, чтобы повторно запрашивать валидацию сборок.
  2. Они не только должны повторно ставить сборки в очередь вручную, но перед этим они должны вручную перебазировать свою ветку перед повторной постановкой в ​​очередь.
  3. по мере того, как мы приближаемся к более мелким / готовым к отправке отметкам в мастере, нет. время от времени ожидается, что это число увеличится.

Я хочу автоматизировать (1) и (2). Есть ли способ настроить проверку сборки VSTS таким образом, чтобы для всех открытых PR по истечении срока сборки он автоматически перебазировал / повторно объединял исходную ветку с помощью master, а затем запрашивал сборку?


git azure-devops azure-pipelines azure-pipelines-build-task
person dparkar    schedule 23.03.2018    source источник
comment
Сам VSTS не может автоматически запрашивать и перебазировать. Вы можете найти в документе (docs.microsoft.com/en-us/vsts/git/), для параметра немедленного истечения срока сборки. Этот вариант лучше всего подходит для команд, у которых есть важные ветки с меньший объем изменений. Команды, работающие в загруженных ветвях разработки, могут счесть утомительным ожидание завершения сборки при каждом обновлении защищенной ветки.   -  person Marina Liu    schedule 26.03.2018
comment
Кроме того, если ветка master предназначена для производственных версий, вы также можете изменить модель ветвления git (аналогичную этой nvie.com/posts/a-successful-git-branching-model), например, все разработчики работают с веткой develop. И затем достаточно создать PR для немедленного слияния develop ветки с master ветвью.   -  person Marina Liu    schedule 26.03.2018
comment
Есть ли для этого существующий запрос User Voice, за который я могу проголосовать? Или мы можем создать новый?   -  person dparkar    schedule 27.03.2018
comment
Такого голоса пользователя пока нет. Вы можете создать новый здесь (visualstudio.uservoice.com/forums/).   -  person Marina Liu    schedule 27.03.2018

Ответы (1)


arrow_upward
1
arrow_downward

Я столкнулся с этой проблемой в своей организации. Установка Срок действия сборки до" Немедленно " становится слишком обременительным, когда несколько PR пытаются попасть в одно и то же время.

AFAIK - нет способа автоматически запускать перестройку всех PR, нацеленных на master, всякий раз, когда master обновляется. Я уверен, что основы есть, если вы хотите подключиться к событиям VSTS и написать код самостоятельно. Но в прошлый раз, когда я смотрел, ничего нестандартного нет.

Моя организация пошла на компромисс. Мы настраиваем PR так, чтобы срок действия сборки истек через 1 час. Таким образом, не возникает разногласий, когда несколько PR пытаются объединить одновременно. Однако у этого есть обратная сторона, которую вы описываете в своем исходном вопросе VSTS: Аннулирование сборок существующих PR, когда другая фиксация попадает в основную ветку, когда целевая ветвь (т.е. master) может выйти из строя из-за быстрого слияния двух несовместимых PR.

В итоге мы просто приняли это ограничение

  • У нас есть триггер для всех наших веток (функция, master и т. Д.), Который при добавлении новых коммитов автоматически запускает новую сборку. Таким образом, если PR удалось сорвать master, мы получим электронное письмо об этом в течение нескольких минут.

  • Если основная ветвь (то есть master) становится неработающей, все новые PR начнут терпеть неудачу в построении. Таким образом, новые PR не могут быть объединены. Обычно это привлекает внимание всех, поэтому проблема быстро всплывает на поверхность - и вся команда начинает работать над ее исправлением master.

  • Перед развертыванием master мы запускаем полную сборку VSTS, включая модульные тесты. Таким образом, если основная ветвь сломана (из-за двух несовместимых PR или по любой другой причине), мы обязательно остановим развертывание.

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

person Philip Pittle    schedule 23.03.2018
comment
Я считаю, что это справедливый компромисс, который я могу попробовать в нашей команде. Как вы настроили (2)? (все новые PR не собираются, если основная сборка не работает) - person dparkar; 23.03.2018
comment
о, новые PR, так что это должно быть последнее от мастера, и, следовательно, сборка должна завершиться ошибкой. Хорошо. понятно. - person dparkar; 23.03.2018
comment
Спасибо ! Это действительно полезно. Пока не отмечал это как ответ, надеясь получить какие-то комментарии от людей VSTS. Будем проверять. - person dparkar; 23.03.2018
comment
@dparka - да, новые PR не смогут слиться, потому что сборка завершится неудачно, поскольку мастер уже сломан. Если только они (не) заранее исправят те проблемы, которые уже были на мастере. И подождите, пока VSTS вмешаются - если у них есть лучшее решение, я бы хотел его услышать! - person Philip Pittle; 24.03.2018