多分枝测试需求
随着业务和需求的增长，需要研发进行并行开发，如何保证功能之间不受影响，防止研发打架。如何保证大家代码不被覆盖，如何保证上线的功能就是上线的代码。这需要从代码管理方面来进行考虑，当然推行git是基本。
1.功能开发时使用功能分支，抛弃都提交到develop分支的方式，单独拉取一个分支进行开发，保证开发的时候只涉及当前功能；
2.权限管控：下掉开发master权限，只保留开发权限；
3.上线的时候通过代码合并的方式将功能代码提交到master，合并通过cmdb平台自动完成。
会带来的问题
当开发功能从develop到功能分支，不可避免的会遇到合并代码时候的冲突问题，这个需要在合并的时候研发进行相应的处理，解决冲突。
多分枝测试的实现
为什么要做多分枝讲了，那么如何实现呢？
多分枝不可避免就是服务器上需要跑多套环境，多套不可避免会造成资源冲突，比如端口/pid文件等，还有可能造成管理混乱（多个版本都在跑，回收或手动操作的时候不知道删哪个）。如何规避这些问题，我们选择了kubernetes来解决这些问题。
实现思路为：
1.默认的测试环境，代码全部从develop拉取，也可以查看当前develop分支的代码是否都正常运行；
2.分支环境，从功能分支进行拉取，非功能分支的都从默认环境获取；
3.分支环境的代码和develop的代码通过对ingress的编排实现，我们选用的时helm的charts进行实现的。
以上基本就能实现资源的发布。
那么资源的删除呢，也是需要通过helm来实现。在ingress中把功能分支的service更换成默认的service即可。
会带来的问题
多分枝测试避免了研发之间代码的相互覆盖（合并有冲突会提醒，只有解决了冲突之后才能完成合并，在此之前研发能够相互进行沟通，避免覆盖的发生），但是任何事情都有利有弊。
下面简单说说弊端：
1.需要程序进行适配：由于多分枝是通过不同域名进行实现的，需要给程序制定一个规则，让其访问对应域名下的程序；
2.需要对dns进行泛解析，如果放到公网会带来一些安全问题。
edit by cherrydot