Я опишу вам мои группы разработчиков и этапы поставки программного обеспечения:
У нас есть несколько файлов JAR Java, которые содержат логику служб, но совместно используются две основные группы разработчиков, которые посещают различные области бизнеса.Мы оба разделяем использование и ответственность этих сервисов и часто получаем требования для одновременного внесения изменений в одни и те же модули.Когда фаза разработки заканчивается, jar передается в Quality Assurance, а затем в Production, если с ним все в порядке.
Мы используем Subversion (недавно перенесенный из CVS) и создаем новую ветвь для каждого требования, полученного таким образом, чтобы одновременноразработки для одной банки не влияют друг на друга.Проблема в том, что эти две (или более) параллельные разработки идут в QA, и они попадают в очередь для тестирования.Когда одно из этих требований переходит в фазу производства, оно сливается с основной корневой веткой, а другие, работающие над изменениями для того же jar-файла, должны быть уведомлены, чтобы обновить свои ветви новой производственной версией, поэтому, когда они переходят в QA / Production, они надеваютне отменять недавние изменения.
В заключение я хочу знать, правильно ли я использую управление версиями, использую ли я наиболее подходящий вариант управления версиями (Subversion) для моих параллельных разработок и есть лилучший способ ветвления / объединения веток, используемый в параллельных разработках.