记一次使用 Coding 持续集成控制版本号

前言

已经使用 Coding 中的项目协同 很久了但是 对于版本管理的的内容一直很薄弱,版本号格式一直都是sample-api:20240731-24,每次看到版本号都不知道每个版本更新了什么内容. 那看了 语义化版本 [1] 后想把整体的流程再次串起来.

目标

通过 Coding 项目协同 -> 到代码开发 -> CICD -> 最终提供出一个标准的版本号.

graph LR
Coding项目协同-->代码合并/分支标签-->CICD-->提供最终标准版本号

版本号规范如下 参考 Coding 最佳实践

场景

版本号规则

版本号示例

常用环境

合并请求

mr-{合并请求 ID}-{hash}

mr-123-3a11e12

开发/测试

合并后(或推送分支)

{分支名}-{hash}

main-3a11e12

测试

推送 tag

{tag}

1.2.0

预发布/生产

开始

项目协同相关

创建版本

默认版本从 1.0 开始 1 为主版本号 0 为不影响主版本的功能迭代,版本其实比较好理解我做一个用户管理功能的系统,那么一个 CRUD 完成就是一个版本的控制.

image-20240912110250432.png

创建迭代

迭代我们这边里可以理解为在什么时间段内完成哪些功能,例如我设置该迭代版本为 24 年 9 月版本那么这里的内容都属于是需要在 9 月份完成的.

image-20240912110908843.png

创建需求

image-20240912111144632.png

分解任务绑定迭代和版本

image-20240912111551840.png

以上完成整体项目协同的内容,每个任务指派到人,如果有过个相同岗位的人员则选出一名组长由组长进行分配.

代码仓库相关

创建项目

创建一个最简单的项目此处只为模拟,(公司有特定脚手架就使用特定脚手架)

image-20240912142033661.png

分支设置

设置仓库分支规范

Clipboard - 2024-09-12 15.15.15.png

设置/分支规范

image-20240912162847109.png

分支模型包含 main develop feature release hotfixes

main / develop

main(master) 主干分支

应用发布分支,所有版本都将从这里发布,开发者对对应的主干分支添加上标签(tag),由系统进行打包分发.

Master 上的代码应该是最稳定的代码. Master 代码应该和 Develop 是并行的.

develop 开发分支

当 develop 上的代码足够稳定时就可以将 develop 合并到 main 主干分支上.

feature 功能分支

当有新的功能时,从 develop 创建出一个新的分支 feature/功能 例如 feature/organization_relevance_user,当代码开发完成后再次合并至 develop 并描述该合并做了哪些内容,可以关联前面需求的资源.

image-20240913094045012.png

release 预发布分支

Release 是从 Develop 分支上进行创建,当我们完成产品版本号为 1.1.5 同时我们有一个大的版本即将发行,决定下个版本是什么.所以给一个可以反应新版本的订阅的版本.然后在提交到 Master需要添加一个版本的标签,以便以后更方便的引用这个历史版本. Release 上的 Bug 修改也需要合并到 develop 版本,以便未来发行版本也包含这些 bugs 修复.

hotfixes 热修复分支

热修复分支是从 Master 分支上面分出来的,例如 1.2 的版本有异常但是 develop 分支还不稳定,那么我们就需要分出一个 bug 分支.

当 bug 修复完毕时再将分支合并至 master 并添加版本号 例如 1.2.1 版本.再将 hotfix 分支合并到 develop.

总结

image-20240913101202190.png

持续集成相关

Java To Maven

内部人员可以采用模板 EP_JAVA_MAVEN_V2

  1. 拉取代码

  2. 设置Maven代码版本

  3. 编译代码并推送

Java To Docker

内部人员可以采用模板 EP_JAVA_DOCKER_V2

  1. 拉取代码

  2. 编译代码

  3. 打包 Docker

Vue To Docker

内部人员可以采用模板 EP_VUE_Docker_V2

  1. 拉取代码

  2. 编译代码

  3. 打包 Docker

当有新任务时开发与发布流程

新需求流程

  1. 在项目协同中添加新的需求或任务

  2. 从 Develop 中 创建一个新分支 feature/xxxx 进行开发

  3. 完成开发后 将 feature 合并到 develop 分支,在合并时需要在合并请求中 添加资源 选中之前在项目协同中添加的新需求和新任务

  4. 开发在 开发环境 完成测试后,将 develop 分支合并至 release/1.x 版本.

  5. 测试在 UAT 环境 完成测试后,将 release/1.x版本合并至main分支并给 main 分支添加上 tag 最终的版本号标签

BUG修复流程

热修复流程

  1. 在项目协同中添加新的缺陷

  2. Main 分支中 创建一个新分支 hotfixs/fix-xxx

  3. 完成代码修改后合并至 MainDevelop分支 并给 Main 分支创建一个标签,如果之前的 Main 分支标签为 1.0 那么现在版本就是 1.0.1 如果之前分支标签是 1.0.1 那么现在版本就是 1.0.2,合并至 Develop 是为以后的迭代中也修复了改内容.

总结

这样就可以得到一个比较适合的项目版本号

参考资料

  1. 语义化版本 2.0.0 - https://semver.org/lang/zh-CN/

  2. Coding 最佳实践 - 自动生成版本号 - https://coding.net/help/docs/ci/practice/artifacts/version.html

附件

gitGraph
    commit tag: "0.1"
    branch develop
    checkout develop
    commit
    commit
    branch feature
    commit
    commit
    checkout develop
    merge feature
    branch release
    checkout release
    commit
    checkout main
    merge release tag: "0.2"
    branch hotfixes
    commit
    checkout main
    merge hotfixes tag: "0.2.1"
    checkout feature
    merge main
    commit
    commit
    commit
    checkout develop
    merge feature
    checkout release
    merge develop
    checkout main
    merge release tag: "0.3"