Juice Git Flow

目前存在问题

  • 每个项目分支众多,命名混乱,有的分支用于测试,有的用于代码合并,有的分支用于开发,有的分支已经被废弃,分支跟标签混淆,时间久了无法了解分支的具体用途。混乱疯狂的分支合并操作,多个分支互相合并,出现问题难以回滚。以cpp-ethereum项目为例,截止到2018/09/12为主,有如下42个分支(标签我就不列了)。

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    all-static
    async_pbft_fork_v1.6
    branch_release_v1.2.2_alpha
    develop
    develop-jamvm
    develop-jamvm-v1.6
    develop-memory
    develop-memory-0930
    develop-module
    develop-v1.6.0-java-native
    develop.1.5.1.3.log
    feature-externCall
    feature-nonce
    feature-pbft
    feature-sina-nonce
    feature-websockets
    jamvm-submodule
    jvmDevDemo
    jvm_dev_0913
    master
    monitoring
    origin/develop-jamvm
    release_for_test_1.2.0.0_alpha
    release_for_test_1.2.1.0_alpha
    release_for_test_1.2.888.0_alpha
    release_for_test_1.3.1_alpha
    release_for_test_1.3.2_alpha
    release_for_test_1.3.3_alpha
    release_for_test_1.4.0.1_alpha
    release_for_test_1.5.0.1_alpha
    statechannels_baseon1.5
    test_1.6.0.1
    v1.2.2_alpha
    v1.4.0_branch
    v1.4.0_branch_bug20171212
    v1.5
    v1.5.3.30_sina
    v1.5.3.9-online
    v1.5.4
    v1.5.5
    v1.6
    zk
  • 打出来的标签”无效”
    目前打标签均由Jenkins自动打的,Jenkins打标签的流程是由测试人员选择特定的分支,而这些分支往往是开发分支。如果出包成功,则马上给项目打上标签,给测试人员去测试。当然,如果测试人员将所有的测试通过了,那么由Jenkins打的标签有效。如果测试未通过,那么该标签则是一个无效的标签!

  • Juice 包不完整
    现在打出来的Juice整包,没有包含需要的配套的Dapp,以及启动链的客户端。每次需要搭链的时候,客户端与Dapp都不知道去哪里找。拿过来的客户端或Dapp也不能确定是否跟底层配套。底层开发人员对客户端不熟,客户端开发人员对底层不熟,由此因”开发环境”问题耽误底层开发人员时间。除了打包不完整,出包结构也要做调整。如Web版本的包有底层有其他,唯独没有启动底层的Web。monitor包有无需要用到的底层。
  • 项目代码混乱
    console项目为例,里面有基于electron框架写的钱包客户端代码,有使用Java语言写的后台控制台,还有使用Solidity语言写模块合约。试想,三个项目同时进行同时提交代码,如果合并的时候,负责客户端代码的人员遇到其他两个项目的冲突如何解决? 如果客户端代码出了问题,我想跟历史代码进行比较,那么就可能大段其他两个项目更改的代码。还有问题是客户端将node_modules代码进行引入。

解决流程

  • 集中管理
    创建一个juice项目,将能独立的项目都拆分出来,以 git submodule 方式管理juice用到的所有项目,一是Jenkins打包将以此项目为标准,二是方便随时能checkout出一个经过测试验证过的整个juice可用的代码,也方便整个开发人员了解其他项目。大概设想目录结构如下:
1
2
3
4
5
6
7
8
9
juice/
├── cpp-ethereum/ # JUZIX Ethereum C++ client
├── console # 提供钱包管理功能的矩阵元区块链控台+WEB前端
├── monitor # 矩阵元联盟链监控后台monitor
├── Client-web/ # 矩阵元客户端和JUICE客户端的仓库
├── DApp-monitor # 矩阵元联盟链监控Dapp monitor
├── DApp-console/ # 区块链控制台DApp
├── ...... # 其他一些Juice项目或待拆分项目
└── inner-contracts/ # juzix ethereum inner contract
  • 分支规范

    • master-ooo: 主分支,经测试测试无误之后,由测试人员操作Jenkins在该分支上打标签正式发布。保存每个版本所有的发布记录。
    • release-ooo-x.x: 测试分支,开发人员编码完成之后,推送到此分支,由测试打包发布。此分支也做代码评审合并分支。保存整个版本的所有开发记录。此分支。
    • develop-ooo-x.x: 开发分支,开人员编码工作在此分支上进行。下一个版本出来之前删除。
    • hotfix-xxxxxx: master分支出现的bug紧急修复分支。修复完合并到master分支。合并完成由开发人员删除。
    • feature-xxxxxx: 比较大的功能,从develop分支拉出来开发的功能。开发完成合并到develop分支,合并完成由开发人员删除。
      其中ooo代表名称,比如master-sina,master-open-source。x.x代表版本(其实版本号也是没必要要的),比如release-sina-1.5。xxxxx代表说明,比如hotfix-bug1111(紧急修复bug),hotfix-permission-leak(紧急修复权限漏洞),feature-nonce(开发nonce功能),feature-pbft(开发pbft功能)。后面说的分支,均只用前面的部分进行描述。
      上述分支只是供参考,具体依据实际项目个人变通。比如cpp-ethereum多人开发,不建议大功能在develop分支上面直接开发,当然,很少改动可以在develop分支直接开发没问题。如果只是个人负责单个项目,可以直接在develop分支进行开发。但是需要注意的是master, release分支永远不要作为开发分支。
  • Jenkins打包大概流程

    1. 各个负责人将develop合并到release分支,将代码审核无误之后,将代码push到远程分支,通知测试人员打包。后期应做到用钩子,Juice整个项目有推送自动打包。
    2. Jenkins将获取各个项目release分支上的最新代码,进行打包。
    3. 测试人员测试出的包。
    4. 测试人员测试无问题,测试人员回到Jenkins,以步骤1打包的代码状态打标签推送到服务器,测试有问题,回到步骤1。

主要工作量及时间预估

  • 整理代码,将该拆分项目进行拆分,删除无效的分支。(3day)
  • 由于之前Jenkins打包是在Linux平台进行,在Windows打包的客户端没有由Jenkins打包。需要Jenkins触发一台Windows服务器,进行打包。打包完成之后将客户端拷贝回来。(4day)
  • 按照上述流程,修改Jenkins打包流程。(3day)

资源需求

  • 用于给客户端,Dapp构建的Windows 10服务器。
  • 开放开发人员删除标签,分支的权限。上述hotfix, feature如果需要协助,需要推送到服务器,合并完成需要开发人员删除。
  • 给参与Juice项目人员开放所有Juice相关项目。鼓励以juice项目开发,并了解其他相关项目原理。

Git Flow 流程参考

Alt text

您的支持将鼓励我继续创作!
0%