Front end Engineering: unveiling Automated Deployment System (1)


Front end Engineering: unveiling Automated Deployment System (1)

Sending NPM packages is a frequent requirement for a slightly larger factory, so the local execution of computing version commands andnpm publishIt’s not feasible. There will be a separate deployment system to help us do this automatically.

Today, let’s talk about the core computing version, release logic and process of the deployment system.

Semantic version of semver

Before we talk about the deployment of the system, we have to talk about the semantic version first, because I found that many people still know little about this piece of content.

Version meaning

  • Less than 1.0.0: beta version, indicating that the API of the library is unstable
  • Greater than or equal to 1.0.0: official version
  • Alpha, beta, RC and other tag words are carried in the version, which are collectively referred to as the antecedent version. The general format is x.y.z – [tag]. [times / meta information]

    • Alpha: build
    • Beta: public beta version
    • RC: the official version of advance

Version number format

In general, the format of version number is x.y.z

  • 10: Major, the major version number, which should be changed when an incompatible API appears
  • Y: Minor, minor version number, which should be modified when a new backward compatible function appears
  • Z: When you need to fix a backward compatible bug, you should modify the version number

But this semantics is not invariable. For example, when the version number is beta (version less than 1.0.0), we can change the semantics to0.minor.patch. It’s normal for incompatible APIs to appear at this time. Instead of directly changing the major version number, the minor version number should be changed. At the same time, the version changes caused by new functions and bug repair should be reflected in the patch.

Version change rules

10. Y.z must be a positive integer and cannot be preceded by zeros.

10. Each time y.z changes the version number, it needs to reset the smaller version number to 0. For example, upgrade from 1.0.2 to 1.1.0.

If the previous version of the same version is released many times, only the number of times at the end or the meta value need to be changed. For example, if 1.0.0-beta.0 is released again, the first version should be 1.0.0-beta.1.

Beta is generally calculated from 0.1.0. The official version can be released after the fast iteration and the developers think the API is stable.

Prerequisites for automatic version calculation

Explanation of terms

NPM projects are divided into two package structures

  • Single package, there is only one NPM package to be published in a project
  • Multi package, there are many NPM packages that need to be contracted in a project, which is usually usedlernaAdministration


Otherwise, we may not know what version we need to automatically implement.

So we need to introducecommitizenThis tool.

This tool can help us submit normalized commit information

Front end Engineering: unveiling Automated Deployment System (1)

The format is as follows:

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

Generally speaking, it is not so rigorous for daily development. Type and description are required. Breaking is optional when necessary.

Readers may not understand what these three represent, but I’ll explain them first

Type is the code change of this commit, which is basically divided into the following types:

  • Feat: a new feature that can cause the formal version to change the secondary version number
  • Fix: the version number can be changed
  • Refactor: code refactoring does not cause version changes
  • Doc: document related, no version change
  • Style: code format modification will not cause version change
  • Test: test case, no version change
  • Chord: project configuration related modification will not cause version change

Of course, if users have personalized needs, they can also add or delete this part of the content.

Description is the literal meaning, representing the local commit information.

Finally, breaking. When an incompatible API appears, we need to submit the content of this part to inform the official version that we need to change the main version number.

PS: all the above are official versions. If the current version is a beta version, change the version rule referenceVersion change rules section

The final generated content looks like this:fix: do not alter attributes

In addition, there is the problem of multiple packages. If we use the unified version, we will return to the single package structure, which is very simple. However, if the versions are not uniform, we need to collect which packages are changed files, and only operate on the changed packages during deployment.

There are two ways to achieve this

The first method is@lerna/changed, this tool can help us find all the changed second-party packages. The principle here is quite simple. The core is to implement it through git command

git diff --name-only {git tag / commit sha} --{package path}

The translation is to find out whether there is a file change in a package from the last git tag or the first commit information.

The second way is to transform git CZ tool and add a new function: each time you submit, you will automatically bring with you which packages have been changed in this submission. Of course, the above principle is still used at the bottom, but we can customize more functions according to the needs, which is more free.

