Структура проекта SVN и стратегия ветвления для нескольких проектов, которые иногда пересекаются
Я пытаюсь придумать надежную структуру репозитория SVN и стратегию ветвления для небольшой команды из четырех человек. У нас есть четыре главных и несколько второстепенных проектов в процессе разработки, и между проектами часто наблюдается частичное совпадение. Наша текущая стратегия абсолютно неэффективна и состоит в том, чтобы каждая из этих папок (приблизительно 15 или около того) находилась в одной версионной папке "ствола". Это означает, что всякий раз, когда мы разветвляемся, мы разветвляем все 15 проектов (требуется около 20 минут, чтобы обновить рабочую копию и развернуть ветку, чтобы представить это в перспективе).
Основная проблема заключается в том, что некоторые проекты перекрываются, и для функции или задачи нередко требуется что-то изменить в проекте A, а также в проекте B (все эти проекты взаимодействуют с одной и той же базой данных и используют одни и те же таблицы базы данных; кроме того, они разделяют бизнес-уровень, так что изменение класса в одном проекте повлияет на другой), поскольку все проекты по сути являются связанными частями одного "зонтичного" приложения. Как пример, для крупных проектов в основном:
- Проект A: сайт электронной коммерции
- Проект B: Внутренняя система выполнения / управления
- Проект C: не брендовая копия сайта переднего плана (то же самое, за исключением стилей CSS и с меньшим количеством функций)
- Проект D: API веб-службы
A и B взаимосвязаны, но B - это приложение "программное обеспечение как услуга" (мы выступаем в качестве нашего собственного клиента), в котором C является клиентом (A служит интерфейсом для нашей собственной компании, поскольку C по существу А с меньшими возможностями и без специфических для компании деталей). К D обращаются только клиенты, но моя конечная цель - чтобы все A, B и C использовали функциональные возможности D через веб-сервисы (в основном, едим нашу собачью еду).
Мы только что решили использовать трехнедельную стратегию развертывания (т.е. мы производим производственное развертывание каждые три недели), и наша текущая стратегия SVN громоздка и делает ветвление чрезвычайно болезненным.
Если несколько проектов перекрываются, имеет ли смысл хранить их все в одной папке проекта с форматом branch /tags/trunks или мы должны рассматривать их как отдельные проекты? Может быть, объединить некоторые из них, например, имея внешний интерфейс / бэкэнд SaaS, с нашим отдельным сайтом и веб-сервисом, которые разделены?
Любые предложения или советы от людей, вовлеченных в подобные проекты, будут отличными.
2 ответа
Это звучит так же, как проекты в моей компании. У нас та же проблема, мы молча отказались от использования одной и той же базы кода для всего и разделили все на отдельные проекты, потому что таким способом было легче управлять. Если возможно, то, что вы можете сделать, это также создать отдельные проекты для общего кода, который у вас есть, а затем ссылаться на библиотеки из этих проектов во всех других ваших проектах. Я сделал эту последнюю вещь в моей последней компании, и она работает. Это просто означает, что вы должны не забыть скопировать последнюю DLL в ваш текущий проект, если вы обновите общий код.
Я бы попробовал что-то вроде этого:
D - Сделайте это отдельным репо. Включите в другие репозитории, где это необходимо, используя svn:externals.
Б - Сделайте это отдельным репо. Включите в другие репозитории, где это необходимо, используя svn:externals.
A - Сделайте это отдельным репо, и это может быть сундук.
C - Используйте тот же репо, что и A, но сделайте это своей собственной веткой. Любые функции из транка, которые вы хотите предоставить клиентам, вы сливаете в эту ветку из транка.