我眼中的CICD

Posted 2021-03-13 wiswang

前言

本文基本就是 ThoughtWorks 文集中一键发布的读后感。

持续集成

持续集成也就是 CI，是敏捷软件开发中应用最广泛的技术实践，也是极限编程核心技术实践之一。CI 是指开发人员一旦将代码提交到版本控制系统之后，就进行构建，并运行一系列测试套件的过程。

产出物的管理

现在管理产出物一般使用开源的 Nexus3 或者商业的 artifactory。现在产出物比较推荐的形式就是容器镜像，遵循不可变基础实施这种技术实践，容器能极大的提高各个环境的一致性。还有需要注意的点就是产出物流过整个流水线，就是说各个环境使用的容器镜像都是一样的，如果在各个环境中有不一样的地方就通过配置管理解决，我推荐携程开源的 Apollo。

第一道门--提交测试

开发人员一提交代码，就自动触发持续集成的流程，比较推荐 git 的 pre-commit hook，通过自定义脚本的形式实现整个构建的过程，大家也可以看看持续集成僵死，这个构建过程应该包含所有的单元测试和一些冒烟测试，还有其他一些能证明其质量的测试。

这些测试的目的就是尽早失败，这也是质量内建的体现。开发人员必须等到这些测试全部通过之后才能进行下一个任务，从软件开发的角度，问题发现的越晚解决问题的成本就越高，这个过程通常是很快的。

只要提交测试通过了一般来讲就可以进行下一个任务了，但是有一个很重要的前提就是，这个阶段能发现绝大多数问题，如果很多问题是后面的阶段发现的，就说明需要加强一下提交测试了。这里推荐能极大提高这一阶段质量的极限编程工程实践 TDD 或者 TDD 的进阶实践 TCR。

最初我们把所有的单元测试作为提交测试，如果某个问题在后续阶段中经常出现，就需要为其编写测试并将其加入到提交测试中。

第二道门--验收测试

验收测试是根据用户故事的验收条件编写，用于证明我们的软件满足验收条件。用户故事需要遵循 INVEST（Idependent, Negotiable, Valuable, Estimable, Small, Testable）原则。我们的自动化部署系统只会部署那些通过所有验收测试的软件版本。

部署到生产

这个阶段要尽量做到自动化，自动化能消除很多错误的来源。

刚部署到线上的应用我们一般会运行一些简单的测试来证明该应用确实可用，部署阶段还可以选择蓝绿或者金丝雀发布，这种方法也被称为将部署与发布解耦。

后续的测试阶段

一直到验收测试完成，所有的测试都应该是自动化的，但是自动化在大多数项目中后续的步骤就不那么试用了。那些通过验收测试的版本可以选择性的进入人工验收测试阶段或者性能测试阶段，亦或是直接部署到生产。

验收测试的后续阶段之间的关系以及自动化的程度并不是问题，而如何提供并管理这些持续集成过程的脚本才是需要考虑的事情。

总结

本文介绍的是敏捷软件开发，在产品的刚开始阶段，我们会把需求分成一个个的用户故事，每完成一个用户故事就运行一次验收测试，每个用户故事又会分成很多任务，每完成一个任务就会提交一次，同时就会运行一次提交测试。总的来说用本文介绍的方法构建软件不但可以提高生产率，还可以提高交付质量，降低交付压力。