规范化版本管理实践

这里说的版本管理，特指发布的版本管理。而不是指代码的版本管理。当然，代码的版本管理也是数据信息来源的一部分。

规范git commit提交记录，

开发人员随意的提交记录不利于回顾分析，因此需要有一定的标准，其中Anjular团队规范比较受大家欢迎，同时需要一定工具来支持，方便使用。

Angular 团队的 commit 规范

它的 message 格式如下:

(): 
// 空一行

// 空一行

分别对应 Commit message 的三个部分：Header，Body 和 Footer。

Header

Header 部分只有一行，包括三个字段：type（必需）、scope（可选）和subject（必需）。

• type: 用于说明 commit 的类型。一般有以下几种:

feat: 新增feature
fix: 修复bug
docs: 仅仅修改了文档，如readme.md
style: 仅仅是对格式进行修改，如逗号、缩进、空格等。不改变代码逻辑。
refactor: 代码重构，没有新增功能或修复bug
perf: 优化相关，如提升性能、用户体验等。
test: 测试用例，包括单元测试、集成测试。
chore: 改变构建流程、或者增加依赖库、工具等。
revert: 版本回滚

• scope: 用于说明 commit 影响的范围，比如: views, component, utils, test...
• subject: commit 目的的简短描述

Body

对本次 commit 修改内容的具体描述, 可以分为多行。如下所示:

# body: 72-character wrapped. This should answer:
# * Why was this change necessary?
# * How does it address the problem?
# * Are there any side effects?
# initial commit

Footer

一些备注, 通常是 BREAKING CHANGE(当前代码与上一个版本不兼容) 或修复的 bug(关闭 Issue) 的链接。

可以利用一些工具来方便提交

安装nodejs

安装conEmu

conEmu主要是解决在windows中查看log中文乱码的问题，需在conEmu中设置环境变量

image.png

添加 set LANG=zh_CN.UTF-8

安装 commitizen

commitizen是一个帮助规范commit message的工具，它可以帮我们控制 commit 的格式，并让提交复杂格式时比git commit -m更加容易

# 需要同时安装commitizen和cz-conventional-changelog，后者是adapter
$ npm install -g commitizen cz-conventional-changelog
# 配置安装的adapter
$ echo '{ "path": "cz-conventional-changelog" }' > ~/.czrc
# 使用
$ git cz

对于windows系统，~目录对应C:\Users\xxx
我们可以根据项目定制提交的模板，在项目目录下建立文件.cz-config.js， 内容如下：

'use strict';

module.exports = {

    types: [
        {value: 'feat', name: '特性:    一个新的特性'},
        {value: 'fix', name: '修复:    修复一个Bug'},
        {value: 'docs', name: '文档:    变更的只有文档'},
        {value: 'style', name: '格式:    空格, 分号等格式修复'},
        {value: 'refactor', name: '重构:    代码重构，注意和特性、修复区分开'},
        {value: 'perf', name: '性能:    提升性能'},
        {value: 'test', name: '测试:    添加一个测试'},
        {value: 'chore', name: '工具:    开发工具变动(构建、脚手架工具等)'},
        {value: 'release', name: '发布:   发布版本'},
        {value: 'revert', name: '回滚:    代码回退'}
    ],

    scopes: [
        {name: '模块1'},
        {name: '模块2'},
        {name: '模块3'},
        {name: '模块4'}
    ],

    // it needs to match the value for field type. Eg.: 'fix'
    /*
    scopeOverrides: {
      fix: [
        {name: 'merge'},
        {name: 'style'},
        {name: 'e2eTest'},
        {name: 'unitTest'}
      ]
    },
    */
    // override the messages, defaults are as follows
    messages: {
        type: '选择一种你的提交类型:',
        scope: '选择一个scope (可选):',
        // used if allowCustomScopes is true
        customScope: 'Denote the SCOPE of this change:',
        subject: '短说明:\n',
        body: '长说明，使用"|"换行(可选)：\n',
        breaking: '非兼容性说明 (可选):\n',
        footer: '关联关闭的issue，例如：#31, #34(可选):\n',
        confirmCommit: '确定提交说明?'
    },

    allowCustomScopes: true,
    allowBreakingChanges: ['特性', '修复'],

    // limit subject length
    subjectLimit: 100

};

