Для разработчиков

Версионирование

Основой для версионирования дизайн-системы служит спецификация Семантическое версионирование.

Версия релиза определяется согласно нашей классификации версионирования.

Примеры изменения версий:

patch обновит версию с 0.0.1 до 0.0.2
minor обновит версию с 0.0.1 до 0.1.0
major обновит версию с 0.0.1 до 1.0.0
prerelease обновит версию с 0.0.1 до 0.0.1-beta.0

Версии релизов

Major

Как правило, задачи содержащие несовместимые изменения (breaking changes). Релизится планово, когда наберется backlog из таких задач.

Minor

Плановые доработки дизайн-системы, которые релизятся по спринтам.

Patch

Быстрые фиксы недочетов minor-релизов.

Prerelease

Бета-версия дизайн-системы для проверки внешней совместимости перед каждым релизом.

Процесс

Конфигурация окружения

Необходимо указать ваш логин и пароль в Jira, а так же номер текущей Sprint доски в .env переменных

JIRA_LOGIN=your_login
JIRA_PASSWORD=your_password
JIRA_CDS_SPRINT_BOARD_ID=398

Стандартные шаги

Переключиться в ветку release.
Влить ветку sprint_CDS-${number} с изменениями.
Запустить команду cds prepublish.
Выбрать версию релиза (patch|minor|major).
Проверить список задач для релиза на соответствие (выводится в консоли из Jira).
Проверить сгенерированную историю изменений и обновление версий компонентов на соответствие с измененными файлами в git.
Если необходимо, внести правки в историю изменений или обновление версий компонентов.
Выполнить команду cds commit --prepublish.
Переключиться в ветку develop
Влить ветку release.
Запустить команду cds publish и выбрать beta.
Убедиться, что beta пакет опубликован в npm.
Проконтролировать на gitlab, что deploy beta завершился успешно.
Проверить новую beta версию на окружении
Переключиться в ветку master
Влить ветку develop.
Запустить команду cds publish и выбрать production.
Убедиться, что пакет опубликован в npm.
Проконтролировать на gitlab, что deploy production завершился успешно.
Проверить новую версию на окружении

Возникновение ошибок

При выполнении этапов релизных команд CLI могут возникнуть ошибки их выполнения. В таком случае процесс завершается, и релиз останавливается.

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

Откатить измененные файлы при релизе можно командой cds rollback.

Повторный релиз

Необходимость повторного релиза может возникнуть в нескольких основных случаях:

Ошибки при запуске локальных тестов.
Ошибки при запуске внешних тестов (beta-версия).
Ошибки сборки файлов.

Основное отличие повторного релиза от обычного релиза в том, что если при первом неудачном релизе была опубликована beta-версия пакета, то при повторном релизе beta-версия будет повышаться как prerelease с постфиксоми и номером пререлизной версии (Например 1.0.0-beta.2).

При повторном релизе версия релизного пакета не должна изменяться.