Как автоматически увеличить версию веб-приложения в соответствии с семантической версией?

Question

Мы собираемся использовать Semantic Versioning для наших веб-приложений, это выглядит очень красиво. Теперь Дженкинс используется в качестве инструмента CI/CD. Мы хотим использовать Octopus Deploy в качестве хранилища артефактов и инструмента для компакт-дисков, а также для быстрого повторного развертывания / отката и других функций конфигурации.

Для Octopus требуются пакеты с конкретной версией (например, 1.2.4). Поэтому нам также необходимо строгое управление версиями для наших веб-приложений. В противном случае, как определить, какая версия была развернута и есть ошибки.

Описанное здесь решение не прозрачно и не полностью соответствует семантическому версионированию:

[assembly: AssemblyVersion("1.0.*")]

Потому что версия патча должна увеличиваться один за другим от 0, а не от "случайного" числа, и сбрасывается после незначительного приращения.

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

• Ручное увеличение перед фиксацией - неудобно и сопряжено с риском.
• Автоинкремент с хуков SVN/Git перед фиксацией - требует настройки каждой рабочей станции.
• Автоинкремент от CI tool и commit - создает круговую зависимость с CI-мониторингом изменений в репозитории.

Есть ли другие способы реализовать равное управление версиями, как в репозитории, так и в пакетах для веб-приложения? А может это и не нужно?

ОБНОВЛЕНИЕ 2017-02-28: Мы обнаружили, что Jenkins может пропускать коммиты от определенных пользователей или с конкретными сообщениями (в расширенных настройках). Это решает проблему с автоматическим инкрементом из инструмента CI и фиксацией (циклическая зависимость между мониторингом CI и изменениями в хранилище).

Answer 1

В основном разработчики не смогли зафиксировать правильные версии сборки в коде. Скажем, если у вас 40 проектов и 15 разработчиков, то ведение [assembly: AssemblyVersion("1.0.*")] версия всегда будет проблемой.

Я рекомендую вам проверить код и выполнить поиск и замену, чтобы всегда вводить правильные номера сборок, например [Major.Minor.Build]. [Major.Minor] должен приниматься в качестве входных данных и глобально осведомлен о команде, таким образом уменьшая плохую нумерацию dll / номер сборки может положительно увеличиваться и совпадать с номером CI для отслеживания. Номер коммита SVN также можно смешивать с ним.