Хорошо, это на самом деле не вопрос VCS, это в первую очередь архитектурная проблема - как вы структурируете и создаете свои приложения таким образом, чтобы вы могли доставлять конкретные варианты использования в каждую больницу по мере необходимости будучи в состоянии, как вы предлагаете, исправлять ошибки в коде commom.
Я думаю, можно с уверенностью заявить, что если вы будете следовать модели, предложенной на вашем изображении, вы не сможете сделать это последовательно и эффективно. В результате вы получите ряд различных, дискретных приложений, которые должны поддерживаться отдельно, даже если они в какой-то момент основаны на общем наборе кода.
Трудно сделать больше, чем хорошие обобщения , но , как я мог бы подумать, было бы что-то вроде следующего:
Во-первых, вам нужно базовое приложение (или набор приложений или набор библиотек приложений), которые станут основой любой поставляемой системы и, следовательно, единым поддерживаемым набором кода (хотя само это ядро может включать внешние библиотеки).
Затем у вас есть ряд опций для ваших пользовательских приложений (для каждого больничного экземпляра), которые вы можете определить доступными функциями несколькими способами:
- В одном крайнем случае по конфигурации - наличие одного приложения, содержащего весь код, и эффективное включение и выключение для каждого отдельного экземпляра.
- С другой стороны, наличие приложения для каждой больницы, которое по существу содержит основной код с настройкой.
Однако существует вероятность того, что, хотя сумма вариантов использования для каждой больницы различна, отдельные случаи использования будут распространены в ряде случаев, поэтому вам необходимо стремиться к модульной системе, то есть к чему-то, что начинается с общего ядра и что может быть расширен и сконфигурирован композицией так же, как и любым другим способом.
Это означает, что вы, вероятно, хотите широко использовать Inversion of Control и Dependency Injection, чтобы предоставить вам гибкость в рамках общей структуры. Вы хотите взглянуть на каркасы расширяемости (я использую .NET, так что я бы посмотрел на Managed Extensibility Framework - MEF), которые позволят вам как-то "собирать" приложение во время выполнения, а не во время компиляции.
Вам также нужно обратить внимание на то, как вы собираетесь развертывать - особенно на то, как вы собираетесь обновлять - ваши приложения, и на данный момент вы правы, вам понадобится как контроль версий, так и вы строите среду правильно.
Как только вы узнаете, как вы собираетесь создавать свое приложение, вы можете взглянуть на свою систему управления версиями - @VonC сразу же говорит, что ключевая особенность - возможность включать код из общих проектов в несколько поставляемых проектов. .
Если бы это был я, сейчас у меня, вероятно, было бы ядро (которое, вероятно, само по себе будет представлять собой несколько проектов / решений), а затем по одному проекту / решению на больницу, но я бы стремился иметь как можно меньше кода в для проектов в отдельных больницах - в идеале достаточно структуры для определения конкретной конфигурации экземпляра и настройки пользовательского интерфейса
В отношении того, что использовать ... если вы магазин Microsoft, то внимательно посмотрите на TFS, выигрыш в производительности от хорошо интегрированной среды может быть значительным.
В остальном (и в любом случае) DVCS (Mercurial, Git, Bazaar и т. Д.), По-моему, приобретает преимущество над более традиционными системами по мере их развития.Я думаю, что SVN является отличным инструментом (я использую его, и он работает), и я думаю, что вам нужен центральный репозиторий для такого рода разработки - не в последнюю очередь потому, что вам нужно где-то, что запускает ваш сервер непрерывной интеграции - однако вы можете достичь того жес DVCS и возможностью делать частые локальные, инкрементные коммиты без «нарушения сборки», а гибкость, которую дает вам DVCS, означает, что если у вас есть выбор сейчас , то это почти наверняка путь(но вам нужно убедиться, что вы внедрили передовой опыт в обеспечении того, чтобы код передавался в ваши основные репозитории на ранних этапах)
Я думаю, что многое еще нужно решить исключительно из вопроса о VCS - но вы не можетеперейдите к этому подробно, пока вы не поймете, как будете структурировать поставленное решение.