I also did some work on automation deployment years ago and shared what I learned in this blog post: One small step in automation deployment, one big step in front of the brick. Thanks to @_Shanks and @Tomczhen for giving me the motivation to continue optimizing the deployment process. This article is mainly in the automated deployment process, the version management and process rationality and other aspects to do some improvements, with a standardized workflow, better use experience!

PS: If you need to learn about CI/CD directly, poke here -> spend half a day to easily create a front-end CI/CD workflow.

Update logs are automatically generated

Before, I manually modified Changelog. md to record the update log, which was tiring and not very standard. Fortunately, people have already planted trees, so I consider using conventional changelog-cli to automatically generate and update Changelog. md, really easy to use!

But – changelog is what

Generate a changelog from git metadata

The update log is generated from git metadata, and the conventional-changelog-cli is the related command-line tool.

But – the changelog – cli installation

npm install -g conventional-changelog-cli
Copy the code

Changelog.md is generated by initialization

cd my-project
conventional-changelog -p angular -i CHANGELOG.md -s
Copy the code

The above command generates or updates changelo.md based on the last commit record of Feature, Fix, Performance Improvement or Breaking Changes. If you want to generate a complete changelog. md from all previous commit records, try this command:

conventional-changelog -p angular -i CHANGELOG.md -s -r 0
Copy the code

workflow

Code is added to the staging area

There is nothing special about this step, which is routine code and then add the contents of the workspace to the staging area.

git add .
Copy the code

Standardize the commit message

