-
Notifications
You must be signed in to change notification settings - Fork 257
Chain33平行链升级规范
[TOC]
Chain33平行链完成阶段性开发，具备对外发布条件时。 包含小版本发布（6.2.x）， 大版本发布（6.3.0）
Chain33平行链功能不断迭代，使用的项目方也越来越多。 需要把升级工作规范化，流程化，把工作做在平时，减轻升级过程的压力。
Chain33的升级通常会基于以下等原因： 1）. 现有版本中存在bug, 用升级的方式解决bug. 2）. 对现有版本的性能，效率等做优化提升。比如6.1到6.2, 优化存储效率。 3）. 现有版本不能满足用户的需求，需要增加一些新功能。 4）. Chain33团队追踪业界新技术，自主研发区块链新特性。
基于目前公司人员的配置， 升级工作规范化需要chain33研发，测试，产品，运维几个环节协调配合。
1）. 建议任何代码的修改，都需要在github上提交相应的issue, 标题和内容尽量详尽，以便将来快速回溯。
2）. 建议在plugin目录下，放置一份平行链配置文件，开发中有参数的变动，都要同步修改此文件。
3）. 开发人员需要对新引入的fork配置项，参数配置项做详细说明。 以ForkBase58AddressCheck这个改动为例说明：
在平行链配置文件最顶上增加变更记录： 2019年xx月xx日，在[fork.system]标签下，新增ForkBase58AddressCheck配置项。 在ForkBase58AddressCheck配置项的上方增加清晰明确的注释：解决什么问题，配置建议.
4）. 功能开发完成，自测通过后，提交合并请求。
Chain33产品负责人根据bug和需求，抽取全部或部分功能形成一个发布版本（比如release6.2.1），之后测试人员介入。
原则上，在没有特殊需求的情况下，此版本不再合入任何无关代码。 包括测试过程中发现并修改的问题，也只接受相关功能的合入。
1）. 验证发布版本的基本功能。
2）. 验证版本升级，建议逐渐完善一个测试库，包含几个不同的项目方的配置文件，尽量能包含全业务（coins合约，token合约，游戏合约等）
3）. 升级过程要覆盖平滑升级和全新升级两种场景，确保升级前后state hash一致。
- . 验证通过后，打包升级版本上传oss服务器，并输出升级文档。
升级文档中包含: 升级原因；新增配置参数，fork参数的说明及建议配置；版本下载路径；详细升级步骤；升级前后状态检查。
提前同项目方约定升级时间点， 升级原因，并收集相应的反馈意见。
1）. 确保获取到的版本一定是跟升级文档中一致的。 2）. 严格按照升级文档步骤操作， 特别注意fork高度，每条链的配置都不一样，需要由运维人员在升级过程中自主配置。 3）. 升级完成后，根据升级文档做前后状态检查。 发现状态不一致， 及时反馈给研发。
hello world