本文详细介绍了持续构建、持续测试、持续集成、持续部署和持续交付的概念。构建不仅包括编译，还可能涉及测试和部署。部署是技术操作，而交付是业务决策。持续集成强调团队频繁集成工作，包含自动化的构建和测试。持续交付关注将代码变更安全、快速地部署到生产环境。持续部署是持续集成的延伸，自动化部署是其关键。文中指出，“持续”意味着频繁执行，而实现这一能力往往依赖于自动化。最后，作者提到持续改进的重要性，并鼓励读者深入探讨相关主题。
虽然，读者朋友可能觉得自己已经理解这些概念了，但是，还是希望读者读完。笔者从权威的书上将这些概念的定义摘抄下来，最后给出笔者对于“持续”的理解。
构建（Build）：
一次构建不止是一次编译（或者动态语言中的某种称谓）。一次构建可能包含编译、测试、审查和部署以及其他一些事情。一次构建是将源代码放在一起，并验证软件可以作为一个一致的单元运行的过程。摘自《持续集成》
其实构建过程中还可以包括测试、部署。这点可能和很多人的理解有出入。这里就会有疑问了，既然构建中包括了部署，那么持续构建与持续部署又有什么关系？笔者是这样理解的，因为软件系统是需要部署了，才能测试的，所以，为了在构建过程加入测试，就必须引入部署。
部署（Deployment）：
部署是一种技术领域的操作，也就是说从某处获取软件包，并按照预先设计的方案将其安装在计算节点上，并确保系统可以正常启动，但它并不定意味着“必须包含业务功能的发布或交付”。摘自《持续交付2.0》
交付（Delivery，也被称为发布）：
是一个业务决策活动，通常也被称为“发布”，也就是说，如果将新的构建的特性交到客户（用户&
最低0.47元/天 解锁文章
5275
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
