规范化版本管理实践

作者: wolfwolfgod | 来源:发表于2020-11-19 20:19 被阅读0次

规范化版本管理实践
Java Web技术经验总结（十一）
git 版本管理实践
pycharm 使用 poetry 创建的虚拟环境
第三章宇鑫制度文化
DevOps 教程 (1): Maven 项目版本的介绍
HR-制度规划
项目版本管理模型
水质检测制度
软件测试，如何薪资破万

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

规范git commit提交记录，

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

Angular 团队的 commit 规范

它的 message 格式如下:

<type>(<scope>): <subject>
// 空一行
<body>
// 空一行
<footer>

分别对应 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中的配置如下:

            <plugin>
                <groupId>se.bjurr.gitchangelog</groupId>
                <artifactId>git-changelog-maven-plugin</artifactId>
                <version>1.62</version>
                <executions>
                    <execution>
                        <id>GenerateGitChangelog</id>
                        <phase>generate-sources</phase>
                        <goals>
                            <goal>git-changelog</goal>
                        </goals>
                        <configuration>
                            <templateContent>
                                <![CDATA[
# Changelog
Changelog of My Project.

{{#tags}}
## {{name}}
 {{#issues}}
  {{#hasIssue}}
   {{#hasLink}}
### {{name}} [{{issue}}]({{link}}) {{title}} {{#hasIssueType}} *{{issueType}}* {{/hasIssueType}} {{#hasLabels}} {{#labels}} *{{.}}* {{/labels}} {{/hasLabels}}
   {{/hasLink}}
   {{^hasLink}}
### {{name}} {{issue}} {{title}} {{#hasIssueType}} *{{issueType}}* {{/hasIssueType}} {{#hasLabels}} {{#labels}} *{{.}}* {{/labels}} {{/hasLabels}}
   {{/hasLink}}
  {{/hasIssue}}
  {{^hasIssue}}
### {{name}}
  {{/hasIssue}}

  {{#commits}}
**{{{messageTitle}}}**

{{#messageBodyItems}}
 * {{.}}
{{/messageBodyItems}}

[{{hash}}](https://github.com/{{ownerName}}/{{repoName}}/commit/{{hash}}) {{authorName}} *{{commitTime}}*

  {{/commits}}

 {{/issues}}
{{/tags}}
         ]]>
                            </templateContent>
                            <file>CHANGELOG.md</file>
                        </configuration>
                    </execution>
                </executions>
            </plugin>

maven发布版本

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

配置 scm

    <scm>
        <!--release包需要放入的nexus或者其他maven release包的仓库url地址-->
        <url>http://172.16.30.215:8082/repository/maven-releases/</url>
        <!--connection, developerConnection: 都是连接字符串，其中后者是具有write权限的scm连接 -->
        <!--需要打包项目的git地址-->
        <developerConnection>scm:git:http://172.16.30.210/chenrm/commitizen-test.git</developerConnection>
        <!--需要打包项目的git地址-->
        <connection>scm:git:http://172.16.30.210/chenrm/commitizen-test.git</connection>
        
        <tag>demo-1.0.4</tag>
    </scm>

配置插件

            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-release-plugin</artifactId>
                <version>3.0.0-M1</version>
                <configuration>
                    <scmCommentPrefix>release</scmCommentPrefix>
                    <scmDevelopmentCommitComment>@{prefix}: prepare for next development iteration</scmDevelopmentCommitComment>
                    <scmReleaseCommitComment>@{prefix}: prepare release @{releaseLabel}</scmReleaseCommitComment>
                    <!--git用户名-->
                    <username>chenrm@witsoft.cn</username>
                    <!--git密码-->
                    <password>Abcd1234</password>
                    <!--mvn目标指令-->
                    <goals>-f pom.xml deploy</goals>
                </configuration>
            </plugin>

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

    <distributionManagement>
        <snapshotRepository>
            <id>maven-snapshots</id>
            <name>User Porject Snapshot</name>
            <url>http://172.16.30.215:8082/repository/maven-snapshots/</url>
            <uniqueVersion>true</uniqueVersion>
        </snapshotRepository>
        <repository>
            <id>maven-releases</id>
            <name>User Porject Release</name>
            <url>http://172.16.30.215:8082/repository/maven-releases/</url>
        </repository>
    </distributionManagement>

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

   <server>
    <id>maven-releases</id>
    <username>admin</username>
    <password>Abcd1234</password>
    </server>
    <server>
    <id>maven-snapshots</id>
    <username>admin</username>
    <password>Abcd1234</password>
    </server>

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

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

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

规范化版本管理实践
这里说的版本管理，特指发布的版本管理。而不是指代码的版本管理。当然，代码的版本管理也是数据信息来源的一部分。规范...
Java Web技术经验总结（十一）
Git工作流：Git 工作流程 Maven版本管理：阅读Maven最佳实践：版本管理 lombok project...
git 版本管理实践
最近在做项目时，突然遇到一个未知的BUG，明明项目昨天运行好好的，今天打开电脑发现怎么运行都是失败。原因未知......
pycharm 使用 poetry 创建的虚拟环境
2021最佳实践：pyenv 管理python版本， poetry 负责依赖包管理。 1. pyenv pytho...
第三章宇鑫制度文化
制度承载文化，制度的执行使文化在员工实践和传承，制度是对员工行为实行系统化、标准化、规范化的统一管理，促进经营管理...
DevOps 教程 (1): Maven 项目版本的介绍
英文原文地址在这篇五部分的DevOps系列教程中我将解释如何使用Maven管理项目版本、版本管理的最佳实践、将版...
HR-制度规划
规范化管理是企业一项艰巨、需要持续改进的工作，它是企业正常有效开展的基础，是企业健康有序发展的保障，规范化管理同时...
项目版本管理模型
版本管理在软件开发过程中十分常见，如下是常见的一种最佳实践，适用于所有的版本管理系统(svn, git等)。发布...
水质检测制度
今天来谈一谈关于规范化管理的水质检测制度。我当过几次规范化管理考核水质专家，有人问我，水质检测制度应该怎么样编写...
软件测试，如何薪资破万
测试理论实践测试概论测试流程需求分析测试计划测试用例设计缺陷管理版本管理测试执行操作系统虚拟机...