Мы собираемся начать создание прототипа нового приложения, которое будет совместно использовать некоторые существующие сборки инфраструктуры с существующим приложением, а также задействовать значительный поднабор существующей модели домена.
Части модели домена, скорее всего, претерпятнекоторые серьезные изменения для этого нового приложения и конечный результат всего этого после того, как новое приложение будет полностью определено и готово к запуску, состоит в том, что мы хотели бы воссоединить модели двух приложений (а также поделитьсябаза данных, функциональность ссылок и т. д.), но на время разработки, создания прототипов и т. д. мы будем использовать отдельную базу данных, чтобы мы могли что-то менять, не беспокоясь о влиянии на разработку или использование существующего приложения.Поскольку это прототип, будет довольно длинное окно, в течение которого могут произойти серьезные изменения или реструктуризация, поскольку эксперименты по управлению продуктами с различными рабочими процессами, различные клиентские базы опрошены, и мы стараемся не отставать.
Мы имеемуже создали ветку Subversion, чтобы не влиять на параллельную разработку на зрелом приложении, и теперь они играют с двумя возможными способами продвижения вперед:
Использование ветви svn в качестве единственногоМеханизм разделения.Внесите наши изменения в существующие модели домена и оцените их влияние на существующее приложение (и внесите необходимые изменения в ProjectA), когда мы установим, что наша долгосрочная боковая ветвь достаточно стабильна для повторного входа в транк.
«Разветвить» общий код (временно): скопировать ProjectA.Entities в NewProject.Entities и обработать весь код NewProject как автономный.Когда все возмущения вокруг модели стихли, и мы чувствуем себя удовлетворенными, вручную повторно интегрируйте изменения (как гранулированные или стремительные, насколько это оправдано) обратно в ProjectA.Entities, обновляя ProjectA для использования улучшенных моделей на каждом этапе (это может потребоватьместо до или после слияния Subversion).Слияние Subversion не будет обрабатывать рекомбинацию каких-либо серьезных изменений здесь.Примечание: метод "fork" применяется только к коду, для которого мы видим значительные изменения в хранилище, и чья модификация сломает ProjectA - например, общую инфраструктуру, мы просто изменим на месте (в нашей ветви) и позволим слиянию разобраться.
Развитие сложно, иди за покупками.
Естественно, что после того, как мы не пришли к соглашению, мы передаем его оракулу.силы, которая ТАК.Есть ли опыт использования этих методов, болевые точки, на которые стоит обратить внимание, что-то совершенно новое?