Standardized commit information is the cornerstone of automatic deployment system. Whether it is written by tools or by hand, it can also let developers clearly understand what changes have been made to the general project.

How to calculate version in deployment system

The computing version is a very interesting thing. Here we need to use semver to help us calculate. Of course, you can also use lerna in multi package scenarios, but we still directly unify semver internally.

In addition, the issue of calculating the version needs to be discussed separately. Next, let’s look at it one by one.

Of course, before we start, we need to understand the general change rules of the next version, because several scenarios are based on this general rule.

Common change logic

First of all, we will introduce several types of upgrade version

major | minor | patch | premajor | preminor | prepatch | prerelease

I’ve talked about the first three before. I won’t talk about them here.

The last three correspond to the first version. Take the beta version as an example, Premier can change version 1.0.0 to 2.0.0-beta.0. In fact, it is basically the same as the first three, except that there is an additional first version number.

The last one also corresponds to the first one. Take the beta version for example, you can change version 1.0.0 to 1.0.1-beta.0, and you can also change version 1.0.1-beta.0 to 1.0.1-beta.1.

Knowing the types of change versions, it’s time to think about how to get them. Generally speaking, users will submit multiple commit. First, we need to find out all commit types and get a maximum value.

For example, since the last release, users have submitted three commit types: feat, DOC and breakchange. The maximum type is breakchange.

After getting the maximum commit type, we need to calculate it according to different versions. For example, the release rules of the official version and the beta version are different. SeeVersion number formatIt will not be repeated.

For example, the current version is 1.0.0. At this time, according to commit, we get that the maximum type is feat, and we need to release the beta. Therefore, the final change rule is preminor, and we can upgrade the version to 1.1.0-beta.0.

Front end Engineering: unveiling Automated Deployment System (1)

Analyze commit information

As mentioned above, we need to analyze commit to get type, so readers may wonder how to analyze it?

In fact, the principle is very simple. We still use git command

git log -E --format=%H=%B

Front end Engineering: unveiling Automated Deployment System (1)

For the above commit, we can get the following results by executing the command:

Front end Engineering: unveiling Automated Deployment System (1)

Of course, this analysis includes all the commit of the current branch. Most of the time, we only need to analyze all the changes since the last release. Therefore, we need to modify the command to:

Git log last commit ID... Head - E -- format =% H =% B

Finally, it’s time for all kinds of regular expressions to show off. Just match the information you want.

Single package scenario

In fact, the single package scenario is the simplest. Just apply the general change logic directly.

Multi package scenario

The simple multi package environment is also simple. There is only one more step than a single package. First, you need to find out which files have been changed, then you need to filter out the type of the current package corresponding to the commit, and finally you need to apply the general change logic.

Multi package and interdependent scenarios

Let’s first explain this scenario. For example, three packages a, B, and C are currently maintained. The dependencies of package a include B and C, which means dependency. At this time, multiple steps are needed to calculate the version.

When the general logic is finished, we need to judge whether we need to change the package version according to the dependency relationship.

For example, local submission requires patch to change the version of package B, while the other two packages have no code changes. But in fact, we still need to change the version of a, otherwise only upgrading B will not upgrade a, and users with package a will not be able to use the new version of package B.

Close out

When we have calculated all the versions, we need to write them package.json Then executenpm publishFinally, you need to submit the following code and tag it.


This article is about the next version and release of this part of the content, we have problems can exchange discussion.

In addition, I’m sure some readers will say that it’s too cumbersome. There are other tools to simplify the steps. Of course, I know this, but the principle of automatic version modification under them is consistent with this article. It’s not too much to understand how to do things under the tools.

Front end Engineering: unveiling Automated Deployment System (1)

Recommended Today

Review of SQL Sever basic command

catalogue preface Installation of virtual machine Commands and operations Basic command syntax Case sensitive SQL keyword and function name Column and Index Names alias Too long to see? Space Database connection Connection of SSMS Connection of command line Database operation establish delete constraint integrity constraint Common constraints NOT NULL UNIQUE PRIMARY KEY FOREIGN KEY DEFAULT […]