Отправка пакетов npm является частым требованием для немного более крупной фабрики, поэтому локально выполните команду версии расчета иnpm publishЭто невозможно. В Metropolis есть отдельная система развертывания, которая автоматически помогает нам в этом.
Сегодня поговорим о базовой вычислительной версии в этой системе развертывания, а также о логике и процессе публикации.
Семантическое управление версиями Semver
Прежде чем мы поговорим о развертывании систем, давайте поговорим о семантическом управлении версиями, потому что я обнаружил, что многие люди до сих пор мало что знают об этой теме.
значение версии
- Менее 1.0.0: бета-версия, указывающая на то, что API библиотеки в настоящее время нестабилен.
- Больше или равно 1.0.0: официальный выпуск
- Версия содержит слова альфа, бета, rc и другие теги, вместе именуемые первой версией, общий формат x.y.z-[тег].[время/метаинформация]
- альфа: внутренняя версия
- бета: общедоступная бета-версия
- rc: предварительная официальная версия
Формат номера версии
Общий формат номера версии — X.Y.Z, а значения следующие:
- X: основной, основной номер версии, который следует изменить при появлении несовместимого API.
- Y: дополнительный, дополнительный номер версии, этот номер версии следует изменить, когда появится новая функция, совместимая с предыдущими версиями.
- Z: патч, патч, этот номер версии следует изменить, когда необходимо исправить ошибку обратной совместимости.
Но эта семантика не высечена на камне. Например, если номер версии бета (когда версия меньше 1.0.0), мы можем изменить семантику на0.minor.patch. Поскольку появление несовместимых API в настоящее время является нормальным явлением, номер основной версии не следует изменять напрямую, но следует изменить номер вспомогательной версии, а изменения версии, вызванные новыми функциями и исправлениями ошибок, должны быть отражены в исправлении.
Правила изменения версии
X.Y.Z должны быть целыми положительными числами без ведущих нулей.
X.Y.Z необходимо сбрасывать меньший номер версии на 0 каждый раз, когда номер версии изменяется. Например, 1.0.2 обновляется до 1.1.0.
Предварительная версия одной и той же версии выпускается несколько раз, просто измените количество раз в конце или мета-значение. Например, перевыпуск 1.0.0-бета.0 должен быть 1.0.0-бета.1.
Бета-версии обычно начинаются с 0.1.0. Официальная версия обычно выпускается после завершения быстрой итерации, и разработчик считает, что API стабилен.
Предпосылки для автоматически вычисляемых версий
Терминология Объяснение
Проекты npm делятся на две структуры пакетов:
- Один пакет, в проекте нужно опубликовать только один пакет npm.
- Несколько пакетов, есть несколько пакетов npm, которые необходимо распространять в проекте, обычно используютlernaуправлять
содержание
Если нам нужно добиться автоматического выпуска версии, мы должны сообщить сервису, какую версию нам нужно выпустить, иначе невозможно реализовать требование автоматического расчета версии, несмотря ни на что.
Итак, нам нужно представитьcommitizenэтот инструмент.
Этот инструмент может помочь нам отправить нормализованную информацию о коммите:
Формат следующий:
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]
Как правило, это не так строго для ежедневной разработки, требуется тип и описание, при необходимости выбирается разбивка, а другой контент не является обязательным.
Читателям слишком сложно понять, что представляют собой эти трое, сначала объяснит автор.
Тип — это изменения кода, внесенные в этот коммит, которые в основном делятся на следующие категории:
- feat: новая функция, из-за которой официальная версия может изменить номер младшей версии
- fix: Изменить ошибку, из-за которой в официальной версии может измениться номер версии патча.
- рефакторинг: рефакторинг кода, не приведет к изменению версии
- docs: Относится к документации, не приведет к изменению версии
- стиль: изменение формата кода, не приведет к изменению версии
- test: тестовый пример, не приведет к изменению версии
- chore: Изменения, связанные с конфигурацией проекта, не приведут к изменению версии.
Конечно, если у пользователей есть персонализированные потребности, они также могут добавлять или удалять эту часть контента.
description буквально, он представляет информацию о локальном коммите.
Последнее ломается.Когда есть несовместимый API, нам нужно отправить эту часть контента, чтобы сообщить официальной версии, что номер основной версии необходимо изменить.
PS: Вышеупомянутая версия является официальной.Если текущая версия является бета-версией, пожалуйста, обратитесь к правилам смены версии.Раздел «Правила изменения версии».
Окончательный сгенерированный контент выглядит примерно так:fix: do not alter attributes.
Еще один момент, на который следует обратить внимание, — это проблема множественных пакетов. Если в релизной версии используется унифицированная версия, все в основном вернется к структуре с одним пакетом, что очень просто. Но если версии не унифицированы, нам нужно собрать, в каких пакетах были изменены файлы, и работать только с измененными пакетами во время развертывания.
Есть примерно два способа добиться этого:
Первый метод@lerna/changed, этот инструмент может помочь нам найти все измененные сторонние пакеты. Принцип здесь на самом деле довольно прост, суть в том, чтобы реализовать его через команду git:
git diff --name-only {git tag / commit sha} --{package path}
Перевод заключается в том, чтобы найти, есть ли изменение файла в пакете из последнего тега git или информации о первой фиксации.
Второй метод может преобразовать инструмент git cz и добавить новую функцию: каждый раз, когда делается отправка, автоматически приносятся пакеты, которые были изменены в этой отправке.Конечно, вышеуказанный принцип все еще используется, но мы можем настроить больше в соответствии с к нашим потребностям функция, больше свободы.
Стандартизированная информация о фиксации является краеугольным камнем системы автоматического развертывания, будь то с помощью инструментов или непосредственно от руки, она также позволяет разработчикам четко понимать, какие изменения были внесены в проект.
Как рассчитать версии в системах развертывания
Расчетная версия очень интересная вещь.Здесь нам нужно использовать semver, чтобы помочь нам вычислить.Конечно, вы также можете использовать lerna для расчета в сценариях с несколькими пакетами, но мы по-прежнему напрямую унифицируем semver внутри.
Кроме того, расчет версии нужно разбить на сценарии, а потом мы рассмотрим их по порядку.
Конечно, прежде чем мы начнем, нам нужно понять общие правила изменения следующей версии, потому что несколько сценариев основаны на этом общем правиле.
Общая логика изменений
Во-первых, давайте представим типы, которые необходимо использовать в следующей версии:
major | minor | patch | premajor | preminor | prepatch | prerelease
Первые три уже обсуждались ранее, поэтому я не буду здесь говорить больше.
Последние три все соответствуют первой версии.На примере бета-версии premajor может изменить версию 1.0.0 на 2.0.0-beta.0.По сути, это в основном то же самое, что и первые три, за исключением того, что есть дополнительный номер предварительной версии.
Последний также соответствует предыдущей версии. Взяв в качестве примера бета-версию, версию 1.0.0 можно изменить на 1.0.1-бета.0, а версию 1.0.1-бета.0 также можно изменить на 1.0.1-бета.1.
Зная типы версий изменений, пришло время выяснить, как их вывести. Вообще говоря, пользователи будут отправлять несколько коммитов.Сначала нам нужно выяснить все типы коммитов и выбрать максимальное значение.
Например, если пользователь отправил три коммита с момента последнего выпуска, типы — feat, doc и breakchange, то максимальный тип — breakchange.
Получив максимальный тип коммита, нам нужно рассчитать его по разным версиям. Например, правила выпуска официальной версии и бета-версии различаются, подробнее см.Формат номера версии,Больше никогда.
Например, текущая версия 1.0.0.На данный момент по коммиту мы обнаруживаем, что максимальный тип feat, и нужно выпустить первую версию (beta), поэтому итоговое расчетное правило изменения preminor , а версию можно обновить до 1.1.0-beta.0.
Анализировать информацию о фиксации
Как упоминалось выше, нам нужно проанализировать коммит, чтобы получить тип, поэтому читатели могут спросить, как его проанализировать?
На самом деле принцип очень прост, или воспользуйтесь командой git:
git log -E --format=%H=%B
Для приведенного выше коммита мы можем получить следующие результаты, выполнив команду:
Конечно, этот анализ предназначен для анализа всех коммитов текущей ветки.В большинстве выпусков нам нужно только проанализировать все изменения с момента последнего выпуска, поэтому нам нужно изменить команду следующим образом:
git log 上次的 commit id...HEAD -E --format=%H=%B
Наконец, пришло время всем видам регулярных выражений показать свои таланты, просто сопоставьте любую информацию, которую вы хотите.
Сцена с одним пакетом
Сценарий с одним пакетом на самом деле самый простой, просто примените общую логику изменений напрямую.
Сценарий с несколькими пакетами
Простая среда с несколькими пакетами на самом деле проста. Это не что иное, как один шаг больше, чем один пакет.Вам нужно сначала узнать, какие файлы были изменены, затем вам нужно отфильтровать тип текущего пакета в коммите, и, наконец, применить общую логику изменений.
Многопакетные и взаимозависимые сценарии
Давайте сначала объясним этот сценарий. Например, в настоящее время поддерживаются три пакета A, B и C. Зависимости пакета A включают B и C. Это означает, что зависимости есть. В настоящее время требуется несколько шагов для расчета версии .
Когда общая логика закончена, нам нужно решить, нужно ли нам менять версию пакета в соответствии с зависимостями.
Например, при локальной отправке необходимо выполнить исправление для изменения версии пакета B, а в двух других пакетах нет изменений кода. Но на самом деле нам все равно нужно изменить версию А, иначе, если при обновлении Б не произойдет обновление до А, пользователи, использующие пакет А, не смогут использовать новую версию пакета Б.
окончание
Когда мы посчитали все версии, нам нужно написать package.json и выполнитьnpm publishИ, наконец, быть представленным в соответствии с отмеченным тегом кода.
наконец
Данная статья является общим обсуждением следующей версии и содержания этой части релиза.Если у вас есть какие-либо вопросы, вы можете обменяться и обсудить.
Кроме того, я полагаю, что некоторые читатели скажут, что это слишком громоздко, и есть другие инструменты, которые могут упростить шаги. Конечно, автору это тоже известно, но принцип автоматической модификации версии под них согласуется с этой статьей, и не будет преувеличением понять, как работает инструмент.