devops测试分层（从DevOps持续交付到灰度发布）
devops测试分层（从DevOps持续交付到灰度发布）持续部署和持续交付再简单来说如果一个软件开发涉及到SIT，UAT和生产三个环境。那么仅仅在SIT环境阶段涉及到重新编译，构建，打包等操作。而在后续两个环境仅仅是环境迁移，持续部署，不会再涉及到具体的编译构建。持续集成一般涉及到重新的编译构建过程，而持续部署则不涉及到重新编译构建，而是拿已有的构建完成的部署包后镜像文件进行，即持续部署是基于二进制文件进行交付的。你在测试阶段编译构建的包最终就是部署到生产环境的包，唯一变化的就是配置文件和环境变量，确保你测试通过的内容不会因为重新编译，打包的原因引入新的Bug。在CI/CD里面持续部署概念相当重要，就是要说明后期SIT，UAT各个测试环境间的迁移，测试环境朝生产环境的交付都是基于二进制部署文件或容器镜像进行的。
在谈DevOps的时候我更多谈的是CI/CD持续集成和持续部署，今天重点谈下持续交付和灰度发布方面的内容。在谈这个之前，还是准备先将前面几点的区别进行阐述。
CI/CD和持续交付首先还是先谈下持续集成，持续部署和持续交付几个概念的区别。
对于CI持续集成一般来说是指完整的软件产品从源代码获取开始的编译，构建，打包，部署完整过程。而对于部署来说则是一个独立的动作，即将一键构建打包好的部署包或二进制的镜像文件，找到一个具体的中间件或容器资源，并将其部署下去。
也就是说。
持续集成一般涉及到重新的编译构建过程，而持续部署则不涉及到重新编译构建，而是拿已有的构建完成的部署包后镜像文件进行，即持续部署是基于二进制文件进行交付的。
你在测试阶段编译构建的包最终就是部署到生产环境的包，唯一变化的就是配置文件和环境变量，确保你测试通过的内容不会因为重新编译，打包的原因引入新的Bug。
在CI/CD里面持续部署概念相当重要，就是要说明后期SIT，UAT各个测试环境间的迁移，测试环境朝生产环境的交付都是基于二进制部署文件或容器镜像进行的。
再简单来说如果一个软件开发涉及到SIT，UAT和生产三个环境。那么仅仅在SIT环境阶段涉及到重新编译，构建，打包等操作。而在后续两个环境仅仅是环境迁移，持续部署，不会再涉及到具体的编译构建。
持续部署和持续交付
对于持续交付这个概念，交付的重点一个是面向生产环境，一个重点是面向最终的用户。那么是否生产环境的持续部署就是持续交付？
在早期，实际上生产环境持续部署就是持续交付，因为部署和交付两个过程并没有分离或解耦。也就是说生产环境部署完成后最终的用户马上就可以使用的。
但是到了当前阶段，特别是在云原生和DevOps下，生产环境部署完不一定就马上交付给用户使用，比如生产环境有A一套环境，但是在生产环境部署的时候我并没有讲A覆盖而是重新部署了一套B环境。
这个时候部署动作已经完成，但是交付动作还没有完。只有当我们将用户最终访问的流量切换到B环境的时候，B环境才算完成了对用户的最终交付动作。
云原生不可变基础设施在谈云原生的时候谈到，云原生包括了一系列的管理实践和技术实践，而里面的技术实践包括了容器、ServerMesh服务网格，Serverless无服务器，微服务、不可变基础设施和声明式API。这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。
里面谈到一点不可变的基础设施。
我在前面的文章对这个技术要素谈得比较少。不可变基础设施里的“不可变”非常类似于程序设计中的“不可变”概念。程序设计中不可变变量（Immutable Variable）就是在完成赋值后就不能发生更改，只能创建新的来整体替换旧的。由于具有这样的特性这种变量可以在并发环境下安全的使用。对于基础设施的不可变性，最基本的就是指运行服务的服务器在完成部署后，就不再进行更改。
我们还是举个容器云的例子来说明下。
比如一个软件程序V1.0版本，我们制作了一个容器镜像，并将其通过kurbernetes部署下去形成容器实例。那么到了V1.1版本，我们是否对这个容器实例进行变更和修改？
实际情况并不是如此。
对于V1.1版本的部署，并部署对V1.0版本容器实例进行修改，而是新部署了一个新的V1.1版本的容器实例，在部署完成后将用户访问切换到新的V1.1版本上面。
也就是说V1.0版本的容器实例一旦生成并使用，其本质就是不可变的，只能是创建的新的容器来替代旧的，而不是直接对旧的容器进行修改。
在传统IT架构下不可变基础设施的设想是难以实现的，开发人员总是需要在服务器上对运行环境做一下持续的更改，如：系统升级，配置修改，补丁等。在许多手动修改之后，服务器的不同配置的重要性或必要性变得不清楚，因此更新或更改任何配置可能会产生意想不到的副作用。而进入到容器云阶段后，由于容器本身是在传统IaaS资源的上层抽象，其本身具备了容易创建，容易快速销毁等关键特性，这也让不可变基础设施概念成为可能。
灰度发布
在谈灰度发布前，还是得讲下传统的蓝绿发布。蓝绿发布不算算严格意义上得灰度发布，但是确是持续交付得一种关键类型。
蓝绿发布简单来说就是会存在A和B两套部署的生产环境，但是对于用户访问来说仅仅有一套对外提供能力。如果当前应用是V1.0版本运行在A环境，那么当我们需要发布V1.1环境得时候实际是将V1.1版本得内容部署到B，在B环境先进行验证确认，确认完没有问题后停止使用A环境，将A环境得用户访问和流量全部切换到B环境。
也就是说蓝绿发布是蓝绿发布是要么黑，要么白，同时只有一个环境对外提供用户访问，并在一次完成环境切换。
那么对于灰度发布，首先看下灰度发布的简单定义。
灰度发布（又名金丝雀发布）是指在黑与白之间，能够平滑过渡的一种发布方式。在其上可以进行A/B testing，即让一部分用户继续用产品特性A，一部分用户开始用产品特性B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。
灰度期：灰度发布开始到结束的这一段时间，称为灰度期。
简单来讲，灰度发布主要就是涉及到老版本和新版本间的平衡过渡问题，暂且我们定义为老版本A和灰度版本B。用户的访问流量是在一个时间周期内逐步从A版本过渡到B版本。也就是说A，B两个环境实际在灰度期是同时对外提供用户访问服务的。
这也是灰度发布和蓝绿发布的一个关键区别。
实际上灰度发布需要考虑两个问题。其一就是新的灰度版本如何通过增量的方式逐步完成整个集群的部署过程，在这个过程中新版本节点不断增加，老版本阶段逐步下线。其二就是如何根据指定的策略，将特定的用户路由到灰度版本上，并最终完成全量切换。
新的灰度版本增量发布和部署（灰度版本部署策略）
如果一个开始我们的软件部署到N台服务器的中间件集群中，那么实际灰度版本的部署，可以设置先部署到N台中的1台或n台。在灰度版本测试通过后或者说在灰度期完成后，则需要支持对所有的中间件集群容器进行全量更新。实际上我们看到灰度发布就是在发布的时候从最早的{A}版本，变化到{A B}版本，再变化到{B}版本的一个演进过程。
基于用户特征值的访问路由（路由分发策略）
第二个问题即基于用户特征值的访问路由，比如我们常见的基于用户ID的尾数进行路由，把尾数为奇数的先路由到灰度版本，或者根据IP地址范围进行路由，将某个特定IP地址域的路由到灰度版本，还可以根据用户等级进行路由，将某些等级的用户路由到灰度版本。
这里的路由实际上就是一个类似Nginx来实现的路由转发策略，只是这个策略要做到相当的灵活。其一是可以根据前面讲的一些固定场景进行路由策略配置，其二是路由转发知道哪些后台服务器是打了灰度发布标签的，然后才能够将符合特征值的请求路由转发到已经部署了灰度版本的服务器上面。
当前对于灰度发布的路由分发均衡有很多开源实现可以参考，其中在和容器化部署结合的时候一个关键点就是，首先将版本增量部署到Docker容器中，在部署完成后会生成IP地址信息，这个IP地址 灰度标签一起存储到Nginx的路由配置和请求转发表中。当用户请求符合特征值后，则路由到对应的灰度版本中。
kurbernetes 中灰度发布通过负载均衡网络实现。服务的负载均衡依赖于服务的标签，新发布的服务既包含新的标签标识新的服务又包含之前版本标签(旧标签)，旧标签被用于负载均衡网络发现。新版本服务运行稳定后，进行扩容，旧版本缩容，实现了灰度发布。
因此可以看到如果需要复杂的灰度发布策略，实际还是需要进一步在Kurbernetes的基础上进行定制，比如基于用户优先级灰度，基于子组织进行灰度发布等。
涉及到数据库的灰度发布
对于数据库的灰度发布，由于涉及到持久化后的数据，因此相对麻烦，特别是如果拆分为两套数据库的话很难进行处理和两套数据库的同步。
因此建议是非特殊场景基本都不要启用数据库的灰度发布。对于数据库的版本更新问题，最简单的方法就是尽量不要删除表和字段，而是扩展新字段，同时确保数据表增加字段不对应用层的程序造成影响。
灰度发布下的回滚
对于灰度发布下的回滚，同样是两个方面的内容。
其一是需要将切换到B版本的用户访问流量再重新切换到A版本上面，其次是对于新版本的容器节点进行缩容，同时对老版本的容器节点重新进行扩容。但是在这种回滚场景下，数据库一般不要去做相关数据库结构的回滚操作。
整个回滚过程应该做到完全自动化完成。但是最终回滚的触发除了本身发布的新版本系统级异常外，还应该能够支持通过外部人工执行相应的命令行操作来触发整个回滚操作。
如果是A版本已经完全切换到B版本。但是发现了B版本在运行过程中功能满足或性能上存在明显问题，这个时候就需要将B版本全部回滚切换到A版本，在这种场景的回滚本身就是一种全节点和全流量的切换，不再需要考虑灰度问题，类似蓝绿发布时候的回滚操作。
