持续交付是组织采用DevOps的倒数第二个目标，而非最终目标，因为最终目标是持续部署。
DevOps领域经常热议这样一种能力：每天多次交付可投入生产的软件。
这很好。
我对此并不太兴奋，因为在大多数企业组织中，即使是采用DevOps的企业，交付也只是应用生命周期“推向市场”阶段的第一步。收到最终构建和发布通知时，很少有应用已经“准备好”供用户使用。应用仍需部署到生产环境，并通过各种流程和策略确保正确交付给用户。
持续部署是（应该是、可能是、也终将是）组织采用DevOps的最终目标。即使并非如此，更重要的问题在于，仅仅将应用交付到生产环境，并不意味着应用已真正“交付”给目标用户。应用还需要部署到生产环境，并配备扩展、安全防护和加速所需的各项服务，从而为企业用户和消费者提供良好的应用体验。
这可能意味着需要负载均衡，以确保可扩展性和可用性。几乎可以肯定的是，还需要安全防护，至少包括防火墙，最好还包括应用安全，甚至可能需要更多。访问和身份管理也可能在考虑范围内。面向消费者的应用或许不需要，但面向企业的应用可能需要纳入SSO或联合身份策略，以确保顺畅、便捷的访问。此外，可能还需要提升性能。
应用在面向用户“就绪”之前，需要完成所有这些工作，而“生产”团队对此心知肚明。在我们的《2017 年应用交付现状》调查中，32%的受访者表示“已部署 1 至 10 项此类服务”。其中，大多数受访者部署了 5 项以上，63%表示目前已部署 6 至 10 项。
无论是否存在“持续部署”方面的问题，这些服务对于确保应用不仅“可投入生产”，而且真正“可供用户使用”都至关重要。
频繁部署到生产环境固然很好，但真正的目标是更频繁地将应用推向市场。即使DevOps逐步延伸到生产环境（来吧！这里真的没什么可担心的！），负责处理应用及其直接相关的基础设施，上游也仍然会有一些服务必须完成预配、配置和测试，之后才能真正认为应用已“交付”。
更频繁地将应用发布到生产环境，实际上并不会影响部署计划。开源项目之所以提供“稳定版”分支和“每日构建版”选项，自有其道理。当然，我可以使用功能更新的版本，但作为用户，我更倾向于选择“稳定版”，因为应用出现故障或随机崩溃绝不会带来良好的应用体验。
部署计划必须由业务需求驱动，并由IT部门实施。这意味着需要让IT部门（所有四类运维团队）共同参与，尽可能实现流程自动化。因为应用只有在生产环境中通过周边服务获得安全保护和性能加速后，才能交付用户使用。
关于作者
Lori MacVittie是F5首席技术官办公室的杰出工程师兼首席技术布道师，在应用交付、自动化战略和基础设施领域拥有深厚的专业知识。无论是为AI智能体定义防护机制、剖析脆弱的多云架构，还是探索可扩展系统的极限，她都善于化繁为简。她在应用开发、IT架构以及网络和系统运维领域拥有30多年的行业经验。加入F5之前，她曾担任技术编辑，并因出色表现获得奖项。 MacVittie拥有计算机科学硕士学位，著述颇丰，出版作品涵盖安全、云和企业架构领域。她还热衷于桌面游戏和电子游戏，并且对奶酪有着毫不掩饰的鲜明见解。
Lori Mac Vittie 的更多博客文章相关博客文章
Thingbot正转变为攻击平台
Lori MacVittie重点介绍了F5 Labs对2018年1月至6月全球物联网设备攻击的研究，并指出了其中令人警醒的影响。物联网设备不仅持续遭到利用，还被转变为攻击平台，这意味着攻击者可以更充分地利用这个必然增长的市场。
借助F5全新Quick Start，在AWS上快速开展业务
在AWS re:Invent开幕前，我们很高兴与大家分享F5与AWS之间全新的Quick Start集成。F5的Tom Atkins将介绍该服务如何启动、配置和运行在AWS上部署工作负载所需的计算、网络、存储及其他AWS服务。