摘要：所以此版本號(hào)在這里的作用并不是用來(lái)區(qū)分版本的，小版本號(hào)才是真正用來(lái)做版本區(qū)分的，那么在引用這個(gè)就要這么來(lái)控制版本號(hào)，舉個(gè)栗子鎖定大版本號(hào)和小版本號(hào)，不管我們開(kāi)發(fā)過(guò)程中提交了多少次，我們引用都是最新的。

最近在把公司內(nèi)部用的一個(gè)庫(kù)發(fā)布到內(nèi)網(wǎng)的npm私服上，僅僅是發(fā)布的話是比較簡(jiǎn)單的，但這個(gè)庫(kù)是由多個(gè)人一起維護(hù)的，而且npm私服只有一套，所以生產(chǎn)環(huán)境和開(kāi)發(fā)環(huán)境，用的是同一個(gè)，那么，我們的需求來(lái)了：如何設(shè)計(jì)npm包的開(kāi)發(fā)流程和自動(dòng)化發(fā)布流程。 這一套流程我們想要的達(dá)成如下目標(biāo)

支持團(tuán)隊(duì)協(xié)作，有開(kāi)發(fā)提交代碼，其他人能及時(shí)同步到最新代碼

能夠支持常規(guī)迭代和hotfix上線

同一版本開(kāi)發(fā)、測(cè)試、生產(chǎn)環(huán)境的引用包的版本號(hào)都是一致的

自動(dòng)化發(fā)布，減少人工操作

先說(shuō)下如何搭建npm私服和如何發(fā)包，不過(guò)這不是我們這篇要講的重點(diǎn)，所以我們就簡(jiǎn)單介紹

目前比較主流的有 nexus 和 Verdaccio，因?yàn)?Verdaccio 要更輕量些，而且也滿足我們的需求，所以我們選擇它。 Verdaccio 搭建非常簡(jiǎn)單，直接使用默認(rèn)配置就行

npm install -g verdaccio
or
yarn global add verdaccio
verdaccio

就這樣，私服就搭建完成啦。

有了私服，我們先注冊(cè)到本地的npm中
npm set registry http://localhost:4873
然后添加用戶，如果是首次，則會(huì)新建用戶
npm adduser --registry http://localhost:4873
最后是發(fā)布
npm publish

設(shè)定版本號(hào)有兩種方式，一種是人工修改 package.json 中的 version

// package.json
{
  "name": "project",
  "version": "1.0.0",
}

另一種是通過(guò) npm version 來(lái)修改版本號(hào)，提供有這如下參數(shù)

npm version [ | major | minor | patch | premajor | preminor | prepatch | prerelease [--preid=] | from-git]

詳細(xì)解釋如下：

newversion：自定義版本號(hào)，除了已經(jīng)發(fā)布的版本號(hào)，想寫(xiě)啥寫(xiě)啥
major：升級(jí)主版本號(hào) 1.0.0 -> 2.0.0
minor：升級(jí)次版本號(hào) 1.0.0 -> 1.1.0
patch：升級(jí)補(bǔ)丁號(hào) 1.0.0 -> 1.0.1  
premajor：預(yù)備主版本
preminor：預(yù)備次版本
prerelease：預(yù)發(fā)布版本

在執(zhí)行npm version后，會(huì)產(chǎn)生一條新的提交記錄，比如說(shuō)執(zhí)行 npm version 2.0.0完后 ，查看log，會(huì)發(fā)現(xiàn)一條 commit message 為 2.0.0 的提交記錄，至于為啥會(huì)生成這條記錄呢？很簡(jiǎn)單，因?yàn)?b>npm version這行命令其實(shí)是修改了 package.json 中的 version ，修改后并提交，所以就有這條新的提交記錄。要是想自定義提交記錄，可以這么寫(xiě) npm version 2.0.0 -m "Upgrade to %s for reasons" 其中%s就是修改后的版本號(hào)。

我們打算使用 gitlab CI 來(lái)實(shí)現(xiàn)自動(dòng)化發(fā)布，我們也簡(jiǎn)單介紹下 gitlab CI 的一些步驟和配置項(xiàng)。

項(xiàng)目開(kāi)啟CI，選擇一個(gè)公共的 runner，要是沒(méi)有，那就只能自己弄一個(gè)。

項(xiàng)目根目錄新建 .gitlab-ci.yml，寫(xiě)入配置，詳細(xì)的配置可以查看 gtilab官網(wǎng)

# 定義 stages
stages:
  - build

定義 job
job1:
  stage: build
  script:
    - echo "xxx"

配置完成

我們要說(shuō)的重點(diǎn)來(lái)啦，通過(guò)畫(huà)圖的方式來(lái)給大家介紹我們的設(shè)計(jì)思路。先來(lái)設(shè)定些約定

項(xiàng)目的分支的規(guī)劃，設(shè)定三個(gè)分支

feature分支：常規(guī)功能迭代

master分支：穩(wěn)定分支

hotfix分支：當(dāng)有緊急修改時(shí)，創(chuàng)建該分支，作為臨時(shí)修復(fù)分支，這樣可以不影響常規(guī)功能的開(kāi)發(fā)

