Как управлять версиями сборки в сценарии с несколькими модулями / клиентами?

Question

Мне нужны некоторые рекомендации по управлению сборками и версиями и управлению их исходным кодом.

Сначала немного информации о приложении. Приложение представляет собой систему типа ERP, где несколько клиентов могут запускать различные модули; некоторые из них стандартные и / или некоторые из них настроены специально для клиента. Каждый модуль реализует определенную бизнес-функцию или ее вариант. Обоснование заключается в том, что эти модули можно легко заменять / настраивать, не затрагивая другие модули и не требуя перестройки.

Приложение основано на оболочке приложения, ядре приложения и затем загруженных модулях времени выполнения. Все клиенты используют оболочка приложения и ядро, а затем любое количество модулей. В настоящее время у меня около 70+ модулей.

Ядро приложения состоит из 2 сборок. Первыми являются сервисы / бизнес-логика, уровни доступа к данным, объекты данных и т. Д. Во-вторых, все основные формы пользовательского интерфейса, диалогов и т. Д.

Каждый из модулей реализован как отдельная сборка (как проект VS в решении). Каждый из этих проектов ссылается на 2 основных сборок. Эти сборки модулей загружаются во время выполнения при запуске приложения. Таким образом, чтобы изменить модуль, можно просто заменить сборку. Основная оболочка приложения создает экземпляры класса ядра приложения.

Теперь сценарий таков: - Когда я меняю модуль, его сборочная версия сталкивается.

• Когда я изменяю реализацию метода сборки ядра (т.е. не меняю сигнатуры классов), тогда мне не нужно Перестройка зависимых модулей и, следовательно, их версии остаются как есть. Тем не менее, версия сборки ядра получает удар.

• Когда я добавляю свойство или метод к базовому классу, мне также не нужно перестраивать зависимые модули и, следовательно, их версии. оставайся как есть. Опять же, версия сборки ядра получает удар.

• Однако, когда я изменяю сигнатуру базового класса, мне нужно перестроить все зависимые сборки. Должен ли я поднять каждый модуль версия в этом случае?

Контроль версий

Поскольку каждый модуль представляет собой отдельный проект, каждый из них имеет свой корневой элемент в дереве VSS. Так что я должен маркировать каждый модуль узел с версией?

Каков наилучший способ управления зависимостями версий? Excel

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

Буду признателен за любые предложения / комментарии по поводу версий, а также за философию управления этим каталогом модулей

Answer 1

Шаг 1 - Прекратите использовать VSS и используйте реальную систему контроля версий, такую ​​как Subversion, Mercurial или Git, которая позволяет эффективно использовать ветви и теги. Это поможет тонна , когда дело доходит до управления различными настройками и зависимостями.

Шаг 2 - Следуйте рекомендациям Semantic Versioning и делайте это для каждого модуля или элемента с версиями. Это даст другим вашим элементам, которые зависят от конкретного модуля, простой способ определить scope следующую версию одного из их зависимых модулей

Как правило, версия модуля должна изменяться только в соответствии с рекомендациями по семантическому управлению версиями, которые полностью сосредоточены на том, как изменяется внешний API модуля . Таким образом, если версия зависимого модуля изменяется, но нет изменений во внешнем API модуля, с которым мы имеем дело, вы можете изменить номер версии патча (например, 1.12.5 -> 1.12.6)

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