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

Question

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

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

Answer 1

Вы дали ссылку на MAJOR.MINOR.PATCH и увеличиваете
ОСНОВНАЯ версия, когда вы делаете несовместимые изменения API,
Версия MINOR, когда вы добавляете функциональность обратно-совместимым способом,
Версия PATCH, когда вы делаете обратно совместимые исправления ошибок
Любое изменение в подсистеме может сделать главную систему несовместимой: слишком много, чтобы отслеживать.
Каждая подсистема должна использовать свою версию. В основной системе у вас должен быть обзор зависимостей и собственное управление версиями.
Вы можете управлять этим по-разному. Одним из способов будет использование файлов 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)