构建高质量的持续交付体系

322 2023-08-25

持续交付测试自动化 DevOps

这是软件工程系列知识总结的第七篇文章，也是最后一篇。

前面的文章，聊了软件工程的基础理论、项目管理、需求分析、架构设计、软件测试以及线上服务的质量保障。其中在架构设计和线上服务的质量保障中，我也提到了关于持续集成持续交付相关的内容。软件工程的本质是用工程化的方法去规范软件开发，让软件开发项目可以按时保质完成的同时且成本可控。

交付的软件产品除了质量之外，交付效率对团队来说也是很重要的一点，而持续高效的交付高质量的软件产品，更需要一个高效的持续交付技术体系支撑。

理解持续交付体系

无论是保障质量，还是提升效率，都需要某些持续的能力来支撑他们。

这种支撑能力，可以看作是一种工厂化的流水线能力，业内通常将其统称为持续交付。

从质量保障的角度总体来说，我将其分为：CI持续迭代-CI持续集成-CD持续发布-CO持续运营-CM持续度量。

持续迭代（Continuous Iteration）

技术是什么呢？技术是工具，技术服务于架构设计，架构设计服务于产品，产品服务于业务，业务服务于商业。

这里的持续迭代，更多指的是业务或者需求上的一种可持续的变化，通过需求不断变化来驱动，持续迭代软件产品，为用户提供更好的服务，达成商业价值变现。

持续集成（Continuous Integration）

持续集成可以帮助技术团队更加频繁的将代码更改合并到共享分支或"主干"中。一旦对应用所做的更改被合并，系统就会通过自动构建应用并运行不同级别的自动化测试（通常是单元测试和集成测试）来验证这些更改，确保这些更改没有对应用造成破坏。如果自动化测试发现新代码和现有代码之间存在冲突，CI 可以加快修复这些错误的过程。

持续发布（Continuous Deployment）

这里的持续发布包括持续交付（Continuous Delivery）和持续部署（Continuous Deployment）。

完成 CI 中构建及自动化的测试流程后，持续交付可自动将测试通过的代码发布到存储库。持续交付的目标是拥有一个可随时部署到生产环境的代码库。在持续交付中，每个阶段都涉及测试自动化和代码发布自动化。在流程结束时可以快速的将应用部署到生产环境中。

对于一个成熟的 CI/CD 管道来说，最后的阶段是持续部署。作为持续交付的延伸，持续部署可以自动将应用发布到生产环境，持续部署在很大程度上都得依赖精心设计的测试自动化。持续部署意味着开发人员对应用的更改在编写后的几分钟内就能生效（假设它通过了自动化测试）。这更加便于持续接收和整合用户反馈。

所有这些 CI/CD 的关联步骤都有助于降低应用的部署风险，因此更便于以更快的节奏发布对应用的更改。不过，由于还需要编写自动化测试以适应 CI/CD 管道中的各种测试和发布阶段，因此前期建设需要很大的资源投入。

持续运营（Continuous operation）

应用在生产环境发布后，需要持续的跟踪线上质量、用户反馈建议以及线上可能发生的一些问题或者故障。

所有线上的用户建议、可能发生的问题或者故障，其实从本质来说，和交付质量都息息相关。因此这里提出了持续运营，就是提倡质量的把控、验证、度量即使到了生产环境，也需要持续不断的将这套机制运行下去。

持续度量（Continuous measurement）

脱离数据讲质量是空中楼阁，从需求质量到交付质量整个周期中，将每个阶段的要做的事情，出现的问题，发生的风险以及结果都进行可量化的记录展示，然后从中进行分析评估，找到不足之处。这就是持续度量，需要持续的投入。

持续交付优势

尽快暴露问题；
极大提升效率；
提升交付质量；
降低项目成本；

持续交付体系工具

工具名称	工具作用
Git、SVN、GitLab、Coding	统一的源代码管理工具
testNg、pytest、sonar、selenium	单元/接口/UI自动化测试工具
Jenkins、Go CD、Travis CI、Pipelines	持续集成和持续部署工具

持续交付的前提是整个研发测试发布流程要做到高度自动化。要实现持续交付，项目一般需要满足这些条件：

代码构建的过程可以反复高频进行，且每次构建结果是一致稳定的；
所有环境配置信息都存于源代码管理工具中（现在有配置中心组件如Nacos/Apollo）；
针对不同环境需要部署的代码包，需要自动编译和创建不同版本；
所有环境的构建编译部署发布步骤必须是自动化完成；

DevOps和持续交付的关系

持续交付要求代码可以反复高频的构建编译，代码包的测试部署发布需要自动化来完成，但传统的研发交付流程已经渐渐不适应当下的业务变化，因此才有了近几年的DevOps，甚至万物皆可Ops。

其实DevOps并不是一种岗位，可以理解为一种紧密协作的高效工作方式。无论是DevOps，还是所谓的TestOps，其实都指的是开发/测试和运维同学一起通过高效协作的方式来更快的构建、测试和发布软件。

DevOps的优势

以DevOps为例，当团队采取这种工作协作方式后，带来的好处如下：

软件的构建测试和发布过程高度自动化；
信息更加透明，交付质量更易于度量评估；
跨团队和跨职能协作的效率和氛围会更好；

要实践DevOps，意味着团队需要去做这些事：

构建自动化流水线系统，从构建测试到部署实现高度自动化；
建立完善精确的监控体系，尽力让信息变透明，数据可度量；
建立跨团队跨职能的沟通协作机制，形成团队的流程和文化；

DevOps工程师要做的事情

帮助团队建立持续交付工作流程和工具；
建立一套完善的监控报警系统和故障响应流程；
构建适用于团队研发交付流程的基础技术设施；
推动DevOps流程和文化在团队落地；

原文链接： http://mp.weixin.qq.com/s?__biz=Mzg2NDAwMjM1NQ==&mid=2247486247&idx=1&sn=911f17bdc66c01d35aa96fd4dac52b07&chksm=ce71437bf906ca6d5a4597d912b29ed4707853b316d92bdfa58a24cf890710b1864b6fe288dc#rd