Scrum：什么是持续集成、持续交付与持续部署？

常用术语——“持续集成”、“持续交付”和“持续部署”——被认为是敏捷软件开发。这些实践共享“持续”这一前缀，表明并支持增量集成（可交付的软件）以及结果的同时部署，而无需传统顺序开发中通常存在的延迟。在现代敏捷环境中，这些术语代表通过管道交付已完成的增量，从而实现自动部署作为升级。

持续交付的核心原则是通过短周期迭代逐步交付可工作的软件。换句话说，持续交付是一种短周期的实施方式，代码被频繁地开发、构建、提交、自动测试并部署。

持续交付

注意：

它并不要求短的发布周期——只需具备在代码就绪时随时提交新代码的能力。这样，开发人员可以每天多次更新产品，持续向用户交付价值。这通过高水平的测试和部署自动化实现。

Scrum 中的持续交付

在Scrum，固定时长的冲刺为1至4周，以测试、演示、冲刺评审、最终确认和发布结束。现在，我们希望发布得更加频繁——实现持续交付。

持续集成指的是要求开发人员每天多次将代码集成到中央仓库中的软件开发实践。除了并发和自动更新外，通过验证不同的提交时间，可以轻松发现潜在问题。

持续交付能够以可持续的方式安全、快速地将各类变更（包括新功能、配置更改、缺陷修复和实验）交付到生产环境或最终用户。

持续部署通过最小化编码与部署之间的时间间隔，进一步扩展了持续集成的方法。

Scrum 中的持续交付

人们常常认为，更频繁地发布软件意味着接受系统稳定性与可靠性水平的降低。然而，许多研究表明情况并非如此。事实上，一次只发布一个功能，能显著降低每次部署的风险。你的团队可以更快地将功能交付给客户，从而获得更快的反馈。持续交付管道为团队、业务和用户带来诸多好处：

根据2014年Xebia实验室调查报告，持续交付引领潮流，敏捷紧随其后。如下面图表所示，36.4%的受访者在2014年将DevOps列为关键举措。

软件项目倡议申请（2014年）

如果这听起来好得令人难以置信，请记住：持续交付并非魔法。软件发布需要极大的纪律性。在Scrum中，通过更频繁地发布较小的变更，持续交付实现了持续的日常改进，帮助每个人适应稳定且可预测的节奏，同时为应对变化留出空间。最重要的是，成功的发布成为共同的成功——每个人都可以一起庆祝。