工程实践 穿越CICD那些事

开发现状

• 最普遍的问题是，很多企业忽视了包括开发者测试、自动化验收测试、持续重构等工程实践的开展。
• 这些企业有独立的工具部门（如工具平台部/DevOps平台部/ DevOps运营团队），一个很大的误区是，似乎CI/CD只是工具部门的事，他们专注于工具平台本身建设，持续地为平台添加新功能、制定统一的流水线规范，也有漂亮的构建结果报告等，但开发团队却很少开展开发者测试、自动化验收测试，也没有严格要求的持续集成纪律、没有持续重构等。

什么是CI/CD？

• CI在20多年前就有的实践，是指每天将代码做集成和测试验证，持续反馈
• CD更多关注自动化部署，以便于快速获得用于自动化测试、非公能测试、手工测试、演示、生产等运行环境

企业在CI/CD上存在的误区

• 要么只关注CI，要么只关注CD
• 例如，某公司可以做到代码及时编译生成部署包并在K8S上部署，但却没有做任何自动化测试。

具体要怎么做？

需要从以下4个方面做实：迭代式开发、开发者测试/测试驱动开发、自动化验收测试、自动化部署

迭代式开发

• 一次迭代，产品经理（PO）、开发人员、测试人员三条线并行
• 产品经理输出需求、开发人员实现、测试人员测试
• CI/CD则是三方互相协作的基础平台，每天将代码持续集成、持续部署、持续测试、持续反馈。

开发者测试/测试驱动开发

• CI/CD的基础工程活动是自动化测试，自动化测试的主要参与者不是测试人员，而应该是开发人员，他们做的测试称为开发者测试
• 开发者测试更多的是指测试驱动开发（TDD）这个实践，本质在于如何快速高效地写代码，它的核心思想是“写一点测一点”，先定一个小目标（也就是先写一个测试用例），然后驱动代码实现，测试，重构，然后再定下一个小目标，如此反复
• 单元测试、组件测试、契约测试、接口测试都是开发人员要做的，与之相关的实践是测试驱动开发，开发人员每天提交的代码也应该包括测试代码，持续地在CI/CD流水线中运行。
• 测试人员要做的自动化测试是验收测试，也称为功能测试或系统测试，一些公司也将接口自动化测试作为功能测试的一部分。另外，非功能测试也是测试人员所关注的。
• 要将测试工作量重点投在单元测试和组件测试上（开发者测试）

自动化验收测试

• 验收测试包括功能测试和系统测试
• 做自动化测试是门技术活，编程能力是基础。验收测试的工具有很多，如Selenium、RF等，下图是Robot Framework实现的验收测试脚本（用户正常登录功能），底层用到了Selenium驱动UI测试。
  
• 需求（用户故事）的质量也是阻碍自动化验收测试的重要因素，需求没有验收标准就急匆匆进入开发，这就没有了“完成标准”这个大目标

自动化部署

• CD的核心能力是自动化部署，很多公司已经将应用部署在公有云或私有云上。
• CI/CD实践中，常见的，是通过构建输出容器镜像，然后通过自动化的部署脚本一键部署到K8S/K3S中，参加下图
  

开发者测试工具选择大致分成4类

1. 测试框架：如xUnit、TestNG、Spring Test、pytest、GoogleTest；
2. 断言库：如Hamcrest、chai；
3. Mock工具：如Mockito、JMock、EasyMock；
4. 测试覆盖率工具：如Cobertura、JaCoCo。

@韩德恩业务敏捷