Как спроектировать процесс разработки и выпуска пакетов npm

NPM
Как спроектировать процесс разработки и выпуска пакетов npm

Недавно библиотека, используемая в компании, была выпущена на частный сервер npm в интрасети. Опубликовать ее относительно просто, но эта библиотека поддерживается несколькими людьми, и существует только один набор частных серверов npm, поэтому производство среда и разработка Используется одна и та же среда, поэтому возникает наше требование: как спроектировать процесс разработки и автоматизированный процесс выпуска пакетов npm. Этот набор процессов мы хотим достичь следующих целей

  1. Поддержка совместной работы команды: когда разработчики отправляют код, другие могут вовремя синхронизироваться с последним кодом.
  2. Способен поддерживать регулярную итерацию и исправление онлайн
  3. Номера версий эталонных пакетов в средах разработки, тестирования и производства одной и той же версии совпадают.
  4. Автоматизированная публикация, сокращение ручного труда

Давайте поговорим о том, как собрать приватный сервер npm и как отправлять пакеты, но это не является предметом этой статьи, поэтому мы кратко представим

сборка приватного сервера npm

В настоящее время наиболее популярными являютсяnexusа такжеVerdaccio,потому чтоVerdaccioЧтобы быть легче, а также удовлетворить наши потребности, поэтому мы выбираем его.VerdaccioКонструкция очень проста, просто используйте конфигурацию по умолчанию.

npm install -g verdaccio
or
yarn global add verdaccio
verdaccio

Таким образом создается частный сервер.

выпуск пакета npm

С частным сервером мы сначала регистрируемся на локальном npm.npm set registry http://localhost:4873Затем добавьте пользователя, если это первый раз, будет создан новый пользователь.npm adduser --registry http://localhost:4873наконец опубликоватьnpm publish

Есть два способа установить номер версии, один из них — ручная модификация.package.jsonсерединаversion

// package.json
{
  "name": "project",
  "version": "1.0.0",
}

Другой черезnpm versionДля изменения номера версии предоставляются следующие параметры

npm version [<newversion> | major | minor | patch | premajor | preminor | prepatch | prerelease [--preid=<prerelease-id>] | from-git]

Подробное объяснение выглядит следующим образом:

newversion：自定义版本号，除了已经发布的版本号，想写啥写啥
major：升级主版本号 1.0.0 -> 2.0.0
minor：升级次版本号 1.0.0 -> 1.1.0
patch：升级补丁号 1.0.0 -> 1.0.1  
premajor：预备主版本
preminor：预备次版本
prerelease：预发布版本

в исполненииnpm versionПосле этого будет сгенерирована новая запись коммита, например, выполнениеnpm version 2.0.0После этого проверьте журнал, вы найдете сообщение фиксации как2.0.0Запись представления , почему создается эта запись? просто потому чтоnpm versionЭта строка команды фактически изменяет версию в package.json и отправляет ее после модификации, поэтому есть эта новая запись об отправке. Если вы хотите настроить запись отправки, вы можете написать такnpm version 2.0.0 -m "Upgrade to %s for reasons"в%sэто исправленный номер версии.

gitlab CI

Мы планируем использовать gitlab CI для автоматического выпуска, а также кратко расскажем о некоторых шагах и элементах конфигурации gitlab CI.

  1. Проект запускает CI и выбирает публичный раннер, если нет, то вы можете получить его только сами.
  2. Новый корневой каталог проекта.gitlab-ci.yml, напишите конфигурацию, подробную конфигурацию можно посмотретьофициальный сайт гитлаб 
# 定义 stages
stages:
  - build

定义 job
job1:
  stage: build
  script:
    - echo 'xxx'
  1. Конфигурация завершена

этап проектирования

Ключевой момент, о котором мы хотим поговорить, здесь, мы познакомим вас с нашими дизайнерскими идеями посредством рисования. Давайте установим некоторые соглашения

отраслевая конвенция

Планирование ветки проекта, задать три ветки

  1. featureРазветвление: регулярная формация
  2. masterФилиал: стабильная ветвь
  3. hotfixВетка: При наличии аварийной модификации эта ветка создается как временная ремонтная ветка, чтобы не влиять на развитие штатных функций

Соглашение о номере версии

