Я работал над серией приложений с соответствующими функциональными возможностями, причем каждое приложение доставлялось для разных клиентов. Приложения имеют значительный набор общих функций, но есть некоторые функции, уникальные для требований каждого клиента, которые не могут быть предоставлены другим.
Поскольку все версии, принадлежащие нашим клиентам (A1, B2, A3), до сих пор финансировались и разрабатывались отдельно и последовательно в каждом случае, мы просто сделали снимок исходного кода клиентов, поместили его в новый репозиторий SVN и запустили вносить изменения оттуда. До сих пор у нас все получалось, но в будущем ожидается рост числа клиентов, и мы планируем внедрить некоторые улучшения из приложения клиента A3 в новую версию для A1, и наша текущая настройка не останется управляемой в рамках нашего текущего процесса. .
То, что я ищу, - это информация о том, как такого рода вещи были сделаны в другом месте, и что было бы для нас наилучшим способом. Я опишу свои мысли о том, как мы поступим, и расскажу о своих проблемах, которые у меня есть, и буду ждать отзывов.
Мы предполагаем, что наши клиенты будут разделены на две основные группы на основе некоторых различий в возможностях высокого уровня. Мой префикс наших идентификаторов клиентов с A и B отражает это; Версии программного обеспечения A1 и A3 имеют гораздо больше общего, чем версии B2. В настоящее время мы не ожидаем, что будет добавлена категория C, но не можем исключать, что она изменится через несколько лет.
Наша основная идея состоит в том, чтобы разделить общие части функциональных возможностей (классы внутренних и выигрышных форм) на общие базовые библиотеки для клиентов типа A и B; а затем наследовать общие классы и реализовывать специфичные для клиента функции для каждой версии в отдельном решении. У нас также может быть общая библиотека верхнего уровня для вещей, совместно используемых как с A, так и с B, хотя между A и B достаточно различий, и я обеспокоен тем, что в конечном итоге мы переопределим достаточно методов, которые в конечном итоге только добавят сложности ситуация.
Причина, по которой я думаю, что мне нужно поместить каждое клиентское приложение в отдельное решение вместо того, чтобы иметь единственное решение и просто выбрать, какое клиентское приложение для запуска, заключается в нескольких причинах:
Первое - это то, что из-за NDA для конкретных клиентов у нас, скорее всего, появятся новые разработчики, которым не будет предоставлен доступ к приложениям, сделанным ранее, потому что без их работы над приложением клиента X они не смогут соответствовать внешним требованиям. навязанная необходимость знать требование для утверждения NDA.
Во-вторых, поскольку мы работаем непосредственно с деньгами конкретных клиентов, мы не можем вносить изменения в функциональные возможности общих библиотек (например, перемещать что-то от клиента к основной или другой версии), а затем обновлять каждое приложение для конкретного клиента. продолжить работу с новым ядром. Это ограничение является большой частью того, почему мы изначально придерживались концепции независимо поддерживаемых баз кода, и может сделать проверку правильности того, где мы разделяем общие и специфические для клиента функциональные возможности, проблемой на договорном уровне.
Третий относится ко второму. По соображениям безопасности, если клиент X не может иметь функцию Y, то приложение X не может иметь методы для реализации Y в общей библиотеке, даже если приложение X не имеет никакого способа вызвать метод, потому что, если они достаточно умны, они могут сделать обратное инженеры пишут свой собственный интерфейс, который находится поверх общей библиотеки.
Изменить: Этот вопрос, кажется, в основном умер здесь, но я получил приличную дискуссию на другом сайте.