一直以來，因爲團隊項目迭代節奏很快，每次發佈的更新日誌和版本更新都是通過人肉來完成的。有時候實在忙的團團轉，對於手動的寫這些更新信息就顯得力不從心了。對於團隊新來的小夥伴，有時候遇到些緊急情況，就更顯的亂糟糟，還是得麻煩團隊資深的同學。顯然這些工作，用自動化工具再適合不過了。
本文是一篇項目自動化方面的使用教程，社區裏面針對四類問題的解決方案很多，今天這裏主要介紹的是 conventional-changelog 方案相關的內容。 如果你正在思考或者試圖解決這方面的問題的話，不妨瞭解一下。
conventional-changelog
conventional-changelog 是一款可以根據項目的commit 和 metadata信息自動生成 changelogs 和 release notes的系列工具，並且在輔助 standard-version 工具的情況下，可以自動幫你完成生成version、打tag, 生成CHANGELOG等系列過程。
conventional-changelog 生態主要模塊
conventional-changelog-cli - conventional-changelog 核心命令行工具
standard-changelog - 針對 angular commit 格式的命令行工具
conventional-github-releaser - 利用 git metadata 針對 Github 的發佈工具
conventional-commits-detector - commit message 規範引用檢測
commitizen - 針對開發者簡單的 commit 規範
commitlint - commit Lint 工具
以上是 conventional-changelog 生態重要的幾個主要模塊，實際工作中這幾個工具常常是配套使用的，當然也需要根據自己的情況而定。篇幅有限，今天我們就主要介紹 commitizen、conventional-changelog-cli 、standard-version 這三工具了。
commitizen
commitizen 是一款標準化 git commit 信息的工具。在沒有規範的情況下，開發人員的 commit 信息是常常是隨意的，這就導致 commit 信息顯的很無用。可是當你在做git log、code review、編寫changelog等情況時，良好的 commit 規範就顯的尤爲重要。
commitizen 安裝
$ npm install -g commitizen
或者本地安裝
$ npm install --save-dev commitizen
安裝適配器（Adapter)
因爲不同的項目本身的構建方式的不同，commitizen 支持不同適配器的擴展，從而去滿足不同的構建需求的。本文主要使用cz-conventional-changelog的構建標準，當然你也可以根據具體的情況選擇其他的適配器，更多請看。
$ npm install -g cz-conventional-changelog
全局安裝完成後，我們需要在項目根目錄下添加 .czrc 配置文件，文件內容如下：
// path 用來指定適配器
{ “path”: “cz-conventional-changelog” }
本地安裝
$ npm install cz-conventional-changelog --save-dev
或者使用 commitizen 工具
$ commitizen init cz-conventional-changelog --save-dev --save-exact
commitizen 工具會自動在package.json中添加配置相應的配置，具體如下：
“config”: {
“commitizen”: {
“path”: “cz-conventional-changelog”
}
}
安裝並添加完後，我們便可以使用 git cz 命令替換 git commit 來使用了。我們修改一個文件並 git add 後，通過 git cz 試一下：
可以看到，git cz 給出了 commit 的幾種類型選項，如下：
feat 新功能
fix Bug 修復
docs 文檔更新
style 代碼的格式，標點符號的更新
refactor 代碼重構
perf 性能優化
test 測試更新
build 構建系統或者包依賴更新
ci CI 配置，腳本文件等更新
chore 非 src 或者 測試文件的更新
revert commit 回退
使用的時候，我們應該根據項目具體變更情況選擇。如果想修改已經打好的 commit 信息，我們可以通過 git reset命令來修復。
需要注意的是，僅僅是添加 commit 工具是不夠的，爲了保證 commit 格式的一致性，這裏強烈建議你記得整合 commitlint 工具, 配合 git commit-msg hook 來使用，在這裏就不相信介紹了，具體可以查看官方文檔。
conventional-changelog-cli
conventional-changelog-cli 默認推薦的 commit 標準是來自angular項目,除了 angular 標準以外，目前集成了包括 atom, codemirror, ember, eslint, express, jquery 等項目的標準，具體可以根據自己口味來選用。
安裝
Help conventional-changelog --help
$ npm install -g conventional-changelog-cli
基本使用
$ conventional-changelog -p angular -i CHANGELOG.md -s
以上命令中參數-p angular用來指定使用的 commit message 標準，假如想使用atom的標準，則是：
$ conventional-changelog -p atom -i CHANGELOG.md -s
參數-i CHANGELOG.md表示從 CHANGELOG.md 讀取 changelog, -s 表示讀寫 changelog 爲同一文件。需要注意的是，上面這條命令產生的 changelog 是基於上次 tag 版本之後的變更（Feature、Fix、Breaking Changes等等）所產生的，所以如果你想生成之前所有 commit 信息產生的 changelog 則需要使用這條命令：
$ conventional-changelog -p angular -i CHANGELOG.md -s -r 0
其中 -r 表示生成 changelog 所需要使用的 release 版本數量，默認爲1，全部則是0。
自定義參數
生成的 changlog 中有些常用內容可以通過自定義參數來根據需求更改，例如版本號、commit 地址等等。 changelog 中生成的版本號即是從 package.json 中獲取 version 字段來的。commit 連接的倉庫地址我們需要修改 package.json 中的repository地址，changelog 中 issuse 默認的連接地址也是根據 repository 來生成的。如果你使用了第三方的協作系統（例如 bitbucket）， 那麼你可以使用這個標準conventional-changelog-angular-bitbucket。或者像我們使用 redmine 來管理 isssue ，那麼在生成 changelog 後可以使用 replace 工具來處理文本中的原有地址：
$ replace ‘https://github.com/myproject/issues/’ ‘https://redmine.example.com’ CHANGELOG.md
最後看看大致生成的效果：
conventional-changelog 更多的選項配置可以看這裏。
standard-version
standard-version 是一款遵循語義化版本（ semver）和 commit message 標準規範 的版本和 changlog 自動化工具。通常情況線下，我們會在 master 分支進行如下的版本發佈操作：
- git pull origin master
- 根據 pacakage.json 中的 version 更新版本號，更新 changelog
- git add -A, 然後 git commit
- git tag 打版本操作
- push 版本 tag 和 master 分支到倉庫
其中2，3，4則是 standard-version 工具會自動完成的工作，配合本地的 shell 腳本，則可以自動完成一系列版本發佈的工作了。
安裝 & 使用
在這裏我仍然推薦的全局安裝：
$ npm install -g standard-version
或者
$ npm install --save-dev standard-version
執行：
Help standard-version --help
$ standard-version
執行 standard-version 命令，我們會在控制檯看到整個執行流程的 log 信息，在這裏幾個常用的參數需要注意下:
–release-as, -r 指定版本號
默認情況下，工具會自動根據 主版本（major）,次版本（ minor） or 修訂版（patch） 規則生成版本號，例如如果你package.json 中的version 爲 1.0.0, 那麼執行後版本號則是：1.0.1。自定義可以通過：
$ standard-version -r minor
output 1.1.0
$ standard-version -r 2.0.0
output 2.0.0
$ standard-version -r 2.0.0-test
output 2.0.0-test
需要注意的是，這裏的版本名稱不是隨便的字符，而是需要遵循語義化版本（ semver） 規範的
–prerelease, -p 預發版本命名
用來生成預發版本, 如果當期的版本號是 2.0.0，例如
$ standard-version --prerelease alpha
output 2.0.0-alpha.0
–tag-prefix, -t 版本 tag 前綴
用來給生成 tag 標籤添加前綴，例如如果前版本號爲 2.0.0，則：
$ standard-version --tag-prefix “stable-”
output tag: stable-v2.0.0
以上這幾個參數可能我們用的比較多，還有其他選項可以通過 standard-version --help查看。
集成 npm
最後記得把命令集成到 npm package.json的 scripts 中, 並配合 shell 腳本使用, 如下：
“scripts”: {
“release”: “./scripts/release.sh”,
“changelog”: “conventional-changelog -p angular -i CHANGELOG.md -s -r 0 && git add CHANGELOG.md && npm run changeissueurl”,
“changeissueurl”: “replace ‘https://github.com/myproject/issues/’ ‘https://redmine.example.com/’ CHANGELOG.md”
},
// 配置好後使用 npm run 執行發佈
$ npm run release
添加 release.sh 腳本：
#!/bin/bash
while [[ “$#” > 0 ]]; do case $1 in
-r|–release) release="$2"; shift;;
-b|–branch) branch="$2"; shift;;
*) echo “Unknown parameter passed: $1”; exit 1;;
esac; shift; done
Default as minor, the argument major, minor or patch:
if [ -z “$release” ]; then
release=“minor”;
fi
Default release branch is master
if [ -z “$branch” ] ; then
branch=“master”;
fi;
echo “Branch is $branch”
echo “Release as $release”
Tag prefix
prefix=“prefix_v”
git pull origin $branch
echo “Current pull origin $branch.”
Generate version number and tag
standard-version -r $release --tag-prefix $prefix --infile CHANGELOG.md
git push --follow-tags origin $branch
echo “Release finished.”
上面的腳本只是做了簡單的分支 pull, 執行 standard-version 和最後的版本 push 工作，如果要做一些定製化的執行參數，則需要做定製修改了。
最後
項目的工程化是一件很有意思的事情，通過自動化的工具，可以有效提升項目可維護性和質量，並且避免很多不確定因素。如果你工作中發現了這些問題，而不想繼續通過人肉的方法解決這些問題的話，那就趕緊試試~