Мы используем大版本:小版本:次版本号Таким образом, каждая фиксация в каждой функциональной ветке запускает обновление этого номера версии.Например, номер версии текущей функциональной ветки1.1.5то следующая фиксация будет эскалирована до1.1.6И выпустите npm, младший номер версии итеративно обновляется с помощью обычных требований, например, текущий1.1.8, то завтра будет запущен периодический спрос, то после запуска номер версии будет повышен до1.2.0И опубликовать npm, все нашли1.1.8а также1.2.0Это один и тот же код, да, причина в том, что минорный номер версии соответствует обычной модификации цикла, тогда обновленный1.2.0Это номер версии, используемый в качестве следующего общего требования. Таким образом, этот номер версии соответствует каждой отправке, а дополнительный номер версии соответствует текущему этапу разработки. Мы оба можем инициировать модификацию через CI, нет необходимости С ручным участием , по-прежнему существует большой номер версии. Его можно изменить вручную только в случае основной версии. Вообще говоря, частота обновления большого номера версии относительно низка, и его изменение вручную вполне допустимо.

Вы обнаружите, что каждое представление запускаетnpm version patch & npm publishЭто кажется слишком частым, но чтобы удовлетворить командную работу, ему приходится идти на небольшие уступки. Таким образом, функция этого номера версии здесь не в том, чтобы отличить версию, маленький номер версии действительно используется для различения версии, поэтому, когда мы ссылаемся на этот npm, нам нужно контролировать номер версии таким образом, например

"my-package": "~1.2.0"

Заблокируйте основные и дополнительные номера версий, чтобы наши ссылки были актуальными, независимо от того, сколько коммитов мы сделали во время разработки.

Временная диаграмма

Нарисуйте диаграмму последовательности разработки и выпуска следующим образом.

Диаграмма последовательности процесса разработки

Схема последовательности разработки выглядит следующим образом

开发流程

Диаграмма последовательности процесса выпуска

发布流程

Реализация кодирования

В основном кодирование CI, как показано ниже

# .gitlab-ci.yml
# 定义 stages
stages:
  - publish

# 定义 job
job2:
  stage: publish
  before_script:
    - cd /home/node/MY #进到项目目录
    - git checkout .
    - git checkout $CI_COMMIT_REF_NAME || git checkout -b $CI_COMMIT_REF_NAME
    - git pull -f -X theirs origin $CI_COMMIT_REF_NAME
    - yarn
  script:
    - node publish.js

// publish.js
var shell = require('shelljs');
var git = require('git-last-commit');
var featureBranchName = 'feature-npm';
// 判断文本是否是版本号格式
function checkCommitMessage(subject) {
    return /^\d+.\d+.\d+$/g.test(subject)
}

// 获取最近一次提交，判断是否是版本号格式，若不是，则进行发布，
git.getLastCommit(function(err, commit) {
    console.log(commit);
    const { subject, sanitizedSubject } = commit;
    shell.exec('echo $CI_COMMIT_REF_NAME');

    if (!checkCommitMessage(subject)) {
        if (sanitizedSubject.indexOf(`Merge-branch-${featureBranchName}-into-master`) > -1) {
            shell.exec('git checkout .');
            shell.exec(`git checkout ${featureBranchName} || git checkout -b ${featureBranchName}`);
            shell.exec(`git pull -f -X theirs origin ${featureBranchName}`);
            shell.exec('npm version minor');
            shell.exec('npm publish');
            shell.exec(`git push origin ${featureBranchName}`);
        } else {
            shell.exec('npm version patch');
            shell.exec('npm publish');
            shell.exec('git push origin $CI_COMMIT_REF_NAME');
        }
     }
});


// package.json
"scripts": {
    "test": "echo \"Error: no test specified\" && exit 1",
    "prepublish": "build script"
  },

В скрипте публикации есть функцияcheckCommitMessageОн используется для определения того, имеет ли последнее отправленное сообщение формат номера версии, потому что в конце у нас будет операция отправки, и CI будет снова запущен после отправки, поэтому, чтобы предотвратить бесконечный цикл, мы используем отправленное сообщение в качестве основы для запуска CI, поэтому, как только мы придем к стандартизации формата сообщения, я предлагаю следовать этому формату.U ${修改的具体的内容}.

резюме

Это решение не является универсальным, ведь процесс разработки у каждой команды разный, и на данный момент это решение подходит для нашего текущего сценария. Если есть сцена друга, которая соответствует нашей, можете попробовать, если у вас есть план получше, добро пожаловать на общение~

Категории