# Chain33平行链升级规范

## 1 此规范适用场景

Chain33平行链完成阶段性开发，具备对外发布条件时。 包含小版本发布（6.2.x）， 大版本发布（6.3.0）

## 2 规范制订的背景

Chain33平行链功能不断迭代，使用的项目方也越来越多。 需要把升级工作规范化，流程化，把工作做在平时，减轻升级过程的压力。

## 3 Chain33平行链版本升级原因

Chain33的升级通常会基于以下等原因：
1）. 现有版本中存在bug, 用升级的方式解决bug.
2）. 对现有版本的性能，效率等做优化提升。比如6.1到6.2, 优化存储效率。
3）. 现有版本不能满足用户的需求，需要增加一些新功能。
4）. Chain33团队追踪业界新技术，自主研发区块链新特性。

## 4 如何做到升级规范化

基于目前公司人员的配置， 升级工作规范化需要chain33研发，测试，产品，运维几个环节协调配合。

#### 4.1. Chain33研发

###### 研发阶段

1）. 建议任何代码的修改，都需要在github上提交相应的issue, 标题和内容尽量详尽，以便将来快速回溯。

2）. 建议在plugin目录下，放置一份平行链配置文件，开发中有参数的变动，都要同步修改此文件。

3）. 开发人员需要对新引入的fork配置项，参数配置项做详细说明。 以ForkBase58AddressCheck这个改动为例说明：

> 在平行链配置文件最顶上增加变更记录： 2019年xx月xx日，在[fork.system]标签下，新增ForkBase58AddressCheck配置项。
> 在ForkBase58AddressCheck配置项的上方增加清晰明确的注释：解决什么问题，配置建议.

4）. 功能开发完成，自测通过后，提交合并请求。

###### 代码合入

Chain33产品负责人根据bug和需求，抽取全部或部分功能形成一个发布版本（比如release6.2.1），之后测试人员介入。

原则上，在没有特殊需求的情况下，此版本不再合入任何无关代码。 包括测试过程中发现并修改的问题，也只接受相关功能的合入。

#### 4.2. Chain33测试人员

1）. 验证发布版本的基本功能。

2）. 验证版本升级，建议逐渐完善一个测试库，包含几个不同的项目方的配置文件，尽量能包含全业务（coins合约，token合约，游戏合约等）

3）. 升级过程要覆盖平滑升级和全新升级两种场景，确保升级前后state hash一致。

\4) . 验证通过后，打包升级版本上传oss服务器，并输出升级文档。

> 升级文档中包含: 升级原因；新增配置参数，fork参数的说明及建议配置；版本下载路径；详细升级步骤；升级前后状态检查。

#### 4.3. 市场/产品人员

提前同项目方约定升级时间点， 升级原因，并收集相应的反馈意见。

#### 4.4. 运维操作

1）. 确保获取到的版本一定是跟升级文档中一致的。
2）. 严格按照升级文档步骤操作， 特别注意fork高度，每条链的配置都不一样，需要由运维人员在升级过程中自主配置。
3）. 升级完成后，根据升级文档做前后状态检查。 发现状态不一致， 及时反馈给研发。