Учитывая, что мы используем GIT с более или менее разветвленным рабочим процессом http://nvie.com/posts/a-successful-git-branching-model/, имеет ли смысл регулярно проводить интеграционное тестирование с помощью инструмента CI, такого как Jenkins, следуя этому процессу.
- Создание новой ветки только для ежедневного интеграционного теста, ветвление от разработки
- Объединение всех ветвей функций, запланированных на следующий выпуск (если мы назовем их все функции Sprint - # - тогда мы сможем выбрать ветки по префиксу имении автоматически объединить) в эту специальную ветку
- Запустить интеграционные тесты CI для этой новой ветви
- Удалить ветку
Моя теория состоит в том, что, делая это, мы можем избежатьстрашные проблемы слияния несколькими способами.Во-первых, автоматическое слияние может не сработать, и мы узнаем, что в течение дня что-то было сделано, чтобы вывести нас с территории простого слияния.Во-вторых, мы получаем результаты тех же интеграционных тестов, которые были бы у нас, если бы мы решили объединить все в выпуск на тот момент.Очевидно, что это зависит от того, как разработчики очищают свою работу над ветвями функций и каждый день стараются освоить их перед началом сборки CI, но это не кажется обременительным требованием.Поскольку мы отбрасываем слияние, это означает, что у разработчика все еще есть возможность очистить историю своих коммитов до того, как они официально слились с веткой разработки.
Кто-нибудь пробовал подобные вещи?Не могли бы вы сделать это по-другому?
Я просто ищу способ использовать автоматизацию для проведения большего и более частого тестирования.Написание модульных тестов и TDD на самом деле не относится к этой области интеграционных тестов, потому что вы обычно запускаете дополнительные тесты для интеграции, а не только тесты юнит-тестов и TDD.