Организация веток в системе контроля версий для разработчиков и тестировщиков

общие вопросы
#1

Расскажите как у вас на проекте организованы ветки для тестирования и разработки, сам проект и тесты хранятся в одном репозитории? Деплоятся ли тесты на прод вместе с проектом?

#2

у нас SVN используют :cry:

#3

У нас все просто - от мастера отбранчевывается ветка для разработки (1 -> 1.1). Когда разработчики считают, что все готово, версию(1.1) заливают на стейдж для ручного тестирования и написания интеграционных и UI тестов. Дальше препрод и прод. Тесты на прод не идут, так как нет смысла.

#4

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

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

Бранчевать код тестов вместе с кодом приложения смысла нет, если тесты не запускаются на каждой стадии, а гоняются на одной ветке (develop, например).

На прод имеет смысл деплоить те тесты, которые именно там должны запускаться. Например, для проверки жизнеспособности приложения. Иначе нечего засорять продакшен имхо

#5

App repo: dev / qa branch <-> forks <-> feature / bugfix branches.
Automation repo: master branch <-> forks <-> feature / bugfix branches.

Unit / integration tests поставляются вместе с апликейшен кодом.
Функциональные UI тесты живут своей жизнью.

#6

Мы используем Mercurial. У нас несколько репозиториев: для каждого модуля и отдельный реп. для UI тестов.
Unit, API/Integration тесты лежат в каждом модуле.

Branching strategy одинакова для всех:

  1. Есть default branch, с которого релизимся, с него же начинаются все feature branch.
  2. Под конец спринта создается demo branch, в который сливаем все feature.
  3. После demo, если все ОК, то сливаем все в default. Если не ОК :smile: , то делаем back-out непринятой feature и потом сливаем остальное в default.

Нагляднее на картинке:

1 лайк
#7

Вывод:у каждого свой велик

1 лайк