本文来自微信公众号“开源云中文社区”。
不久前，大多数组织使用瀑布法开发软件，并在光盘等介质上发布软件。对敏捷、快节奏的发布周期没有真正的业务需求，公司对不断变化的需求反应缓慢。
对于许多软件公司来说，大发布仍然是常态。主要版本发布仍然是营销重点。而且这些版本仍然包含客户必须忍受的漏洞，直到明年的主要新版本。
然而，许多软件开发团队采用了持续交付（CD）或渐进交付（PD）方法，立即将代码交付到生产环境中。新的功能和修复程序会随着频繁的更新自动出现在用户的设备上。用户今天抱怨的bug甚至可能在下周修复，不久后就会被遗忘。
采用CD和PD的公司的部署更无聊。当这些软件制造商快速修复漏洞并频繁添加新功能时，客户会感到高兴，发布的版本也不会有戏剧性的变化。
自动化的重要性
保持软件处于可发布状态对CD至关重要。自动CD管道让你有信心提高功能交付的节奏，并从快速反馈循环和高代码库质量中获益。问题往往很早就出现了，研究将CD与提高生产力联系起来。
如果没有自动化的CD，部署是有风险的。不一致的流程和手动步骤成为痛苦的根源。通常，同一团队中的两个开发人员部署同一软件的方法不同。开发人员根据个人编写的脚本执行许多手动部署。当他们转到其他工作时，对脚本的知识和维护脚本的能力将与他们一起离开。剩下的开发人员继续部署脚本，对它们了解甚少或根本不了解——这会导致灾难。
相比之下，标准化和自动化生产可以确保你最大限度地延长产品的正常运行时间，并提供想要的产品。回滚也是最好的自动化操作，因此，部署团队不需要在出现问题后的凌晨进行修补，只需按下一个按钮，就可以返回到稳定的版本。这使团队有信心以更高的频率部署。
毕竟，这里的整体理念是自动化就是可靠性。因此，我们的目标是实现更多的自动化，并最大限度地减少部署中具有挑战性的手动方面。
让我们来看看如何打破单体，为CD实现一些最佳实践。将你的软件交付从一个有风险、有压力的事件变成一个无聊的日常事件。
打破单体
让部署变得枯燥的一种方法是避免将单体应用程序移动到云中。相反，将其拆分为微服务。这项任务值得投入时间，而且非常简单，因为你不必一次完成所有任务。
首先将整个应用程序放在Docker容器中完成任务。然后，逐渐将各个部分拆分为单独的微服务，每个服务都在自己的容器中运行。这种碎片化本身并不能使部署变得更好，但它有助于确保应用程序由易于开发、测试、控制和部署的较小部分组成。
软件工程师会感谢你，因为他们不太担心修改代码库，因为他们害怕在其他地方破坏某些东西。自给自足的微服务是工作的乐趣。
微服务还有许多其他好处。部署更小，更易于管理。征服这一单体也使团队能够在适合他们的时间进行部署。再也不用等单体做好生产准备了。即使这种成就感也会产生令人鼓舞的效果。
除了单体架构之外，一些公司还开发单体部署脚本。在选择部署工具时，重要的是确保它具有有助于避免此问题的功能。一些部署工具，如Spinnaker，允许组合由其他命令管道组成的命令管道。这鼓励了重用和模块化，这有助于避免开发单一流程。
另一种新兴模式是声明式部署定义。在该模式中，你声明了代码必须遵循的一组需求，但不提供逐步的过程。这些需求列表往往更简单，并且能够随着时间的推移而演变，同时避免脆弱的单体。
使用Kubernetes部署微服务
一旦你将应用程序放入Docker容器中的微服务中，你需要一种管理它们的方法。Kubernetes是编排、扩展和管理此类流程的常用工具之一。它监视容器的运行状况，并对节点故障和其他事件做出反应。
帮助部署顺利运行的一个技巧是使用YAML或JSON文件配置Kubernetes。如果需要，不要忘记将这些配置文件保存在源代码管理中，以便进行恢复。配置文件也有助于检测配置漂移，其中一个团队出于可能只有他们知道的原因进行调整，并将其存储在一张纸片上。
充分利用可用于制定标准的技术可以使流程顺利运行。使用许多技术可能会让人望而生畏，但通过将其与第三方服务结合起来，你可以利用各种软件包的强大功能无缝地构建CD管道。你可以构建护栏，以确保团队实施最佳实践、弹性、安全性和合规性。
引入部署检查也是保持消费者信心的关键。没有人想损害品牌声誉，但任何部署都有可能推出不合格的产品。因此，在投入生产之前，组织有任务清单和最终保障措施。部署到生产是一个地方，你应该考虑自动化产品遵守公司的政策和合规性。
例如，一些公司可能有“责任分工”策略：编写代码的人不能是部署代码的人。你可以依靠监控、审计跟踪和警报来捕获违反策略的行为，但这些手动步骤容易出现弱点。自动化系统可以实现这些检查，并在出现问题时停止部署，你可以轻松地将这种策略强制添加到管道中。
当自动化CD时，你不再需要等待高级开发人员度假回来部署。公司文化发生了变化，从分散的团队独立工作到跨团队授权，使每个人——从开发人员到运维人员，以及其他人——都觉得自己是流程的重要组成部分。此外，工程师不必担心在几个小时后被寻呼（因为有人在部署前发现了错误）。
出了问题时
当你准备部署时，如果你推出的代码出现问题，高级部署策略可以帮助你限制暴露（通常称为限制爆炸半径）。
金丝雀等技术可以将部署限制在特定的目标用户数量，分析结果，然后在更大范围内进行，从而避免灾难性的失败。
另一种策略是蓝绿（Netflix称之为红黑）。通过这种方法，你可以维护两个尽可能相似的生产环境。你在其中一台服务器上对一个新版本执行测试的最后阶段，一旦它稳定下来，你就切断了它的所有流量。如果发现任何问题，可以自动将流量推回到另一台服务器（立即回滚）。使用这种方法，可以避免代价高昂的停机。
随着部署时间的延长，不再有固定的发布日期会导致压力和频繁更改交付内容。作为一名开发人员，知道自己已经修复了一个bug但需要两周的时间才能解决，是令人沮丧的。虽然在持续部署中仍然会出现bug和边缘情况，但团队可以快速响应它们。
下一步
持续部署提供了许多好处。根据麦肯锡公司（McKinsey&Co.）的统计，高开发速度的公司已经大大超过了没有高开发速度的公司，包括：
——收入增长快四倍至五倍
——股东总回报提高60%
——营业利润率提高20%
——创新得分提高55%
——更高的客户满意度、品牌认知和人才管理
以信心、速度、稳定性和跨目标的方式向用户交付产品。这样做，你就获得了企业级部署的竞争优势。而且，这会让你的部署平淡无奇，甚至无聊，这是应该的。
