Является ли хорошей идеей ветвиться и объединяться только для того, чтобы создать интеграционную ветвь для тестирования CI? - PullRequest
2 голосов
/ 11 февраля 2012

Учитывая, что мы используем GIT с более или менее разветвленным рабочим процессом http://nvie.com/posts/a-successful-git-branching-model/, имеет ли смысл регулярно проводить интеграционное тестирование с помощью инструмента CI, такого как Jenkins, следуя этому процессу.

  1. Создание новой ветки только для ежедневного интеграционного теста, ветвление от разработки
  2. Объединение всех ветвей функций, запланированных на следующий выпуск (если мы назовем их все функции Sprint - # - тогда мы сможем выбрать ветки по префиксу имении автоматически объединить) в эту специальную ветку
  3. Запустить интеграционные тесты CI для этой новой ветви
  4. Удалить ветку

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

Кто-нибудь пробовал подобные вещи?Не могли бы вы сделать это по-другому?

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

Ответы [ 2 ]

0 голосов
/ 11 февраля 2012

Мы улучшили модель ветвления вашего сайта. Посмотрите здесь:

http://dymitruk.com/blog/2012/02/05/branch-per-feature/

Вы должны рассматривать ветки dev и RC как отбрасываемые ветки, которые используются CI двумя различными способами. rerere очень помогает в этом рабочем процессе. Вы также можете поделиться своим опытом со своими коллегами. Используйте ветку master, чтобы отметить то, что было выпущено в производство. Успешная сборка тега CI-сервера.

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

0 голосов
/ 11 февраля 2012

Вы фактически получаете все упомянутые вами преимущества, плюс одно.

Расширение rerere для git будет записывать ваши ручные разрешения конфликтов слияния, поэтому, если вы выполняете это ежедневное интеграционное слияние веток вручную, когда происходит сбой автоматического слияния, ваше окончательное «реальное» слияние будет проще ( используйте это, чтобы сделать каждый отдельный разрыв единовременным, поскольку следующий automerge будет успешным).

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

Но да, принципы здравы.

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