我們采用 大版本:小版本:次版本號(hào) 這種方式，每一次feature分支上的每次提交都觸發(fā)此版本號(hào)升級(jí)，比如當(dāng)前feature分支的版本號(hào)是 1.1.5 那么下一次提交就會(huì)升級(jí)為 1.1.6 并發(fā)布npm，小版本號(hào)跟著常規(guī)需求迭代往上升級(jí)，比如說(shuō)當(dāng)前是 1.1.8 ，周期性的需求在明天上線，那么上線后，版本號(hào)就升級(jí)為 1.2.0 并發(fā)布npm，大家發(fā)現(xiàn) 1.1.8 和 1.2.0 是同樣的代碼，沒(méi)錯(cuò)，之所以這么做是因?yàn)樾“姹咎?hào)對(duì)應(yīng)的是一個(gè)周期的常規(guī)修改，那么升級(jí)的 1.2.0 就是作為下一次的常規(guī)需求的版本號(hào)，這樣一來(lái)，此版本號(hào)對(duì)應(yīng)的是每一次提交，小版本號(hào)對(duì)應(yīng)的是當(dāng)前的開(kāi)發(fā)階段，這兩個(gè)我們都可以通過(guò)CI來(lái)觸發(fā)修改，不需要人工參與 ，剩下還有個(gè)大版本號(hào)，這個(gè)只有在大改版的情況下才由人工修改，一般來(lái)說(shuō)升級(jí)大版本號(hào)的頻率是比較低的，人工來(lái)來(lái)修改完全是OK的。

大家會(huì)發(fā)現(xiàn)每一次提交就觸發(fā) npm version patch & npm publish 感覺(jué)太頻繁了，但為了能滿足團(tuán)隊(duì)協(xié)作，只好做些小小的讓步。所以此版本號(hào)在這里的作用并不是用來(lái)區(qū)分版本的，小版本號(hào)才是真正用來(lái)做版本區(qū)分的，那么在引用這個(gè)npm就要這么來(lái)控制版本號(hào)，舉個(gè)栗子

"my-package": "~1.2.0"

鎖定大版本號(hào)和小版本號(hào)，不管我們開(kāi)發(fā)過(guò)程中提交了多少次，我們引用都是最新的。

畫(huà)了開(kāi)發(fā)、發(fā)布的時(shí)序圖，如下。

開(kāi)發(fā)時(shí)序圖如下

主要是CI的編碼，如下

# .gitlab-ci.yml
# 定義 stages
stages:
  - publish

# 定義 job
job2:
  stage: publish
  before_script:
    - cd /home/node/MY #進(jìn)到項(xiàng)目目錄
    - git checkout .
    - git checkout $CI_COMMIT_REF_NAME || git checkout -b $CI_COMMIT_REF_NAME
    - git pull -f -X theirs origin $CI_COMMIT_REF_NAME
    - yarn
  script:
    - node publish.js

// publish.js
var shell = require("shelljs");
var git = require("git-last-commit");
var featureBranchName = "feature-npm";
// 判斷文本是否是版本號(hào)格式
function checkCommitMessage(subject) {
    return /^d+.d+.d+$/g.test(subject)
}

// 獲取最近一次提交，判斷是否是版本號(hào)格式，若不是，則進(jìn)行發(fā)布，
git.getLastCommit(function(err, commit) {
    console.log(commit);
    const { subject, sanitizedSubject } = commit;
    shell.exec("echo $CI_COMMIT_REF_NAME");

    if (!checkCommitMessage(subject)) {
        if (sanitizedSubject.indexOf(`Merge-branch-${featureBranchName}-into-master`) > -1) {
            shell.exec("git checkout .");
            shell.exec(`git checkout ${featureBranchName} || git checkout -b ${featureBranchName}`);
            shell.exec(`git pull -f -X theirs origin ${featureBranchName}`);
            shell.exec("npm version minor");
            shell.exec("npm publish");
            shell.exec(`git push origin ${featureBranchName}`);
        } else {
            shell.exec("npm version patch");
            shell.exec("npm publish");
            shell.exec("git push origin $CI_COMMIT_REF_NAME");
        }
     }
});

// package.json
"scripts": {
    "test": "echo "Error: no test specified" && exit 1",
    "prepublish": "build script"
  },

發(fā)布腳本里有個(gè)函數(shù) checkCommitMessage 用于判斷最新的提交message是不是版本號(hào)格式，因?yàn)槲覀冏詈髸?huì)有一步push的操作，push后會(huì)再一次觸發(fā)CI，所以為了防止死循環(huán)，我們通過(guò)提交的message作為是否觸發(fā)CI的依據(jù)，這么一來(lái)我們就要規(guī)范message的格式，我的建議是按照這個(gè)格式 U ${修改的具體的內(nèi)容}。

這個(gè)方案不是個(gè)普適性的方案，畢竟每個(gè)團(tuán)隊(duì)的開(kāi)發(fā)流程都不一樣，目前這個(gè)方案是適合我們目前的場(chǎng)景的。如果有小伙伴的場(chǎng)景跟我們的一致，可以嘗試下，如果小伙伴們有更好的方案，歡迎一起交流呀~