Subversion - Асинхронный цикл разработки ... два ствола?

Question

В настоящее время на нашем предприятии возникла ситуация, которая, как мне кажется, не очень распространена, или, по крайней мере, я не нашел подобного случая в Интернете. Моя проблема в том, что у нас есть программное обеспечение, которое может развиваться более чем по одному требованию, и оба не обязательно будут совпадать по дате выпуска.

У нас есть цикл разработки, в котором все программное обеспечение разрабатывается в среде "DEV", а затем обрабатывается в SQA, чтобы его можно было протестировать в среде "LAB"; если все работает нормально, то это программное обеспечение перемещается в среду «PROD». Проблема, с которой я здесь сталкиваюсь, заключается в том, что я не могу использовать одну магистраль, и я не понимаю, как может работать одна ветвь.

Например, допустим, у меня есть требования A и B, одно из которых будет выпущено сегодня, а другое через неделю. Оба достигли среды LAB, но сегодняшний выпуск среды PROD должен содержать только A, так как B еще не нужен нашим бизнес-пользователям (и он не может быть выпущен досрочно, потому что это может привести к ошибкам в других системах). Оба требования были разработаны в разных отраслях (они отвечают различным потребностям). В этом случае моя проблема заключается в том, что у меня не может быть одной магистрали, где разработчики могут объединиться, чтобы увидеть оба изменения в среде «DEV», а затем использовать эту же магистраль для подачи в среду «LAB», поскольку исходный код еще не запланирован. для выпуска.

Думаю, я должен также упомянуть, что создание отдельной среды разработки для каждой ветви невозможно, поскольку это программное обеспечение основано на PL / SQL (Oracle), а наша текущая тестовая база данных имеет размер около 350 МБ, поэтому иметь другую базу данных для каждое требование было бы довольно дорогим и трудным в управлении.

Любое предложение или подобный опыт будут оценены.

Привет

Answer 1

Я бы предложил следующее:

• Продукт-1 /
  • багажник /
  • филиалы /
    • особенность-ветви /
      • REQ-A /
      • REQ-B / * * 1014
    • до лаборатории /
    • лаборатория /
    • прод /

Разработчики начинают разрабатывать новые требования в соответствующей функциональной ветке. Затем вы реинтегрируете ветви функций, которые было решено включить в среду LAB / pre-lab /, где вы можете интегрировать изменения для новых функций и исправлений из trunk /.

Как только вы узнаете, что это работает (это займет некоторое время, как любой шаг интеграции, объединяющий несколько источников), вы объединяете все изменения от pre-lab / до lab /. Когда вы ограничиваете себя слиянием только из pre-lab / to lab /, это слияние всегда будет чистым, т.е. одним щелчком мыши.

В trunk / вы можете объединить все функциональные ветви и исправления ошибок, но в зависимости от структуры вашего проекта и процесса разработки программного обеспечения это может потребовать дальнейшего обсуждения.

Обязательно используйте Subversion 1.5, так как это слияние затеряет вас в аду с более старыми версиями.

Answer 2

Судя по вашему последнему абзацу, у вас довольно много соленья. Я полагаю, что для этого лучше всего разветвляться на каждую функцию и объединять функции в ствол по мере необходимости / выпуска. Я действительно не знаю, есть ли вторая лучшая практика для улучшения вашей ситуации (но я не настолько умен) ...

Answer 3

В большинстве случаев вам нужно протестировать результирующее приложение с включенными и отключенными функциями, чтобы вы могли выбрать, что включать или отключать во время выпуска.

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

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

В этом случае релиз должен быть тем, что будет тестироваться, а не тем, что собирается в производство. То, что будет идти в производство, является проверенным выпуском. На этом этапе это просто вопрос создания ветки для каждого выпуска или функции и объединения того, что нужно.

Операция слияния не должна быть для всех. Если коммиты сделаны хорошо, вы сможете легко объединить нужные вам функции (комиты и / или файлы) между ветками. Также отметим, что SVN имеет возможность сохранять историю объединенных веток только с 1.5 /

Answer 4

Мне кажется, что вы могли бы выиграть от использования распределенной VCS (git, mercurial, bazaar и т.