A canonical Commit message is typically divided into three parts: Header, Body, and Footer. The Header contains sections such as Type, scope, and Subject, which describe the COMMIT type, scope of influence, and brief commit, respectively. The Body is a detailed description that can be written in multiple lines. Watch-watches Footer is used mainly to describe Breaking changes or to close an issue (watch-# issue)

Format is as follows:

<type>(<scope>) :<subject>

<body>

<footer>
Copy the code

Here’s an example:

Feat (supporting automatic deployment): Combined with the deployment script to complete the deployment task, the Conventional deployment script is used to automatically generate changelog. The whole deployment process is more normalized Breaking Change: bigger update watches #315Copy the code

The Header is required and the Body and Footer can be omitted.

After you have a general understanding of the specification, you are ready to use the tool, in this case, commitizen.

npm install -g commitizen
Copy the code

Next, run the following command in the project root directory:

commitizen init cz-conventional-changelog --save --save-exact
Copy the code

After running successfully, package.json will add the following:

"devDependencies": {
  "cz-conventional-changelog": "^ 3.1.0"
},
"config": {
  "commitizen": {
    "path": "./node_modules/cz-conventional-changelog"}}Copy the code

The git commit step is replaced by git cz, which stands for commitizen. It is done through the interactive command line.

PS D:\robin\frontend\spa-blog-frontend> git cz [email protected], [email protected]? Select the type of change that you're committing: feat: A new feature ? What is the scope of this change (e.g. component or file name): (press enter to skip) support automatic deployment? Write a short, imperative tense Description of the change (Max 86 Chars): (37) Complete the deployment task with the deployment script combined with the Conventional Changelog? Provide a longer description of the change: (press enter to skip) ? Are there any breaking changes? No ? Does this change affect any open issues? No [Master EE41F35] Feat (Supporting automatic deployment): 3 Files changed, 15 insertions(+), 3 deletions(-)Copy the code

Process the version number and update CHANGELOG

Next, we need to update the version number of the NPM package. In combination with NPM version and Conventional Changelog, we can update changelog.md at the same time.

Ok, let’s prepare the script:

"scripts": {
    "start": "vue-cli-service serve"."build": "vue-cli-service build"."deploy": "node deploy"."version": "conventional-changelog -p angular -i CHANGELOG.md -s && git add CHANGELOG.md"."postversion": "npm run deploy"
}
Copy the code

Update the patch, minor, and Major versions based on the actual version. Assuming we update the minor version number, the operation command is as follows:

NPM Version minor -m 'Feature version update'Copy the code

Executing this command updates the version field in package.json,

Conventional -changelog-p angular -i changelog. md -s && git add changelog. md is executed to update Changelog. md.

After executing this command, you can see that changelog. md has been modified.

The NPM hook triggers the deployment script

The deployment script node deploy is triggered using the PostVersion hook to start the deployment. The contents of the deploy.js file are as follows:

const { execFile } = require('child_process');

const version = process.env.npm_package_version;

execFile('deploy.sh', [version], { shell: true }, (err, stdout, stderr) = > {
    if (err) {
        throw err;
    }
    console.log(stdout);
});
Copy the code

The child_process module executes the child process using nodeJS, invokes execFile to execute deploy.sh, and passes the NPM package version number as a parameter to deploy.sh.

The contents of the deploy.sh file are as follows:

#! /bin/bash
npm run build
htmldir="/usr/share/nginx/html"
uploadbasedir="${htmldir}/upgrade_blog_vue_ts"
appenddir=$1
uploaddir="${uploadbasedir}/${appenddir}"
projectdir="/usr/share/nginx/html/blog_vue_ts"
scp -r ./dist/. txcloud:${uploaddir}
ssh txcloud > /dev/null 2>&1 << eeooff
ln -snf ${uploaddir} ${projectdir}
exit
eeooff
echo done
Copy the code

The above commands do the following:

  • npm run buildExecute the build task
  • Will be builtdistThe contents of the folder pass throughscpTransfer to the server, distinguishing versions by version number.
  • nginxThe configuration is listening80Port, pointing to/usr/share/nginx/html/blog_vue_tsAnd I will through the soft linkblog_vue_tsPointing again toupgrade_blog_vue_tsFor example,Upgrade_blog_vue_ts / 0.5.4. Each time a version is released, the script changes the softlink to point to the target version, such asUpgrade_blog_vue_ts / 0.6.0To complete the version transition.

I’ve improved my previous deployment script by using a soft link to keep the individual historical version folders on the server without having to deal with the separation of index.html from static resources.

It is strongly recommended to combineOne small step for automated deployment, one big step for the front endRead this article together.

LRWXRWXRWX 1 root root 47 Feb 3 "blog_vue_ts - > / usr/share/nginx/HTML/upgrade_blog_vue_ts 0.6.0Copy the code

If you want to roll back the version, you can also modify the softlink, which is more convenient.

Pushed to the remote

Finally, don’t forget to push your code to a remote repository.

git push
Copy the code

It is also easy to view the changelog log, see what has been changed at a glance, and jump directly to commit history, issues, etc.

One day

As you can see, I called deploy.sh through deploy.js. I wanted to call deploy.sh directly in NPM scripts and pass in the version number parameter, but I tried several ways to write it.

"deploy": "deploy.sh npm_package_version"
Copy the code
"deploy": "deploy.sh $npm_package_version"
Copy the code

It seems that when you call sh script from NPM scripts, you can only write parameters, and passing variables as parameters does not seem to work.

The following literal argument is fine, but it’s a bit silly and not in line with the topic of automated deployment.

"Deploy" : "the deploy. Sh 0.6.0"Copy the code

So I still choose to invoke deploy. Sh using deploy.js as the intermediary.

conclusion

It should be admitted that the deployment process I described above is illustrated by my personal project, which may not be very standard, but it can be regarded as a complete set of deployment process through my own understanding and exploration, without using Jenkins and other tools. With this learning experience of automated deployment, it will be easier to learn and use Jenkins. As I continue to refine and standardize my deployment process, Jenkins will certainly be on my to-do list.

  • Better start learning now, Ollie!
  • If you found this article helpful, please leave a like and follow in support. Thanks!
  • Fast attention to the public number front si Nan, and the author to exchange learning!