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

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

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

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

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

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

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

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

npm install -g verdaccio
or
yarn global add verdaccio
verdaccio

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

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

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

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

另一種是通過 npm version 來修改版本號，提供有這如下參數(shù)

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

詳細(xì)解釋如下：

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

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

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

項目開啟CI，選擇一個公共的 runner，要是沒有，那就只能自己弄一個。

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

# 定義 stages
stages:
  - build

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

配置完成

我們要說的重點來啦，通過畫圖的方式來給大家介紹我們的設(shè)計思路。先來設(shè)定些約定

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

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

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

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

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

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

"my-package": "~1.2.0"

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

畫了開發(fā)、發(fā)布的時序圖，如下。

開發(fā)時序圖如下

主要是CI的編碼，如下

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

# 定義 job
job2:
  stage: publish
  before_script:
    - cd /home/node/MY #進(jìn)到項目目錄
    - 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";
// 判斷文本是否是版本號格式
function checkCommitMessage(subject) {
    return /^d+.d+.d+$/g.test(subject)
}

// 獲取最近一次提交，判斷是否是版本號格式，若不是，則進(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ā)布腳本里有個函數(shù) checkCommitMessage 用于判斷最新的提交message是不是版本號格式，因為我們最后會有一步push的操作，push后會再一次觸發(fā)CI，所以為了防止死循環(huán)，我們通過提交的message作為是否觸發(fā)CI的依據(jù)，這么一來我們就要規(guī)范message的格式，我的建議是按照這個格式 U ${修改的具體的內(nèi)容}。

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