4. 共享库版本管理基础:Git分支策略、Tag标签、版本号语义化规范(SemVer)

在Jenkins共享库的准入体系中,版本管理是基石。没有清晰的分支策略、规范的标签命名和语义化的版本号,共享库的发布、回滚与依赖管理将陷入混乱。本节将系统讲解这三项核心基础,为后续的版本准入规则奠定可执行的技术前提。

4.1 Git分支策略:共享库的协作模型

共享库的代码仓库需要一套轻量但严格的分支策略,以区分开发、集成与发布阶段。推荐采用Trunk-Based Development(主干开发)结合短期特性分支的模式,避免长期并行分支带来的合并灾难。

分支名称 用途 生命周期 准入要求
main / master 稳定发布分支,仅通过PR合并 永久 必须通过CI测试 + 代码评审
develop 日常集成分支,所有特性分支的汇合点 永久 必须通过CI测试
feature/xxx 新功能或修复开发 短期(1-3天) 从develop拉出,完成后删除
release/x.y.z 发布候选分支,用于最终验证与打标签 短期(发布后删除) 仅允许bug修复,禁止新功能
hotfix/x.y.z 紧急修复生产问题 短期(修复后删除) 从main拉出,修复后合并回main和develop
实践建议:共享库仓库应禁止直接向 main 和 develop 推送代码。所有变更必须通过 Pull Request(PR)触发 Jenkins 流水线进行静态检查与单元测试,确保分支策略被严格执行。
共享库分支策略与发布流程 共享库分支策略与发布流程 develop feature/xxx release/x.y.z main v1.2.3 hotfix/x.y.z 流程说明: 1. 开发者从 develop 创建 feature 分支进行开发。 2. 完成开发后,通过 PR 将 feature 合并回 develop。 3. 准备发布时,从 develop 创建 release 分支,进行最终验证。 4. 验证通过后,release 合并到 main,并在 main 上打 Tag。 5. 紧急修复从 main 拉出 hotfix 分支,修复后合并回 main 和 develop。

4.2 Tag标签:不可变的发布锚点

Git Tag 是共享库版本准入的唯一不可变锚点。与分支不同,Tag 一旦创建就不应被修改或删除(除非极端情况)。Jenkins 共享库的消费者(如 Jenkinsfile)通过引用特定的 Tag 来锁定依赖版本,确保构建的可复现性。

重要原则:禁止在 Tag 创建后移动或删除它。如果发现严重问题,正确的做法是:修复代码 → 创建新的 Patch 版本 → 打新的 Tag。历史 Tag 应永久保留,以支持旧版本的持续维护与审计。

4.2.1 Tag命名规范

推荐采用 v 前缀 + 语义化版本号的格式,例如 v1.2.3。这种命名方式与 SemVer 标准天然对齐,且易于在 Jenkins 流水线中通过正则表达式进行匹配和校验。

Tag 示例 含义 是否推荐
v1.2.3 标准语义化版本 ✅ 强烈推荐
v1.2.3-rc.1 发布候选版本 ✅ 推荐用于预发布
v1.2.3+build.20240101 带构建元数据的版本 ✅ 可用于CI自动生成
release-1.2.3 非标准前缀 ⚠️ 不推荐,增加解析复杂度
1.2.3 缺少 v 前缀 ⚠️ 不推荐,与 SemVer 规范不一致

4.3 版本号语义化规范(SemVer)

语义化版本控制(Semantic Versioning,简称 SemVer)是共享库版本管理的核心标准。它通过 主版本号.次版本号.修订号 的三段式结构,向使用者传递明确的兼容性信号。

4.3.1 SemVer 核心规则

给定一个版本号 MAJOR.MINOR.PATCH,每次版本号的递增必须遵循以下规则:

  • MAJOR(主版本号):当做了不兼容的 API 修改时递增。例如:修改了共享库中公开函数的签名、删除了某个步骤、改变了默认行为。
  • MINOR(次版本号):当以向后兼容的方式添加功能时递增。例如:新增一个步骤、增加一个可选参数、扩展了某个功能。
  • PATCH(修订号):当做了向后兼容的问题修正时递增。例如:修复了一个 bug、优化了性能、更新了文档。
关键理解:版本号不仅仅是数字,它是共享库作者与消费者之间的契约。消费者看到 v2.0.0 就知道需要修改自己的 Jenkinsfile;看到 v1.5.0 就知道可以安全升级;看到 v1.5.1 就知道只是修复了问题,不会破坏现有功能。

4.3.2 预发布版本与构建元数据

SemVer 还支持预发布版本和构建元数据,用于标识非稳定版本或CI自动构建的版本:

格式 示例 排序规则 使用场景
MAJOR.MINOR.PATCH-PRERELEASE 1.0.0-alpha.1 低于正式版本 内部测试、功能预览
MAJOR.MINOR.PATCH+BUILD 1.0.0+build.20240101 不影响版本优先级 CI自动构建标识
MAJOR.MINOR.PATCH-PRERELEASE+BUILD 1.0.0-rc.1+build.42 预发布 + 构建信息 发布候选版本的CI构建
语义化版本号结构解析 语义化版本号(SemVer)结构解析 MAJOR . MINOR . PATCH -PRERELEASE 版本号递增规则: 🔴 MAJOR(主版本):不兼容的 API 修改 → 消费者必须修改代码 🔵 MINOR(次版本):向后兼容的新功能 → 消费者可安全升级 🟢 PATCH(修订号):向后兼容的 bug 修复 → 消费者应尽快升级 🟣 PRERELEASE(预发布):标识非稳定版本,优先级低于正式版本

4.4 版本准入的基线规则

基于上述分支策略、Tag 规范和 SemVer 标准,我们可以定义共享库版本准入的基线规则。这些规则将在后续章节中通过 Jenkins Pipeline 实现自动化校验。

  1. Tag 必须符合 SemVer 格式:正则表达式 ^v?[0-9]+\.[0-9]+\.[0-9]+(-[0-9A-Za-z.-]+)?(\+[0-9A-Za-z.-]+)?$ 用于校验。
  2. Tag 必须指向 main 分支:只有从 main 分支创建的 Tag 才被视为正式发布版本。
  3. 版本号必须递增:新 Tag 的版本号必须大于仓库中已存在的最大 Tag 版本号。
  4. 预发布版本不可用于生产:包含 - 预发布标识的 Tag 只能用于测试环境。
  5. 禁止重复 Tag:不允许创建与已有 Tag 完全相同的版本号。
自动化提示:在 Jenkins 共享库的 vars/ 目录中,可以封装一个 versionCheck.groovy 步骤,用于在流水线中自动执行上述基线规则的校验。该步骤将作为版本准入的第一道防线。