分支管理规范

问题背景

使用一个dev，pre分支管理dev 环境和 pre环境，研发release环境基本废弃（服务端环境不稳定）, 统一通过pre分支上master

1. 频繁需要人为介入管理分支和解决dev,pre冲突，解决冲突过程容易误操作拉取dev,pre分支的代码提交到release 分支
2. 需要频繁重建剔除pre环境分支不需要上线的代码，如果出现人为失误，就容易带上不应该上线的分支代码
3. 多版本并行,一个版本出问题，就阻塞所有版本进度
4. 一旦存在一个长期测试不上线的研发版本，需要延伸dev2, pre2，多几个类似的研发版本就炸裂了
5. 测试环境的单一, 需要审核一直陪跑，留给MR的时间往往迫于测试的紧急和突发性很难预留

调整方案

1. 发布通过release上线，上线前需要反向同步master代码（最好每次提交都pull from master，定期更新），合并机器人会检测提交的分支是否落后于master的提交；
2. 所有合向release的代码都需要approver;
3. 每个release分支可以有自己的独立的临时的dev,pre测试环境空间，不互相影响；
4. 加强前期版本规划：如果存在多个release分支同时要发布，能合并到一个release的前期就以feature合作方式合并掉，合并不掉的拉取新的release分支，将要发布的release合并到一个release发布；
5. 如果业务逻辑涉及需要固定路径地址

• 5.1 代码合并方式：依旧将代码提交到dev/pre分支
• 5.2 抢占式：指定分支部署覆盖环境

部署优化策略(gitlab)

小程序

小程序原来是一个环境对应一个appid，要做到每个release有自己的独立测试空间，只能用研发码。
研发码就一个问题————时效性。 解决思路其实就是，让二维码的获取变得容易:

• 开放交互让任何人都能获取
  • 交互这块采用机器人的方式，告诉机器人项目，版本号，环境，机器人去触发出码
• 加快出码速度
  • 利用独立分支的特性，增加构建产物cache，如果已经存在构建产物且没有变更，直接进行上传生成二维码
    外加其实如果码过期，但之前访问过这个版本，在手机上可以通过访问记录找到之前的访问入口，依然可以访问

H5

H5 原来一版方案是通过域名映射到对应的文件目录
由于目前他们的使用习惯已经习惯了固定三个环境域名
就采用目录去做区分(项目名-版本号-环境)
同时提供chrome插件做分支代理，允许用原来的访问路径，然后代理到分支产物路径