Комментарии 11
А зачем нужна тестовая площадка под каждую ветку? Если у вас 100% покрытие функциональными тестами — вопрос снимается =)
Если присутствует ручное тестирование, то ничего не мешает иметь 1-2 настроеных инстанса приложения/виртуалки и переключаться между ветками обыкновенным git checkout.
У нас при активных 22 ветках с фичами с этим делом вполне справляется 2 тестовых инстанса autotest.some.local для jenkins'а и тестировщик.some.local для ручного тестирования.
Причем переключение на ветку и перенастройка окружения под неё делается двумя консольными командами:
git co feature/**** && phing config (да, настройки приложения для боя/тестирования/разработки разруливаются phing'ом)
Если присутствует ручное тестирование, то ничего не мешает иметь 1-2 настроеных инстанса приложения/виртуалки и переключаться между ветками обыкновенным git checkout.
У нас при активных 22 ветках с фичами с этим делом вполне справляется 2 тестовых инстанса autotest.some.local для jenkins'а и тестировщик.some.local для ручного тестирования.
Причем переключение на ветку и перенастройка окружения под неё делается двумя консольными командами:
git co feature/**** && phing config (да, настройки приложения для боя/тестирования/разработки разруливаются phing'ом)
Если вам это не нужно, это не значит, что никому не нужно. При таком подходе точно знаешь какую версию продукта ты смотришь/тестируешь. При большой команде это крайне полезно.
Да я ж не против :)
Если имеется ввиду что этот инстанс-бранч будет использоваться и программистом и тестировщиком одновременно, тогда вопрос опять же снимается =) При моем подходе любой из них может поменять ветку и поломать работу другого. Но если тестирование и разработка ведется на разных инстансах — подход вполне себе жизнеспособен, каждый знает в какой ветке сидит и что делает.
И да, про автодеплой было бы весьма интересно почитать.
Если имеется ввиду что этот инстанс-бранч будет использоваться и программистом и тестировщиком одновременно, тогда вопрос опять же снимается =) При моем подходе любой из них может поменять ветку и поломать работу другого. Но если тестирование и разработка ведется на разных инстансах — подход вполне себе жизнеспособен, каждый знает в какой ветке сидит и что делает.
И да, про автодеплой было бы весьма интересно почитать.
Отказались мы от такого подхода (вариант 2), т. к. приходилось дёргать разработчика, чтобы в нужное время посмотреть на функционал.
Мы сделали для себя как раз №4. Поднятие виртуалок занимает минуты, работает прекрасно :)
Поднятие с нуля в образа виртуалки — это быстро. Возьмите Vagrant. Учитывая то, что образ хранится уже готовый, сделать по нему образец не займёт ни много времени, ни много места (засчёт copy-on-write в файловой системе). Деплой в виртуалку какой-то ветки кода — тоже задача не из сложных. А там уже конфигурируйте доменты в hosts как вам заблагорассудится.
Для Vargant ещё появился вот такой генератор rove.io.
А как решаете проблему если разным веткам нужна разная схема в базе?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как мы устроили бранчи под каждую задачу