基于移动云CC-OPS平台进行灰度发布的思考

公司近期在推进产品部门使用移动云CC-OPS平台进行灰度发布实践，其提供的官方方案主要基于应用发布自动化模块（ADA），官方方案如下所示：
1、新增模板集
创建Deployment类型test-app-v1和test-app-v2，设置镜像版本为变量，然后陆续创建service类型test-app-svc-v1和test-app-svc-v2，ingress类型test-app-header-v1和test-app-header-v2

2、编排灰度发布任务模板
①添加第一个节点，发布正常版本和灰度版本资源文件
②添加第二个节点（只更新deployment，全部发布最新版本的镜像）
③创建任务实例并执行

3、执行灰度发布流水线
①第一个节点完成新旧版本的发布后，任务暂停，等待人工测试介入
②测试完成后，人工点击更新，完成全量更新

经过讨论，该方案切流步骤并不推荐。在灰度切流阶段，该方案只是将灰度版本和原始版本的deployment资源文件的镜像文件全改为灰度版本进行了全量发布，看似灰度服务全量发布了，实际上线上还是存在两套服务，包括各自的ingress资源文件和service资源文件，只是最终导入的pod是一样的。这种方式不太规范，不仅会使线上资源文件混乱，也会产生安全性问题。

合理的切流方案如下：
①新版本全量发布：
如果灰度版本测试通过，则修改非灰度版本Ingress资源文件并执行，将所有流量默认到新版本，新版本全量发布。<