Основные команды

Суть pvm управлять двумя составляющими – релизами и версиями. По пути обновлять ченжлоги и уведомлять в слак. При этом есть разные процессы делать релизы – можно вручную, можно автоматически. Автоматически процесс тоже может различаться в зависимости от того, где мы храним версии например.

Цель данной главы – показать "кирпичики", из которых можно выстраивать те или иные процессы доставки релизов. А также на практике настроем парочку процессов, в котором релизы будут происходить автоматически по мержу в мастер, без участия человека, и как pvm может нам помочь в этом.

При этом подразумевается использование github flow, с тем дополнением, что мерж в мастер сразу же ведет к релизу пакетов, хотя это и можно перенастроить при желании.

Также предполагается что у вас есть некоторая платформа где вы разрабатываете продукт, которая поддерживает базовые сценарии CI/CD, такие как запуск задач для мерж-реквестов, а также запуск задач для тегов или бранчей.

Давайте теперь перейдем к примеру процесса, где мерж автоматически приводит к новому релизу с релизным коммитом.

Flow с релизным коммитом и тегом

пример сценария релиза по мержу в мастер

В данном случае сценарий выглядит так:

1. Создаем мерж-реквест
2. Запускается CI-задача в которой pvm говорит, какие пакеты обновятся и как, если замержить этот мерж-реквест
3. На мерж в мастер запускается pvm update, который уже на самом деле обновляет пакеты и создает новый релизный коммит и тег
4. На релизный тег запускается CI-задача, которая публикует обновленные пакеты и сообщает об этом в slack-канал

Т.е. по сути мы получаем такой flow: create -> review -> merge & update -> publish.

Важно понимать, pvm нас никак не ограничивает в настройке процесса доставки релизов, он предоставляет "кирпичики" или команды, с помощью которых уже можно выстроить тот или иной процесс доставки релизов. Например можно не создавать релизный коммит и обойтись только релизным тегом.

Рассмотрим ключевые "кирпичики" с данной схемы.

mark-pr

pvm mark-pr – позволяет понять, что произойдет с пакетами если мы выполним команду pvm update. Команда pvm mark-pr добавит в мерж-реквест комментарий с подробной таблицей, какие пакеты будут обновлены и как:

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

update

pvm update – команда, которая делают всю основную работу – обновляет версии, ченжлоги и фиксирует эти изменения в репозитории в виде релиза. Делает она это на основе изменений, которые произошли с момента последнего релиза.

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

При этом команда pvm update заточена под работу в CI/CD окружении для доставки изменений в центральное хранилище кода – она создает и пушит теги и коммиты либо через Platform API, либо через git. Подробнее эту команду и вообще процесс обновления и как на него можно влиять мы рассмотрим в отдельной [главе].

Если же вы хотите произвести обновление локально, достаточно добавить подкоманду local в начало:

yarn pvm local update

publish

pvm publish – команда публикует все пакеты, которые поменяли свою версию в используемый registry, а также оповещает о публикации в мессенджеры если задан токен PVM_SLACK_TOKEN или PVM_MATTERMOST_TOKEN и PVM_MATTERMOST_URL через переменные окружения. Также понадобится настройка notifications.clients_common_config в конфиге pvm, например такая:

[notifications.clients_common_config]
channel = '#temp'
author = { name = 'pvm minion', avatarEmoji = ':deciduous_tree:' }

Подробно рассмотрим публикацию в отдельной [главе], сейчас остановимся на этом и перейдем к другому, альтернативному процессу релиза.

Flow только с релизным тегом

В предыдущем flow мы использовали релизный коммит для того, чтобы фиксировать изменения версий пакетов в исходном коде и обновлять ченжлоги. Однако если у нас нет потребности создавать коммит для доставки изменений с релизом в основную ветку, можно обойтись и без него:

pvm add-tag

В данном случае используется команда pvm add-tag, которая не создает новый коммит, а только подбирает новую версию тега и выставляет ее на мерж коммит в основной ветке и заканчивает свою работу на этом.

pvm update

Такой кейс с pvm update возможен либо если явно указать что не нужно делать коммит с помощью настройки release.tag_only равной true. Либо в случае если команде pvm update нечего доставлять в основную ветку:

• Ченжлоги либо отключены, либо настроены на хранение в другом месте (про хранение артефактов подробнее поговорим в главе [процесс обновления]).
• Артефакт списка релизов отключен, либо также настроен на хренение в другом месте.
• Не было других изменений, которые pvm настроен удалять с помощью релизного коммита.

Далее происходит публикация пакетов в задаче запущенной на релизном теге. Pvm перед публикацией будет подменять версии пакетов на версию указанную в релизном теге. Данное поведение настраивается явно в конфиге pvm:

[versioning]
source = 'tag'

Итоги

В pvm есть 4 основных команды для построения процессов обновления пакетов. Одна для ревью, пара для фиксации релиза и одна для публикации. В следующей части главы рассмотрим примеры интеграционных файлов, реализующих автоматический процесс доставки, для конкретных платформ.