今天给大家分享下 devops 的相关内容。
之前我就是在老东家的工程效率部门做大仓的 devops 相关工作，来腾讯后也是在 CICD 平台做过一阵子开发。其实 devops 和我们是息息相关，只要你还在写代码，只要现网还有要维护的服务，那么就需要了解下 devops，能够帮助你利用现有的平台和工具提高服务质量以及交付速度。
开发模型进化史
那我们就开始吧，首先说说历史上的开发模型。
瀑布开发模型是比较早的开发方式定义，从计划制定到产品交付整个过程划分了几个主要阶段，制定计划、需求分析、软件设计、程序编写、软件测试和运行维护，主要涉及到的角色有 产品经理、开发人员、测试人员、运维人员。瀑布模型定义在当前阶段完成之后才能进入到下一个阶段，由此导致的问题就是阶段间相互依赖，到软件测试阶段代码才会集成，导致项目 delay 的风险极大。
所以在之后的敏捷开发就提出来了要尽早的集成代码，并且随着需求的动态变更，可以尽可能快地看到修改结果。但这样搞其实不管是开发测试还是运维产品，大家都比较累，属于是小迭代加快了，但是工作量依旧是那么多，只是在保证质量的前提下加快了交付速度。
那么就到了 devops 了，从字面意思理解，就是开发和运维放在一起了。在瀑布到敏捷开发的转变下，其实工作量并没有减少，所以这个交付速度的提升是有上限的。所以提出来用自动化的方式来加快从开发到部署上线期间的过程，从而达到干掉测试以及运维来提高交付效率。也就是，you build & test & deploy it。
测试自动化
接下来看看如何干掉测试，也就是测试自动化是怎么搞的。首先要说明的是测试并不能与质量挂钩，有测试不一定代表代码质量一定很好。这里我按测试规模从小到大排序，而越小的测试运行频率则越高，分别为 单元测试、接口测试、系统测试、全链路压力测试。
单元测试可以说是发现 bug 最有效的方式，它的测试对象为函数，一般是将函数抽象为黑盒，对给定的函数输入断言输出是否与期望相等。当然也可以做白盒测试，对函数中的各个步骤做验证。之前很火热的 TDD 测试驱动开发，也大多可以在单测上试试。不过单测好是好，也需要评估下是否需要，如果是需要一直迭代的项目，那写一次单测的收益会很高，反之如果是一次性的脚本类似工作的话，大可不必浪费时间。
接口测试主要测试对象为 api，也是断言给定输入下的输出是否为预期结果。从某种意义上来说，也算是一种 e2e 测试，一般都有对应的自动化测试脚本生成工具，工作量都在测试用例的编写上，mock 掉下游的依赖服务，一次编写，即可每次在变更后自动验证。
这里的系统测试指类似于前后端联调，在微服务比较多的情况下会涉及到很多模块，这种测试一般会针对测试指标或者功能单独划分环境进行手动测试。
全链路压测一般用不上，除非是像微信淘宝这种toc的服务，对qps和可靠性要求都非常高，一般都是手动测试，不过压测有对应的压测平台。
综上所述，将最常用到的单测和接口测试自动化，会很好的提高代码质量。除此之外呢还有基准测试啊模糊测试啊混沌测试，不过这些都是针对服务的某一方面，一般服务也不会用到的。
上云干掉运维
讲完测试，接下来需要干运维了，那就是上云。在没有上云之前，我们的服务需要部署在物理机上，如果是多台机器还得分别登录操作，所以之前用的最多的常用工具之一就是跳板机，在各种环境跳来跳去。手动创建配置文件，手动运行命令跑服务，所以很容易出问题。
上云后简单多了，通过脚本编译生成容器镜像，无需关心运行环境，一条命令就可以部署镜像到 k8s 集群中多个实例。配合已有的服务注册中心、远程配置中心、网关服务，除了需要手动创建网关路由外，即可全自动化部署，无需人工参与。
CICD 流水线
在讲 cicd 自动化前，特意加了一章，先来说说 git 工作流。git flow 有很多种，目前主要流行的还是 github flow，也最方便。首先它是基于主干开发，保证的是主干上一定是最新的代码。一般情况主干也会是生产环境运行的当前代码，也可以通过打标签来实现迭代发布。其次是使用功能分支作为一次性的开发分支，使用该分支创建 mr，然后使用压缩合并到主干，这样不会污染到主干的提交历史。
最后来说说 cicd 自动化流程。按环境区分，cicd的流程也是不一样的，一个完整的 cicd 流程包括 lint test build 以及 deploy。在我们创建功能分支后，就需要创建 pull request了，之后在该分支上的所有提交都会触发测试环境的 CICD 流水线，如果代码没有问题就会发布到测试环境（保证最小可行性以及尽早集成），接受cr，反复这一过程，直到测试没有问题，cr通过，那么就可以 merge 了。这里建议是每个 mr 负责人负责 merge，因为这里的修改提交人最清楚，提交信息也是负责人写最好。等到merge成功后就会触发正式环境的 cicd 流水线，完成功能交付。
今天给大家分享下 devops 的相关内容。
之前我就是在老东家的工程效率部门做大仓的 devops 相关工作，来腾讯后也是在 CICD 平台做过一阵子开发。其实 devops 和我们是息息相关，只要你还在写代码，只要现网还有要维护的服务，那么就需要了解下 devops，能够帮助你利用现有的平台和工具提高服务质量以及交付速度。
开发模型进化史
那我们就开始吧，首先说说历史上的开发模型。
瀑布开发模型是比较早的开发方式定义，从计划制定到产品交付整个过程划分了几个主要阶段，制定计划、需求分析、软件设计、程序编写、软件测试和运行维护，主要涉及到的角色有 产品经理、开发人员、测试人员、运维人员。瀑布模型定义在当前阶段完成之后才能进入到下一个阶段，由此导致的问题就是阶段间相互依赖，到软件测试阶段代码才会集成，导致项目 delay 的风险极大。
所以在之后的敏捷开发就提出来了要尽早的集成代码，并且随着需求的动态变更，可以尽可能快地看到修改结果。但这样搞其实不管是开发测试还是运维产品，大家都比较累，属于是小迭代加快了，但是工作量依旧是那么多，只是在保证质量的前提下加快了交付速度。
那么就到了 devops 了，从字面意思理解，就是开发和运维放在一起了。在瀑布到敏捷开发的转变下，其实工作量并没有减少，所以这个交付速度的提升是有上限的。所以提出来用自动化的方式来加快从开发到部署上线期间的过程，从而达到干掉测试以及运维来提高交付效率。也就是，you build & test & deploy it。
测试自动化
接下来看看如何干掉测试，也就是测试自动化是怎么搞的。首先要说明的是测试并不能与质量挂钩，有测试不一定代表代码质量一定很好。这里我按测试规模从小到大排序，而越小的测试运行频率则越高，分别为 单元测试、接口测试、系统测试、全链路压力测试。
单元测试可以说是发现 bug 最有效的方式，它的测试对象为函数，一般是将函数抽象为黑盒，对给定的函数输入断言输出是否与期望相等。当然也可以做白盒测试，对函数中的各个步骤做验证。之前很火热的 TDD 测试驱动开发，也大多可以在单测上试试。不过单测好是好，也需要评估下是否需要，如果是需要一直迭代的项目，那写一次单测的收益会很高，反之如果是一次性的脚本类似工作的话，大可不必浪费时间。
接口测试主要测试对象为 api，也是断言给定输入下的输出是否为预期结果。从某种意义上来说，也算是一种 e2e 测试，一般都有对应的自动化测试脚本生成工具，工作量都在测试用例的编写上，mock 掉下游的依赖服务，一次编写，即可每次在变更后自动验证。
这里的系统测试指类似于前后端联调，在微服务比较多的情况下会涉及到很多模块，这种测试一般会针对测试指标或者功能单独划分环境进行手动测试。
全链路压测一般用不上，除非是像微信淘宝这种toc的服务，对qps和可靠性要求都非常高，一般都是手动测试，不过压测有对应的压测平台。
综上所述，将最常用到的单测和接口测试自动化，会很好的提高代码质量。除此之外呢还有基准测试啊模糊测试啊混沌测试，不过这些都是针对服务的某一方面，一般服务也不会用到的。
上云干掉运维
讲完测试，接下来需要干运维了，那就是上云。在没有上云之前，我们的服务需要部署在物理机上，如果是多台机器还得分别登录操作，所以之前用的最多的常用工具之一就是跳板机，在各种环境跳来跳去。手动创建配置文件，手动运行命令跑服务，所以很容易出问题。
上云后简单多了，通过脚本编译生成容器镜像，无需关心运行环境，一条命令就可以部署镜像到 k8s 集群中多个实例。配合已有的服务注册中心、远程配置中心、网关服务，除了需要手动创建网关路由外，即可全自动化部署，无需人工参与。
CICD 流水线
在讲 cicd 自动化前，特意加了一章，先来说说 git 工作流。git flow 有很多种，目前主要流行的还是 github flow，也最方便。首先它是基于主干开发，保证的是主干上一定是最新的代码。一般情况主干也会是生产环境运行的当前代码，也可以通过打标签来实现迭代发布。其次是使用功能分支作为一次性的开发分支，使用该分支创建 mr，然后使用压缩合并到主干，这样不会污染到主干的提交历史。
最后来说说 cicd 自动化流程。按环境区分，cicd的流程也是不一样的，一个完整的 cicd 流程包括 lint test build 以及 deploy。在我们创建功能分支后，就需要创建 pull request了，之后在该分支上的所有提交都会触发测试环境的 CICD 流水线，如果代码没有问题就会发布到测试环境（保证最小可行性以及尽早集成），接受cr，反复这一过程，直到测试没有问题，cr通过，那么就可以 merge 了。这里建议是每个 mr 负责人负责 merge，因为这里的修改提交人最清楚，提交信息也是负责人写最好。等到merge成功后就会触发正式环境的 cicd 流水线，完成功能交付。