持续部署的优点是什么？

Question

持续部署需要大量的努力，而不仅仅是持续集成所需的工作。

• 由于每个更改都对应于一个发行版(或多或少)，用于手动测试的时间和资源要少得多。它们几乎需要完全被自动化测试所取代，在某些情况下，自动化测试很难做好，而且可能需要广泛开发自动化工具。(CI也鼓励这样做。但在CD中，这是绝对必要的，错误的破坏性要大得多。
• 由于部署的频率要高得多，因此在部署期间允许的停机时间或中断要少得多。它需要更好的自动化架构管理和部署策略。

持续部署是流行的，因此显然有一些巨大的好处来抵消这些成本。

连续部署的优点是什么？

(具体来说，我很好奇连续部署所特有的好处，这并不是单靠持续集成就能得到的。)

Answer 1

连续部署或连续交付在web服务和SaaS应用程序中非常常见。亚马逊，脸书，吉顿，谷歌.他们一直在部署。一些运营商每天为每个定义非常狭窄的服务部署少量甚至几十个更新。我甚至不确定你能很容易地计算出亚马逊和谷歌这样的大型商店每天在他们整个产业范围内的总部署事件数量。

为什么要这样做？

1. 用户很早就掌握了修复、更新、改进和新特性。“修补程序”和升级周期被集成到日常使用中，而不是在主要版本中划分。
2. 内部经理(个人业务、营销活动等的产品所有者)看到他们的项目与组织中的所有其他项目脱钩，因此，当客户准备就绪时，就可以立即将其呈现给客户，而不是依赖于许多其他变量或“发布培训”。
3. 有较少的“抛出许多新的功能，修复，等等一蹴而就”现象。用户和支持团队都会讨厌“发布日”(Release)，因为这是因为大多数错误、新的破坏、未知的新特性/行为等都会在这一天显现出来。连续部署将这些发布瞬间扩展到许多非常小的块中。(这可能有其自身的缺点，但痛苦的分布更为均匀。)
4. 为了敏捷。各种敏捷技术都需要用户的反馈循环。如果你有几个主要的利益相关者，你可以问他们“你认为这个想法怎么样？”亚马逊将如何做到这一点？举办世界上最大的焦点小组？不，他们出版了又走了。他们得到的反馈是基于事情的进展，基于详细的分析，而不是直接的客户反馈。内容密集的组织似乎特别有可能成为具有基于分析的反馈循环的活跃的出版商。
5. 用于A/B测试或其多元等效项。“靠你的裤子”很难管理成千上万种产品、产品选择和产品可能性的复杂业务。它们需要由数据驱动。虽然与前一点有关反馈循环，连续交付使房间必须不断测试多种选择在现实世界实验室的客户行为。如果没有不断提供和衡量变化的能力，测试不同假设和选项的机会就会少得多，因此收集有价值的业务分析的机会就少得多。
6. 与“版本漂移”的噩梦作斗争。那些运行面向网络的服务和应用程序的人非常擅长滑流和管理版本漂移--在这种情况下，可能同时使用多个逻辑版本的应用程序。但是，即使是那些擅长运行十几个或两个不同版本的人，也不希望存在200、2000或20000种不同的版本配置。配置管理的麻烦和支持成本变得太大了。不断地部署新代码(和旧版本)，将实际使用的版本的数量保留到沉闷的咆哮中。
7. 建立最佳实践和组织适应性。就像您引入自动化测试技术或连续积分时一样，这不是一个简单的更改。你不只是到处轻拍。你必须坚持测试的想法，或者测试所有的东西。你必须精通它，在这方面要有纪律，并确保你有正确的工具、环境和文化，才能在这种运作方式下变得高效和有效。Web属性由于其庞大的客户群和不断需要部署新内容、新服务和补丁/更新，不仅需要进行大量的更新，而且还必须非常擅长于随时更新。这导致像Netflix这样的商店对他们的员工和流程进行持续的“构建-烘焙-部署”循环--这不仅是一个技术特性，而且也是他们开发和运营文化的一部分。

虽然连续部署在面向互联网的应用程序中很流行，但没有什么是完全连续的。总是有内部服务、容量移动、组织准备状态和其他基础结构更改，这些更改可能会延迟或成为各种版本的先决条件。即使对于不断提供许多更新的服务，为了技术、营销、培训和支持目的，当出现“大”变化时，仍然可以方便地将这些更改作为一个包进行呈现、提升、培训和部署。

有些更改会改变应用程序的性质或界面。在下一次页面重新加载或AJAX调用时，让它以一种方式工作，然后让它工作，看起来也不一样，这是不明智的。有些特性或元素只有在其他特性可用的情况下才有意义。最后，许多大的更改需要组装不同的后端服务，或者需要不同的数据模式。在这些情况下，总是持续部署是没有意义的。限制游戏中的“主要版本”的数量可以帮助用户消费和运营商有效地提供服务。因此，即使是在最具侵略性的情况下，它也是“偶尔的颠簸”。