Как структурировать VCS с несколькими зависимыми проектами

Question

Я уверен, что это распространенная проблема, которую другие уже решали раньше, поэтому я призываю других разработчиков / руководителей проектов к помощи за помощью.

У меня есть несколько проектов:

• Применение
• WebApp
• ServerApp
• Dev Utils
• ORM

Все приложения / утилиты зависят от ORM. Когда ORM изменяется, его необходимо скомпилировать, а все приложения необходимо заново скомпилировать и затем развернуть. Прямо сейчас моя структура VCS беспорядочная:

• AppName
  • Магистральные
    • Применение
    • WebApp
    • ServerApp
    • Dev Utils (около 4 папок сейчас, но растет)
    • ORM
  • разблокировка,
    • ProjectName (будь то приложение или WebApp) version.number
  • Филиалы
    • ExperimentName_DevName

В идеале я хотел бы иметь корневую папку для каждого приложения (Application / WebApp / ORM и т. Д.), Каждый из которых имеет свои собственные Trunk / Branches / Releases и т. Д. Для их логического и физического разделения. Я рассуждаю так: из-за того, что над Приложением проделано много работы, и оно выпускается гораздо чаще, каждая ветвь выпуска имеет идентичные копии одних и тех же утилит и т. Д. Кроме того, проверка Trunk на работу всегда означает, что все остальные проекты идут вместе.

Однако разделение означало бы выделение определенных проектов из решений и одновременное изменение любых проектов - больший скачок между 2-3 IDE (особенно при внесении изменений в ORM).

Я думаю об этом, потому что очень скоро я собираю компьютер CI (будьте готовы к вопросам об этом через неделю или около того), и я пытаюсь найти способ автоматического создания релизов / развертывается. Как правило, приложение развертывается только посредством копирования сценариев на сервер, где все рабочие станции запускаются при запуске, но, как я уже говорил, если ORM изменяется / выпускается, все остальные приложения следует пересобрать и развернуть.

(Сегодня я сломал наш веб-сайт и 3 утилиты, потому что я изменил ORM и развернул его с обновленной версией Приложения, но забыл перестроить / развернуть другие приложения с новым ORM - упс.)

Answer 1

Поставь себя на место разработчика. Это не должно быть сложно, потому что звучит так, будто вы один из них :-) Посмотрите на свой макет управления версиями не с архитектурной точки зрения, а с точки зрения удобства использования. Задайте себе вопрос: ежедневно, что мы, как разработчики, делаем с нашим исходным кодом? Подумайте конкретно о вашем взаимодействии с вашей системой VCS и макетами проекта. Вы хотите, чтобы обычные вещи были просто умопомрачительными. Вполне нормально, что к менее распространенным случаям использования будет сложнее добраться, если у вас есть сведения о том, как их выполнять, чтобы, когда (не если!) Люди забыли, они знали, где искать, чтобы напомнить себе, как .

Я видел много макетов VCS, которые пытаются быть архитектурно "идеальными", но в конечном итоге не вызывают никаких хлопот и головных болей с точки зрения повседневного использования. Я не говорю, что они не могут совпасть и хорошо совмещаться, я просто говорю, подумайте об этом с точки зрения пользователей, и пусть это будет вашим руководством.

С точки зрения CI, я бы все еще использовал этот подход. Даже если ваша настройка становится более сложной для определения в выбранном вами CI, вам нужно выполнить ее только один раз. Если макет прост в использовании во время разработки, большая часть настроек CI также должна быть относительно простой. Затем вы просто сосредотачиваетесь на последних битах, которые займут больше времени.

Answer 2

Разделить вашу кодовую базу на разные «проекты» может быть очень сложно. Мы сделали это на каждой отдельно «развертываемой» границе. Включая «платформенный» слой, который является общим / используемым другими, как отдельный проект. Но это не совсем идеально.

Единственное, что я не могу подчеркнуть достаточно, это то, что нужно иметь некоторую форму непрерывной регрессии / тестирования, которая запускается после проверок и до того, как вы на самом деле что-либо развернете. Кроме того, может быть полезен процесс «выпуска», который может даже включать некоторое ручное тестирование, и он определенно предотвратил несколько ситуаций на лице. (Лучше выпустить его на пару дней позже, чем сломать.)

(Извините, что не обратились к вашей проблеме напрямую)