Всем привет!
Всегда было интересно, что такое версии продукта и как ими управлять? Как автоматизировать управление версиями разработки? Прошу под кат.
Меня зовут Роман. Я разработчик в очень интересной компании Softeq, где каждый человек — вдохновитель.
При разработке различных инструментов я впал в размышления о том, всем ли разработчикам известно, что же такое версия, какой смысл она несет и как ей управлять при разработке. Итак, давайте рассмотрим, что же такое версионирование.
Версионирование — разработка и управление несколькими выпусками продукта, которые имеют тот же общий функционал, но усовершенствованы, модернизированы либо индивидуализированы.
Коротко, версия говорит об изменении продукта. Как версия говорит об изменении продукта?
Давайте назовем систему упорядочивания символов для обозначения версии продукта — схемой версионирования. Различные схемы версионирования были созданы для отслеживания версий различного программного обеспечения.
Схем версионирования много, но мы сталкиваемся с Семантическим версионированием (Semantic Versioning) каждый день. Для Семантического версионирования характерно то, что номера версий и то, как они меняются, передают смысл содержания исходного кода и какие модификации были применены от одной версии к другой.
Рассмотрим, каким образом формируется номер Семантической версии.
Давайте представим, что у нас имеется проект в разработке. Главная задача проекта — управление построением библиотеки. Проект позволяет производить заказ материалов для построения здания, контролировать этапы построения библиотеки. В настоящее время спроектирована архитектура приложения, произведена реализация базовых задач. При тестировании функционала заказа материалов для построения здания библиотеки обнаруживается ошибка, bug. Производится исправление ошибки и повышается Patch версия проекта.
У заказчика возникла идея о необходимости внедрить анализ маркетинговой информации в проект. Разработчики искусно и быстро спроектировали сервисы анализа данных, интегрировали сервисы с актуальной архитектурой. Произведено добавление новой функциональности проекта, которая не нарушает обратной совместимости. Повысилась Minor версия проекта.
Проект был успешно реализован. Через некоторое время у заказчика возникла идея по развитию данной технологии автоматизации бизнеса. В предстоящих планах были совершенно новые сервисы: формирование команды строителей, внутренняя социальная сеть, внутренний обмен документами и прочее. Разработчики проявили высокую компетентность, и через некоторое время архитектура проекта была спроектирована для решения и новых, и старых задач. Новая архитектура проекта внесла обратно несовместимые изменения. Повысилась Major версия проекта.
Итак, мы представляем, что же такое версии продукта. Но как ими управлять?
Давайте рассмотрим инструмент автоматизации управления версиями.
NPM: https://www.npmjs.com/package/versionings
GitHub: https://github.com/morozow/versionings
Управление версиями производится при помощи командной строки:
Актуальная версия продукта хранится как в ./package.json файле проекта, так и в Git тегах и ветке повышения версии. Автоматизация имеет возможность интеграции с различными сторонними инструментами — управление версиями производится через CLI команду.
Давайте рассмотрим пример повышения версии продукта.
Ведется разработка проекта актуальной версии 2.5.3. Разработка нового сервиса проекта ведется в ветке crm-user-service. Завершилась разработка сервиса, закоммичены все изменения и принято решение о повышении минорной версии:
На этом все :)?
Всем продуктивного настроения и отличного дня!
Всегда было интересно, что такое версии продукта и как ими управлять? Как автоматизировать управление версиями разработки? Прошу под кат.
Меня зовут Роман. Я разработчик в очень интересной компании Softeq, где каждый человек — вдохновитель.
При разработке различных инструментов я впал в размышления о том, всем ли разработчикам известно, что же такое версия, какой смысл она несет и как ей управлять при разработке. Итак, давайте рассмотрим, что же такое версионирование.
Версионирование
Версионирование — разработка и управление несколькими выпусками продукта, которые имеют тот же общий функционал, но усовершенствованы, модернизированы либо индивидуализированы.
Коротко, версия говорит об изменении продукта. Как версия говорит об изменении продукта?
Давайте назовем систему упорядочивания символов для обозначения версии продукта — схемой версионирования. Различные схемы версионирования были созданы для отслеживания версий различного программного обеспечения.
Семантическое версионирование
Схем версионирования много, но мы сталкиваемся с Семантическим версионированием (Semantic Versioning) каждый день. Для Семантического версионирования характерно то, что номера версий и то, как они меняются, передают смысл содержания исходного кода и какие модификации были применены от одной версии к другой.
Рассмотрим, каким образом формируется номер Семантической версии.
Давайте представим, что у нас имеется проект в разработке. Главная задача проекта — управление построением библиотеки. Проект позволяет производить заказ материалов для построения здания, контролировать этапы построения библиотеки. В настоящее время спроектирована архитектура приложения, произведена реализация базовых задач. При тестировании функционала заказа материалов для построения здания библиотеки обнаруживается ошибка, bug. Производится исправление ошибки и повышается Patch версия проекта.
У заказчика возникла идея о необходимости внедрить анализ маркетинговой информации в проект. Разработчики искусно и быстро спроектировали сервисы анализа данных, интегрировали сервисы с актуальной архитектурой. Произведено добавление новой функциональности проекта, которая не нарушает обратной совместимости. Повысилась Minor версия проекта.
Проект был успешно реализован. Через некоторое время у заказчика возникла идея по развитию данной технологии автоматизации бизнеса. В предстоящих планах были совершенно новые сервисы: формирование команды строителей, внутренняя социальная сеть, внутренний обмен документами и прочее. Разработчики проявили высокую компетентность, и через некоторое время архитектура проекта была спроектирована для решения и новых, и старых задач. Новая архитектура проекта внесла обратно несовместимые изменения. Повысилась Major версия проекта.
Полная картина выглядит так, но с ней вы сталкиваетесь редко.
Итак, мы представляем, что же такое версии продукта. Но как ими управлять?
Давайте рассмотрим инструмент автоматизации управления версиями.
Versionings
NPM: https://www.npmjs.com/package/versionings
GitHub: https://github.com/morozow/versionings
Управление версиями производится при помощи командной строки:
versionings --semver=[<semantic-version> | patch | prepatch | minor | preminor | premajor | prerelease | major] --branch=[<version-branch-name> | any-hyphen-case-less-100-characters-string] [--push]
Актуальная версия продукта хранится как в ./package.json файле проекта, так и в Git тегах и ветке повышения версии. Автоматизация имеет возможность интеграции с различными сторонними инструментами — управление версиями производится через CLI команду.
Давайте рассмотрим пример повышения версии продукта.
Действия
Ведется разработка проекта актуальной версии 2.5.3. Разработка нового сервиса проекта ведется в ветке crm-user-service. Завершилась разработка сервиса, закоммичены все изменения и принято решение о повышении минорной версии:
versionings --semver=minor --branch=user-service --push
Результат
- Новая ветка: version/minor/v2.6.0-user-service
- Изменение версии в
./package.json: 2.5.3 -> 2.6.0 - Commit новой версии продукта в веткe version/minor/v2.6.0-user-service
- Push новой ветки с реализацией сервиса и повышенной версии продукта.
- Создание Pull Request для ветки version/minor/v2.6.0-user-service, которая содержит реализацию сервиса и повышенную версию продукта
Замечания
- Инструмент автоматизации ориентирован на Unix среду
- Пример проекта для построения библиотеки является абстрактным, для общего представления версионирования.
На этом все :)?
Всем продуктивного настроения и отличного дня!
Комментарии (2)
staticlab
22.12.2018 18:30Зачем в ветке самостоятельно вычислять номер следующей версии, если это сразу же приведёт к конфликтам даже в небольшой команде, а для однозначного вычисления номера следующей версии достаточно только префикса (major-, minor-, patch- или release-, feature-, fix-)?
lair
Ну и зачем так сложно?
GitVersion. Просто коммитьте ваш код.