Code specification verification, Commit specification verification, ChangeLog. md generation, version update, tag, release
demo
Currently, the front-end project has done incremental code format validation at pre-commit using lint-stage and ESLint, and has done a degree of normalization at the code level. In order to further standardize the flow of front-end development and make it easier for people to see what we did with each release when we were working together, or for us to review what we did ourselves, so it’s easier to understand, so we don’t have to go to the branch and look at the code at the time. Therefore, I did the following normalized optimization for the process after code verification:
- right
commit
useConventional Commits
specification - in
commit-msg
Stage ofcommit
check - Each project or component library should have its own version, which should be adopted as each version is completed
semver
Specifications, upgraded versions, and typedtag
- After the release, according to the submission
commit
Information generatedCHANGELOG.md
- release
release
Here,release
Refers to thegithub
orgitlab
In therelease
Before introducing the whole process, let’s take a look at the renderings after implementation:
The following are the tools used to optimize the entire process (some commonly used tools are briefly introduced):
1. husky
Blocking Git Hooks allows you to do things within the Git lifecycle. Husky V4 is used here
Huksy supports all Git Hooks:
- check
commit msg
- Verify code format
- Run tests…
2. lint-stage
If you use huksy to block Git Hooks, this will cause you to check all js files when you commit Git, even if you have changed only one
The lint-stage solves this problem by verifying only the parts of the content that you have submitted or that you have modified
3. eslint
Code format check
At the beginning of the introduction how to interceptcommit-msg
And generateCHANGELOG.md
Before we do, we need to know that the current mainstreamcommit-msg
What is the specification?
Magmic-Commits are the most commonly used types of writing, which are reasonable and systematic, and have been described in particular by associative tools
For each Commit, the Commit message consists of three parts: Header, Body, and Footer.
< type > (< scope >) : < subject > / / short line < body > / / short line < footer >
The Header is required, and the Body and Footer can be omitted.
Header
The Header section is a single line with three fields: Type (required), Scope (optional), and Subject (required)
(1)
type
The category used to indicate the Commit
-Sheldon: A feature that fixes bugs, docs, and formats (changes that do not affect the running of the code). -Sheldon: Refactor (changes that are not new features, or changes to the code that fix bugs). Added test chore: Changes to the build process or assistive tools...
(2)
scope
The scope of the COMMIT impact, such as the data layer, the control layer, the view layer, and so on, varies from project to project.(3) Subject is a short description of the purpose of the Commit, not more than 50 characters
Body
The Body section is a detailed description of the Commit, which can be divided into multiple lines
Footer
(1) Incompatible changes
If the current code is incompatible with the previous version, the Footer section begins with Breaking Change, followed by a description of the CHANGE, along with the reasons for the CHANGE and the migration method
(2) Close Issue
If the current commit is for an issue, you can close that issue in the Footer section
Closes #123, #245, #992
4. commitizenInteractive submissioncommit-msg
Here only introduces the local use of the way, easy to work together, the version of the same installation
# NPM install --save-dev commitizens # NPM install --save-dev commitizens Make the project Commitizens friendly NPX Commitizens Init CZ - MagXCom - Changelog -- Save-Dev -- Save-Exact
Configure it in package.json
{"scripts": {"commit": "cz"}} // NPM Run Commit pops up the interactive command line
If you want to force this interaction to be mandatory, you can intercept prepare-commit-msg, and the interactive command line will pop up at git commit
{
"husky": {
"hooks": {
"prepare-commit-msg": "exec < /dev/tty && git cz --hook || true"
}
}
}
5.commitlint
After introducing Conventional Commit and the interactive Commit tool, we now need a tool that verifies that our code is in strict compliance with the Conventional Commit specification. This tool is commitlint
This tool is very simple to use and requires only two steps:
# Install commitlint cli and conventional config
npm install --save-dev @commitlint/{config-conventional,cli}
# Configure commitlint to use conventional config
echo "module.exports = {extends: ['@commitlint/config-conventional']}" > commitlint.config.js
Commitlint-config-conventional (based on the Angular convention)
build
: Changes affecting the build system or external dependencies (sample scope :gulp, broccoli, NPM)ci
: Changes to CI configuration files and scripts (sample range :Travis, Circle, BrowserStack, SauceLabs)chore
: Any other changes that do not modify SRC or test files should be releaseddocs
: Document changesfeat
: New features and functionsfix
: bug fixesperf
: Performance optimizationrefactor
: refactoringrevert
: Returns the previous commitstyle
: Changes that do not affect the meaning of the code (whitespace, formatting, missing semicolons, etc.)test
Test:
6.conventional-changelog
Now that the interactive commit and format verification tools for COMMit-msg have been implemented, it’s time to generate a change document for the commit according to our convention
Conventional – ChangeLog extracts git log history information and generates a document
Quick start
$NPM install -g conventional-changelog-cli $CD my-project # install -g conventional-changelog-cli $CD my-project # install -g conventional-changelog-cli $CD my-project # install -g conventional-changelog-cli $CD my-project # MSG $commence-changeLog -p angular-i changeLog. Md-s # commit MSG $commence-changeLog -p angular-i changeLog. Md-s # commit MSG $changeLog -p angular-i changeLog. Overwrite ChangeLog. md Bexcom-ChangeLog-p angular-i ChangeLog. md-s-r 0 with ChangeLog. md Bexcom-ChangeLog-p angular-i ChangeLog. md-s-r 0
Configure it in package.json
{
"scripts": {
"changelog": "conventional-changelog -p angular -i CHANGELOG.md -s -r 0"
}
}
7. Automatic publishing toolsstandard-version
Semantic version control version format: major.minor.patch, version number increment rules are as follows:
Major version number: when you make incompatible API changes, minor version number: when you make backward compatible functionality additions, revision number: when you make backward compatible problem fixes
Standard-version is a utility that makes version changes and generates changeLog based on Semver (Semantic Versioning) and Conventional Commits
Standard-version does the following things:
- To view
package.json
In the version - upgrade
package.json
Chinese version number andpackage-lock.json
The version number - Based on theconventional-changeloggenerate
changelog
- Create a new Commit (include
bumpFiles
And update theCHANGELOG
) - Created based on a new version
tag
Quick start
- Install dependencies
npm install --save-dev standard-version
- in
package.json
Add a script to
{
"scripts": {
"release": "standard-version"
}
}
// npm run release
8.conventional-github-releaser
Post to the GitHub release or GitLab release
Need to set the environment variable CONVENTIONAL_GITHUB_RELEASER_TOKEN first before use, making access to the Personal access tokens. Select Scope repo for private repositories, or Scope public_repo for public repositories
It is not recommended to putPersonal access tokens
Use locally in the project and publish togithub
It will be invalidated immediately after identification
Quick start
$ npm install -g conventional-github-releaser
$ cd my-project
$ conventional-github-releaser -p angular
// package.json
{
"scripts": {
"release": "conventional-github-releaser -p angular -n changelog-options.js -i CHANGELOG.md -s -r 0 -t e3c6d36e80b8faba29f44e91c5778a8271e83291"
}
}
9. Script configuration
{"scripts": {"commit": "cz", // Beacon - Commit interactive commit" changelog": "conventional-changelog -p angular -n changelog-options.js -i CHANGELOG.md -s -r 0", // create CHANGELOG. Md "github-releaser": "conventional-github-releaser -p angular -n changelog-options.js -i CHANGELOG.md -s -r 0 -t E3c6d36e80b8faba29f44e91c5778a8271e83291, "released / / lot or gitlab releaser" update project - version: project - the minor ": "Node scripts/release/ version-updater.js-t project-r minor", // update-project-version: project-patch": "Node scripts/release/ version-updater.js-t project-r minor", // update-package-version: patch": "Node scripts/release/ version-updater.js-r patch", // update-package-version: minor": "Node scripts/release/ version-updater.js-r minor",// update the library version information "tag": "Node scripts/release/tag.js", // "release":" NPM run tag &&npm run github-releaser"}}
10. Recommend workflow
-
Package (component library)
- The requirements development
- Submit the commit
-
Beta release
update-package-version: patch
Update the component library version, then package itpublish
-
Release release
update-package-version: minor
Update the component library version, then package itpublish
release
Branch reissue,update-package-version: patch
Update the component library version, then package itpublish
-
Master release
changelog
– > inCHANGELOG.md
Add iteration related information ->commit
->release
-
An iterative project
- The requirements development
- Submit the commit
-
Beta release
build
-
Release release
update-project-version: project-minor
Version, and thenbuild
release
Branch reissue,update-project-version: project-patch
Update the version, then package itbuild
-
Master release
changelog
– > inCHANGELOG.md
Add iteration related information ->commit
->release