Трудно ответить на такой вопрос, и я сомневаюсь, что вы сможете получить что-то лучше, чем «это зависит» и «забрать свой яд», но я постараюсь изо всех сил.
Основные подходы Я могу думать о:
Отдельные базы кода и конвейеры выпуска. Это, кажется, ваш нынешний подход.
- Плюсы:
- независимые релизы - нет ничего удивительного, как выпустить изменение в Канаде, которое другая команда сделала для США
- потенциально более простая база кода - меньше конфигурации, меньше "if (region == 'CANADA') ..."
- независимый контроль качества - гораздо проще автоматизировать тестирование, если вы просто тестируете одну среду
- Минусы:
- Дублирование усилий, как вы уже заметили
Одна база кода, изменяет конфигурацию Ведомый.
- Плюсы:
- внесение изменений в одном месте
- Минусы:
- более высокий шанс у многих разработчиков работая с одним и тем же кодом в одно и то же время
- , вы, скорее всего, получите ужасное 'ifs'
- , разделяющее разделительные конвейеры, что может быть очень сложно. Если у вас есть изменения для Канады, вам нужно протестировать все для США - это может быть значительное количество усилий в зависимости от уровня автоматизации контроля качества и сложности вашего сценария тестирования ios. Кроме того, вы выпускаете США только потому, что кто-то в Канаде хотел изменить цвет кнопки на зеленый? Если вы это сделаете, вы тратите время. Если вы не внесете в этот список потенциально непроверенные изменения для следующего выпуска в США.
- Если у вас появятся другие регионы, этот код быстро становится сложным - многие люди просто добавляют что-то, чтобы заставить их регион работать, и вы заканчиваете с кодом спагетти.
Разделяйте базы кода с помощью общих настраиваемых модулей. Это может содержать все, что вы решите, вряд ли будет отличаться в разных регионах: пакеты Nuget с базовой логикой c, npm пакеты с javascript, стиль интерфейса и т. Д. c.
- Плюсы :
- если все сделано правильно, вы можете получить лучшее из обоих миров - отдельных конвейеров выпуска и отдельной (простой) области, задав c код
- , вы можете внести изменения в общий модуль и принять решение когда / если обновлять каждый регион до последней версии отдельно
- Минусы:
- больше усилий инфраструктуры - вам нужен конвейер выпуска для каждого приложения и один для каждого пакета
- Отладка и понимание упакованного кода при использовании в приложении - сложная задача
- Изменение чего-либо в общем модуле и тестирование его в вашем приложении - это боль - вам нужно go в общий репозиторий, сделать измените, протестируйте его, создайте PR, объедините его, дождитесь сборки и выпуска пакета, обновите приложение ... и затем вы обнаружите, что изменение было неправильным.
Я работал с такими проектами, и всегда есть проблемы - если вы сделаете его сверхконфигурируемым, он станет нечитаемым и чрезмерно усиленным. Если вы делаете это по отдельности, вы должны вносить изменения во многих местах, и поддержание таких вещей, как модульные тесты во многих местах, является кошмаром. Поскольку вы уже начали с подхода 1 и упомянули о приближении других регионов, я бы предложил перейти с вашей текущей стратегии и постепенно абстрагировать общие части в отдельные репозитории (переход к третьему подходу). Я думаю, что наиболее важной частью, которая облегчит такие изменения, является достойный уровень автоматизации тестирования - как для ваших приложений, так и для общих модулей при их создании.
Один совет, который я могу вам дать, - будь прагматиком c. Некоторый уровень дублирования хорош, особенно если альтернативой является сложный механизм правил, который никто не понимает и никто не хочет трогать, потому что он используется везде.
Надеюсь, это поможет, удачи!