Практический DevOps # 2: публикация в npm с автоматическим управлением версиями

Управление опубликованными модулями npm может быть проблемой. Даже в конвейере CI / CD позаботиться о правильном семантическом управлении версиями непросто. Либо это? Что ж, есть инструмент, который может это сделать, с множеством других приятных функций. Я собираюсь показать вам, как вы можете использовать semantic-release, чтобы сделать ваши npm-релизы легкими и автоматическими.

Шаги:

  1. Создать репозиторий GitLab
  2. Зарегистрируйте учетную запись npm (если у вас ее еще нет)
  3. Создать проект npm
  4. Настройте конвейер GitLab
  5. Зафиксируйте свой код

1. Создайте репозиторий GitLab

Создадим пустой репозиторий GitLab. Если у вас еще нет аккаунта GitLab, зарегистрируйте его.

GitLab предоставляет мощный инструмент для создания конвейеров для вашего проекта. Самое главное, что к нему прилагается отличная документация, и это бесплатно!

Создать репозиторий GitLab довольно просто. Вам просто нужно нажать зеленую кнопку Новый проект в правом верхнем углу, дать ему красивое имя, а затем нажать зеленую кнопку Создать проект.

Нажав на синюю кнопку клонирования, вы можете клонировать репозиторий, выполнив команду git clone и вставив свой адрес (HTTPS или SSH) в ее конец.

2. Зарегистрируйте учетную запись nmp

Чтобы опубликовать ваш код в npm, нам понадобится учетная запись npmjs. Если у вас его еще нет, вы можете создать его здесь.

3. Создайте проект npm.

Теперь, когда у нас есть пустой проект, мы готовы добавить несколько файлов.

Давайте будем простыми! Мы создадим файл main.js, который будет простым консольным журналом. Код JS на самом деле не требуется, но его полезно проверить в дальнейшем. При этом:

Теперь о package.json. Это центральная часть любого проекта npm, но мы также сделаем его простым. В качестве имени мы должны выбрать что-то глобально уникальное в реестре npm, поэтому постарайтесь выбрать что-нибудь уникальное. (В противном случае вы увидите очень неприятную и вводящую в заблуждение ошибку аутентификации 403 от npm publish.)

Помимо обычной информации, единственное, что нам конкретно нужно для семантического выпуска, - это ключ «release» в нашем .json. Это ключ, который содержит всю информацию о нашем процессе выпуска:

Давайте посмотрим поближе, прежде чем продолжить:

Установив атрибут «ветвь», процесс публикации будет запускаться только для тех коммитов, которые отправлены в основную ветку или объединены с ней.

В плагинах у нас есть:

@ semantic-release / commit-analyzer, как следует из названия, анализирует наши коммиты и на основании сообщения о фиксации решает, запускается ли выпуск. Если это так, он также решает, является ли это незначительным, серьезным или критическим изменением. Затем он соответствующим образом изменит номер нашей версии, просмотрев наши предыдущие теги.

@ semantic-release / release-notes-generator собирается для нас составить примечание к выпуску, которое включает в себя коммиты, влияющие на выпуск.

@ semantic-release / npm отвечает за взаимодействие с реестром npm.

@ semantic-release / gitlab получит всю информацию, необходимую для наших плагинов, после завершения процесса он пометит нашу фиксацию в репозитории соответствующей версией и загрузит примечания к выпуску.

Давайте сделаем нашу первую фиксацию. Нам нужно вручную пометить этот коммит номером версии. Это необходимо для семантического выпуска, потому что ему нужна база, на основе которой он может рассчитывать номера будущих версий. У нас есть версия 1.0.0 в нашем package.json, поэтому этот тег также будет v1.0.0:

4. Настройка нашего конвейера

Каждый раз, когда мы нажимаем на GitLab, он ищет файл .gitlab-ci.yml в репозитории (по умолчанию). Этот файл .yml описывает, какие команды интерфейса командной строки будут выполняться в нашем конвейере. Возьмем такой пример:

Здесь мы выбрали образ докера, в котором хотим запускать наши команды. Мы выбрали образ alpine linux с узлом и npm предустановлен, поэтому нам не нужно об этом заботиться.

Проблема в том, что для семантического выпуска также потребуется git, но он не установлен в этом образе. Думайте о первой строке before_script как об альпийской версии простого apt-get в Ubuntu.

Прежде чем запускать semantic-release, мы просто берем уже упомянутый плагин gitlab, и все готово (он не включен в пакет semantic-release)! Наконец, выполняя команду npx, мы в основном устанавливаем и запускаем модуль npm semantic-release, так что ничего особенного в этом нет.

Мы также можем настроить конвейер для выполнения только в главной ветви. Это отличается от атрибута в нашем файле package.json. Прямо сейчас, если у нас есть push в любую ветку, кроме master, конвейер даже не запустится. В противном случае он будет запускать семантический выпуск, но это не будет продолжаться с публикацией.

Вы можете спросить: как семантический релиз узнает, где опубликовать наш пакет? И как он может пометить наши коммиты и добавить примечания к выпуску в наш репозиторий?

Что ж, это самый последний шаг, так что давайте продолжим!

Для этого мы должны добавить в наш конвейер две переменные среды. NPM_TOKEN и GITLAB_TOKEN. Установить их в GitLab очень просто, просто откройте репозиторий и перейдите в Настройки - ›CI / CD -› Переменные. Мы собираемся сделать это примерно так:

Получить их тоже не так уж сложно. Для NPM_TOKEN нам нужно только вернуться в нашу учетную запись npm на npmjs.com. Нажав на изображение своего профиля, вы увидите меню Токены. Здесь нам просто нужно перейти в Создать новый токен. Уровень доступа должен быть Чтение и публикация. Просто вставьте токен как значение NPM_TOKEN в GitLab.

Теперь перейдите на GitLab. Точно так же мы найдем эту опцию под нашим аватаром. Нам нужно зайти в Настройки - ›Токены доступа. В разделе Области необходим только api, поэтому достаточно выбрать его. Копируя токен в нашу GITLAB_TOKEN переменную окружения, мы настроены!

5. Код фиксации

Если мы сейчас отправим коммит с помощью обычного сообщения о коммите, скорее всего, ничего не произойдет. Конвейер будет запущен, семантический выпуск будет проверять коммиты, и мы получим сообщение «Коммит не должен запускать выпуск». Это почему?

Ну, по умолчанию, semantic-release полагается на Соглашения о сообщениях Angular Commit. Этот формат позволяет семантическому выпуску определить, какой выпуск должен запускаться. Вот некоторые примеры:

Измените сообщение журнала консоли на «Hello 1.1.0!» и нажмите следующую фиксацию:

После того, как мы нажмем, мы сможем наблюдать за нашим конвейером в GitLab. Когда это будет сделано, мы сможем проверить наши опубликованные npm на npmjs.com. Semantic-release также пометил нашу фиксацию новым номером версии 1.1.0 при загрузке соответствующих примечаний к выпуску. Аккуратно, правда? Нам не пришлось добавлять теги или публиковать вручную, все происходило автоматически.

Хотите еще немного погрузиться? Мы можем удалить весь прогресс публикации и использовать его, чтобы просто пометить наши выпуски в нашем репозитории. Мы можем использовать GitHub или даже публиковать образы Docker в Docker Hub! Анализатор коммитов тоже можно настроить, если вам не нравятся соглашения о сообщениях о коммитах в Angular.

Заключительные примечания

В Code Factory мы фокусируемся на устойчивых, возобновляемых решениях, которые помогают клиентам разрабатывать и улучшать свои системы. Если вы хотите сделать что-то подобное или вашей компании нужна помощь, не стесняйтесь обращаться к нам по электронной почте или в Instagram:

привет [o] codefactory.hu
https://www.instagram.com/codefactoryhu/

Вы можете посетить наш сайт
https://codefactory.hu