CM и Agile процесс проверки слияния с магистралью? - PullRequest
0 голосов
/ 05 апреля 2010

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

В нашем процессе магистраль считается веткой интеграции; он не должен быть выполнимым, но он должен быть стабильным и функциональным, чтобы другие могли его использовать. Мы создаем ветки Feature Trunk для новых разработок. Вся работа и тестирование происходит в этих ветках. Отдельная ветвь затягивается по мере необходимости, чтобы оставаться интегрированной с магистралью, как и другие функции, которые приняты и передаются. Но теперь у нас есть многочисленные тематические ветви. Каждый из них сфокусирован, имеет короткий жизненный цикл и выталкивается в магистраль по мере их завершения, поэтому мы не обсуждаем необходимость ветвей и очень стараемся быть гибкими.

Моя проблема возникает здесь: я требую, чтобы ответвления извлекались из магистрали в конце их жизненного цикла, а также проходили валидацию, регрессионное тестирование и обрабатывали все проблемы конфигурации, прежде чем отправлять в транк. После реинтеграции в багажник я прошу хотя бы сборку и автоматический тест на дым. Тем не менее, теперь я получаю откат на проверку магистрали. Аргумент заключается в том, что разработчики могут объединять код и не нуждаются в этапах проверки качества, поскольку они уже завершили работу в ветви функций. Поэтому дополнительное тестирование не требуется. Я попытался напомнить руководству о многочисленных случаях, когда «безмозглые» слияния проваливались. Их решение состоит в том, чтобы вместо сборки и регрессионного тестирования разработчик разобрал ветку Feature и только что слитый Trunk. Этот процесс в их сознании заменит регрессионное тестирование, о котором я просил. Так что вам нужно, когда вы реинтегрируете обратно в Ствол? С какими проблемами мы столкнемся, если уберем этот шаг и заменим его на diff? Является ли стоимость пребывания в Agile дополнительной работой по интеграции филиалов?

Спасибо за любой вклад. LoneCM

1 Ответ

0 голосов
/ 05 апреля 2010

Я не понимаю, почему «сборка и автоматизированное испытание на дымность» должны быть какой-то существенной дополнительной работой или рассматриваться как «стоимость пребывания в Agile» - учитывая, что все это, конечно, автоматизировано. (На самом деле я обычно считаю, что непрерывная сборка / интеграция и автоматическое тестирование являются частью набора лучших практик, связанных с гибкой разработкой). diff в общем случае не сокращает его, поскольку могут существовать файлы, которые никогда не будут сравниваться (например, двоичные ресурсы, формат которых включает метки времени), и только тестирование может подтвердить, что различия, если таковые имеются, не влияют на корректность.

Если несколько разработчиков (предположительно их пары, если вы занимаетесь парным программированием) все могут фиксировать транкинг независимо (т. Е. Не допускается «блокировка транка»), то настоятельно рекомендуется тот тип минимальной проверки работоспособности, которую вы поддерживаете - будь то базовое развитие "гибким", полностью хаотичным или чем-то еще; -).

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...