Версии программного обеспечения в крупномасштабных системах

Question

Моя компания разрабатывает систему на 10 лет. Эта система имеет 15 подсистем, которые почти независимы (они могут использовать одни и те же библиотеки или пакеты или базы данных), и эти подсистемы создаются локально в отдельных командах, также разработана основная простая система для чтения конфигураций подсистем и создания страницы с меню и подменю из конфигов (с ярлыками). Продукт нашей компании является exe этой основной системы.

К сожалению, мы не используем стандартные номера версий в нашей компании. Теперь мы решили создать стандарт в компании, и я нашел Semantic Versioning удовлетворительным стандартом, но у меня есть некоторые вопросы в нашем случае: Как изменения в версии подсистемы увеличивают основную версию системы? Часто, даже после существенных изменений в подсистеме, код основной системы остается незатронутым. Я думаю, что изменения в основной системе должны определять номер версии этой системы, но в этом случае это не имеет смысла. Есть ли какое-либо решение для управления версиями больших приложений, состоящих из нескольких подсистем?

Answer 1

Вы дали ссылку на MAJOR.MINOR.PATCH, и увеличивает
мажорной версии, когда вы делаете несовместимые изменения API,
минорной версии при добавлении функциональности в обратной совместимости образом,
патча версии, когда вы сделать исправления ошибок с обратной совместимостью
Любые изменения в подсистеме могут сделать основную систему несовместимой: слишком много для отслеживания.
Каждая подсистема должна использовать свою собственную версию. В основной системе вы должны иметь обзор зависимостей и собственного управления версиями.
Вы можете управлять этим по-разному. Один из способов - использовать файлы Maven и pom.xml. Другой способ - использовать конфигурационный файл с разными версиями.
Каждая команда может самостоятельно разрабатывать собственный код и назначать семантические версии.
Возможно, в какой-то день вы поместите общие библиотеки, пакеты и базы данных в репозиторий, и все команды могут ссылаться на них со своим собственным pom.xml.
Вы так гибки. Возможно, вы захотите сделать вторую основную систему (для лучших клиентов или для бесплатных учетных записей?) И можете изменить pom.xml, включая/исключая подсистемы. Вторая основная система будет иметь собственное управление версиями.

Answer 2

От SemVer FAQ:

Что я должен делать, если я обновлю свои собственные зависимости без изменения общественного API?

Это считается совместимым, поскольку оно не влияет на общедоступный API. Программное обеспечение, которое явно зависит от тех же зависимостей, что и ваш пакет, должно иметь свои собственные спецификации зависимостей, и автор заметит любые конфликты. Определение того, является ли изменение уровнем патча или модификацией незначительного уровня, зависит от того, обновили ли вы свои зависимости, чтобы исправить ошибку или ввести новую функциональность. Обычно я ожидаю дополнительный код для последнего экземпляра, и в этом случае это, очевидно, незначительный прирост.

Я бы применил это к вашему сценарию следующим образом: Если ваше основное приложение принимает обновления зависимых подсистем, не внося существенных изменений в себя, оно должно увеличить либо незначительную, либо версию патча. Вам не нужно увеличивать основную версию, поскольку ее собственный публичный API по-прежнему считается совместимым.

Если основное приложение использует новые функции, добавленные в подсистемы, это должно быть незначительное увеличение версии.

В противном случае это должно быть увеличение версии патча.

Answer 3

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

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

Сохранение идеи SemVer, если что-то может привести к несовместимым изменениям, тогда выработка самого высокого изменения может иметь смысл. Т.е., одновременно обновляя 5 подсистем, 4 - обновления патчей, а один - минор - вы обновляете только малую версию основной системы (и помещаете их в одно единственное изменение). То же самое с серьезными изменениями и т. Д.

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

Что-то, что вы должны помнить, это то, что вам не обязательно следовать SemVer - последовательность - это ключ к чему-то подобному - так что вы может обновить уровень исправления для того, когда изменения подсистемы будут объединены и никогда не будут сброшены, при обновлении младшей и основной версий только для основной системы. (Есть несколько проектов с открытым исходным кодом, которые работают таким образом, я просто не могу вспомнить, какие из них были у меня в голове).

Не уверен, что это будет полезно, но вы можете посмотреть некоторые из пакетов nodejs и как они обновляют свои версии с разными версиями зависимостей - все они включают в себя список того, что они используют в файле package.json с версия, указанная в определенном формате (т. е. точно xyz или> xyz и т. д. - https://docs.npmjs.com/files/package.json#dependencies)