@cmstops/pro-compo
Version:
> 快速上手：[传送门](/docs/get-start.md)
135 lines (99 loc) • 6.64 kB
Markdown
# 智媒管家业务组件库
> 快速上手：[传送门](/docs/get-start.md)
## 模块介绍
业务组件库基于 Vue3 + Storybook 搭建，结合 ArcoDesgin，包含智媒管家平台核心业务相关组件
## 版本规范
关于版本，这里需要提一下
按理论来讲业务组件的版本和产品的版本不应该有强关联（即产品的版本是 3.0，业务组件可以是 1.0）
但是因为产品的买家（即甲方爸爸）使用的产品可能是 3.1、3.2、3.3...，并且会有强定制的情况
所以这里我们需要有一个约定，以便研发人员更好的溯源 & 协作 & 维护～
当前约定如下：
| 分支类型 | 分支名称 | 描述 | 使用位置 | 版本号规则 |
| ------------ | ---------------------------- | -------------------------------- | ------------- | ---------------------------- |
| **主分支** | main | 研发自测完毕并 _可以上线_ 的需求 | 预发布环境 | x.x.x-**rc**.y |
| **版本分支** | release/xxx | 经过完整测试的需求 | 线上/项目环境 | x.x.x-**stable**.y |
| **定制分支** | release/xxx-{{project.name}} | 经过测试的 _定制_ 需求 | 项目环境 | x.x.x-**{{project.name}}**.y |
| **开发分支** | develop | 研发自测完毕的需求 | 测试环境 | x.x.x-**alpha**.y |
> 所谓 "可以上线"，有两种情况：
>
> 1. 是指当前产品发布计划中是否有该功能，如果有，则可以合并至 main，否则不可以
> 2. 该功能是所有版本通用的功能，无论产品版本是多少，都可以合并至 main
### 版本发布示例
假设当前产品版本是 3.2.0
此时：
- 主分支 main 版本号为 3.2.0-rc.0
- 版本分支 release/v3.2.0 版本号为 3.2.0-stable.0
- 开发分支 develop 版本号为 3.2.0-alpha.0
#### 示例 1：当前版本 bug 修复 A 功能和 B 功能
1. 第一步：基于 release/v3.2.0 版本切出：hotfix/v3.2.0-A，hotfix/v3.2.0-B
2. 第二步：bug-A 修复后，将 hotfix/v3.2.0-A 合并至 develop 自测并发布 3.2.0-alpha.**1**
3. 第三步：bug-B 修复后，将 hotfix/v3.2.0-B 合并至 develop 自测并发布 3.2.0-alpha.**2**
4. 第四步：自测完毕后，将 hotfix/v3.2.0-A & hotfix/v3.2.0-B 合并至 main 并发布 3.2.0-rc.**1** 交付测试
5. 第五步：测试完毕后，将 hotfix/v3.2.0-A & hotfix/v3.2.0-B 合并至 release/v3.2.0 并发布 3.2.0-stable.**1** 交付线上
> 注意：第二步第三步可以分开 publish，也可以都合并到 develop 之后再 publish，因为两个 bug 不一定是同一个人修复，所以会有个先后顺序
> 但是尽量 rc 和 stable 尽量统一发布，减少版本号的迭代，方便维护和问题追溯
功能分支走向图：
```mermaid
graph TD
A[release/v3.2.0] --> B[hotfix/v3.2.0-A]
A --> C[hotfix/v3.2.0-B]
B --> D[develop 3.2.0-alpha.1]
C --> E[develop 3.2.0-alpha.2]
D --> F[main 3.2.0-rc.1]
E --> F
F --> G[release/v3.2.0 3.2.0-stable.1]
```
#### 示例 2：历史版本 release/v3.0.0 bug 修复 C 功能
1. 第一步：基于 release/v3.0.0 版本分支切出：hotfix/v3.0.0-C
2. 第二步：bug-C 修复后，将 hotfix/v3.0.0-C 合并至 develop 自测，并发布 3.2.0-alpha.**3**
3. 第三步：自测完毕后，将 hotfix/v3.0.0-C 合并至 main 并发布 3.2.0-rc.**2** 交付测试
4. 第四步：测试完毕后，将 hotfix/v3.0.0-C 合并至 release/v3.0.0、release/v3.0.0、release/v3.1.0、release/v3.2.0；并发布：3.0.0-stable.x、3.1.0-stable.y、3.2.0-stable.**2**
功能分支走向图：
```mermaid
graph TD
A[release/v3.0.0] --> B[hotfix/v3.0.0-C]
B --> C[develop 3.2.0-alpha.3]
C --> D[main 3.2.0-rc.2]
D --> E[release/v3.0.0 3.0.0-stable.x]
D --> F[release/v3.1.0 3.1.0-stable.y]
D --> G[release/v3.2.0 3.2.0-stable.2]
```
> 注意：如果是低版本的问题，尽可能的在出问题的版本处理，然后逐层向上合并（如果新版本已经修复并且代码改动较多，有冲突时，解决冲突并保留新版本原逻辑即可）
> **如果按照社区常见的版本迭代规则，bug 的解决应该是在最新版本，旧版本的代码是不会改动的。**
> **但是实际我们自己的业务场景必须低版本也要能解决，为了尽量不去重复写代码，只能去手动的维护一下该操作。**
#### 示例 3：新版本 release/v3.3.0 功能 D 开发
1. 第一步：基于 release/v3.2.0 版本切出：feature/v3.3.0-D
2. 第二步：Feat-D 开发完毕后，将 feature/v3.3.0-D 合并至 develop 自测，并发布 3.3.0-alpha.**0**
3. 第三步：自测完毕后，将 feature/v3.3.0-D 合并至 main，并发布 3.3.0-rc.**0**
4. 第四步：测试完毕后，基于 release/v3.2.0 切出 release/v3.3.0，将 feature/v3.3.0-D 合并至 release/v3.3.0
功能分支走向图：
```mermaid
graph TD
A[release/v3.2.0] --> B[feature/v3.3.0-D]
B --> C[develop 3.3.0-alpha.0]
C --> D[main 3.3.0-rc.0]
A --> E[release/v3.3.0]
D --> E
```
#### 示例 4：通用功能 E 开发
1. 第一步：基于最早版本 release/v3.0.0 切出：feature/v3.0.0-E
2. 第二步：Feat-E 开发完毕后，将 feature/v3.0.0-E 合并至 develop 自测，并发布 3.3.0-alpha.**1**
3. 第三步：自测完毕后，将 feature/v3.0.0-E 合并至 main，并发布 3.3.0-rc.**1**
4. 第四步：测试完毕后，将 feature/v3.0.0-E 合并至 release/v3.0.0、releaes/v3.1.0、release/v3.2.0、release/v3.3.0
> 业务组件库这个项目和其他模块的不同之处在于，如果这里说是新功能
> 一般是指又抽离出了一个产品的核心业务，而这个核心业务与产品的 **版本** 关联性不强，所有版本均可使用的这种功能
功能分支走向图：
```mermaid
graph TD
A[release/v3.0.0] --> B[feature/v3.0.0-E]
B --> C[develop 3.3.0-alpha.1]
C --> D[main 3.3.0-rc.1]
D --> E[release/v3.0.0]
D --> F[release/v3.1.0]
D --> G[release/v3.2.0]
D --> H[release/v3.3.0]
```
#### 示例 5：3.1.0 版本 _G_ 项目定制 功能 F 开发
1. 第一步：基于 release/v3.1.0 切出：feature/v3.1.0-G-F
2. 第二步：Feat-F 开发完毕后，基于 release/v3.1.0 切出 release/v3.1.0-G，将 feature/v3.1.0-G-F 合并至 release/v3.1.0-G，并发布 3.1.0-G.**0**
> 注意：如果有项目有定制，后续的任何通用更新不会覆盖该版本，所以在定制之前需和产品 **再三确认**