安装commitlint

有了commitizen可以帮助方便提交，但是无法强制，所以我们需要一个提交时检查的工具，commitlint可以帮我们达到此目的。
commitlint是一个提交验证工具。原理是可以在实际的 git commit 提交到远程仓库之前使用 git 钩子来验证信息。提交不符合规则的信息将会被阻止提交到远程仓库。
安装：

npm install -g @commitlint/cli @commitlint/config-conventional

为了可以在每次 commit 时执行 commitlint 来 检查我们输入的 message，我们还需要用到一个工具 —— husky。
husky 是一个增强的 git hook 工具。可以在 git hook 的各个阶段执行我们在 package.json 中配置好的 npm script。

npm install --save-dev husky

建立文件 package.json,指明hooks

{
  "husky": {
    "hooks": {
      "commit-msg": "commitlint -E HUSKY_GIT_PARAMS"
    }
  }
}

建立文件 commitlint.config.js 配置验证规则

module.exports = {
    extends: ['@commitlint/config-conventional'],
    rules: {
        'type-enum': [
            2,
            'always',
            [
                'WIP',      // 开发中
                'feat',     // 新特性
                'improvement', // 加强现有特性
                'fix',      // 修补bug
                'refactor', // 重构
                'docs',     // 文档
                'test',     // 单元测试
                'config',   // 配置文件
                'style',    // 格式需改
                'perf',     // 性能提升
                'ci',       // ci
                'revert',   // 版本回退
                'release',  // 发布版本
                'chore',    // 其他修改
            ],
        ],
        'type-empty': [2, 'never'],               // type不能为空
        'type-case': [0, 'always', 'lower-case'], // type不限制大小写
        'subject-empty': [2, 'never'],            // subject（简短得描述）不能为空
        'subject-max-length': [1, 'always', 50],  // subject最大长度，超出只会警告，不阻止提交
        'body-leading-blank': [1, 'always'],
        'footer-leading-blank': [1, 'always'],
        'header-max-length': [2, 'always', 72],
    }
};

这样，提交的检查配置就完成了，提交时使用git cz命令即可

maven 生成CHANGELOG.md

使用插件git-changelog-maven-plugin，可以在构建时自动生成changelog,pom.xml中的配置如下:

            
                se.bjurr.gitchangelog
                git-changelog-maven-plugin
                1.62
                
                    
                        GenerateGitChangelog
                        generate-sources
                        
                            git-changelog
                        
                        
                            
                                
                            
                            CHANGELOG.md
                        
                    
                
            

maven发布版本

使用插件maven-release-plugin，可以方便的管理版本发布流程，配置 pom.xml

配置 scm

    
        
        http://172.16.30.215:8082/repository/maven-releases/
        
        
        scm:git:http://172.16.30.210/chenrm/commitizen-test.git
        
        scm:git:http://172.16.30.210/chenrm/commitizen-test.git
        
        demo-1.0.4
    

配置插件

            
                org.apache.maven.plugins
                maven-release-plugin
                3.0.0-M1
                
                    release
                    @{prefix}: prepare for next development iteration
                    @{prefix}: prepare release @{releaseLabel}
                    
                    [email protected]
                    
                    Abcd1234
                    
                    -f pom.xml deploy
                
            

由于发布的过程会将jar发布到私有仓库，因此需将仓库地址定义在pom.xml中

    
        
            maven-snapshots
            User Porject Snapshot
            http://172.16.30.215:8082/repository/maven-snapshots/
            true
        
        
            maven-releases
            User Porject Release
            http://172.16.30.215:8082/repository/maven-releases/
        
    

发布过程中会上传，需要NEXUS的用户名密码，这个在maven的settings.xml中配置

   
    maven-releases
    admin
    Abcd1234
    
    
    maven-snapshots
    admin
    Abcd1234
           

这样，在发布版本时，使用命令

mvn -DpreparationGoals=clean release:clean release:prepare
mvn -Darguments="-Dmaven.test.skip=true" release:perform

会打包当前版本，发布到NEXUS的release库，同时将pom.xml中版本号升级为下一版本号的SNAPSHOT版本