AS>У 1-го варианта большой минус — перед каждым слиянием UserStory в Main надо будет проводить тестирование функционала, тогда как во 2-м варианте глобальное тестирование надо будет проводить только при слиянии Iteration в Main.
При правильной организации тестирования то, что вы упомянули в роли "большого минуса 1-го варианта" на самом деле является очень существенным плюсом. Более того, только так и рекомендуется реализовывать тестирование в Agile-проектах.
У нас реализована примерно такая система:
* каждый commit возбуждает Jenkins'а, который вытаскивает изменения, собирает проект, запускает все автотесты (к сожалению, покрытие оставляет желать, но это все вопрос бизнес-приоритетов), и, если нет fail'ов, осуществляется push в master-репозиторий (пока не совсем автоматически, но то скорее боязнь автоматики и страх на-пушить чего-нибудь не того
).
Проводить "глобальное тестирование" — при всей своей кажущейся простоте, этот вариант значительно проигрывает первому, т.к. тестировать мелкие изменения (вы же не перепиливаете всю архитектуру для реализации очередной юзер стори?) в общем случае быстрее. Вернее, не тестировать, а исправлять ошибки. Если изменений было много, сначала требуется найти "виновника" провала тестов, и есть там десяток юзер сторис — придется методом половинного сечения (git bisect) искать виноватого (blame). А если изменение одно — оно, в общем случае, до master-репозитория не долетает, и фиксится на OT&E.
