虽然，读者朋友可能觉得自己已经理解这些概念了，但是，还是希望读者读完。笔者从权威的书上将这些概念的定义摘抄下来，最后给出笔者对于“持续”的理解。

构建（Build）：

一次构建不止是一次编译（或者动态语言中的某种称谓）。一次构建可能包含编译、测试、审查和部署以及其他一些事情。一次构建是将源代码放在一起，并验证软件可以作为一个一致的单元运行的过程。摘自《持续集成》

其实构建过程中还可以包括测试、部署。这点可能和很多人的理解有出入。这里就会有疑问了，既然构建中包括了部署，那么持续构建与持续部署又有什么关系？笔者是这样理解的，因为软件系统是需要部署了，才能测试的，所以，为了在构建过程加入测试，就必须引入部署。

部署（Deployment）：

部署是一种技术领域的操作，也就是说从某处获取软件包，并按照预先设计的方案将其安装在计算节点上，并确保系统可以正常启动，但它并不定意味着“必须包含业务功能的发布或交付”。摘自《持续交付2.0》

交付（Delivery，也被称为发布）：

是一个业务决策活动，通常也被称为“发布”，也就是说，如果将新的构建的特性交到客户（用户）手中，用户就可以看到并使用它们。摘自《持续交付2.0》

我们可以将代码部署上生产环境，但是我们可以通过某种技术手段，让用户看不到，也不能使用它。这就是只部署，但不交付。部署与交付的差异在于部署是技术端操作、交付是业务端决策。

这里，读者可能又有疑问了：未完成的功能，可以部署上生产环境吗？笔者的回答：是的。前提是你能控制该功能是否对用户可见。这称为功能开关。

持续集成（CI）：

它是一种软件开发实践，即团队的成员经常集成他们的工作。通常每个成员每天至少集成一次——这导致每天发生多次集成。每次集成都通过自动化的构建（包括测试）来验证，从而尽快地检测出集成错误。摘自《持续集成——软件质量改进和风险降低之道》

注意，持续集成中包括了构建与测试。所以，我们在行业里经常听到的“持续测试（CT）”又是什么呢？这是笔者的疑问。

持续交付1.0（CD1.0）：

持续交付是一种能力，也就是说，能够以持续方式，安全快速地把代码变更（包括特性、配置、缺陷和试验）部署到生产环境上，让用户使用。摘自《持续交付2.0——业务引领的DevOps精要》

持续交付2.0（CD2.0）：

“持续交付2.0”建立在“持续交付1.0”的“可持续地快速发布软件服务”及精益创业的“最小化可行产品”两种理念基础之上，强调要以业务为导向，从一开始就业务问题进行分解，并通过不断的科学探索与快速验证，减少浪费的同时，快速找到正确的业务前进方向，简称为“双环模型”。摘自《持续交付2.0》

持续集成、持续部署、持续交付之间是什么关系呢？笔者认为是：持续交付的过程会包含持续部署，持续部署的前提是持续集成。把集成与部署组合到一起，并完全自动化，这个自动化的过程，称为部署流水线。持续交付1.0强调的是交付的效率，持续交付2.0则除了强调交付的效率，还强调交付的效果。

最后，我们来谈谈“持续”，笔者是这样理解的：

所谓的“持续”，就是指经常地做。而“经常”是一个相对的概念。对于每年交付一次的软件系统，优化成每个月一次，也算是“持续”了。另，“持续”代表的是一种能力。有能力持续交付，但是业务不一定允许。要实现“持续”的能力，自动化就成为了必然的选择。

说到了“持续”就不得不说“持续改进”。上文说过，持续指的是经常做。持续改进的意思是经常做改进。持续改进的极限是無時不刻地在改进。那么，如何让一个团队无时不刻地进行改进呢？这是一个非常大的话题。关注笔者的公众号，将来会讲到。

Last modified on 2020-09-16