生产就绪不等于用户就绪

持续交付是企业采用 DevOps 的倒数第二个目标。 这不是最终目标，因为那将是持续部署。

在 DevOps 领域，人们为实现每天无数次交付可用于生产的软件的能力而大费周章。

那很好。

我对此并不太兴奋的原因是，在大多数企业组织中 – 即使是那些采用 DevOps 的企业 – 交付只是应用生命周期“进入市场”阶段的第一步。 在最终构建和发布通知时，很少有应用s能够为用户“做好准备”。 它仍然需要部署到生产中，其中各种程序和政策将确保它正确交付给用户。

看看吧，持续部署是（应该是、可能是、将是）组织采用 DevOps 的最终目标。 即使不是，更大的问题是，简单地交付生产并不意味着应用“交付”给了它的组成部分。 这需要在生产中进行部署，以及扩展、保护和加速应用所需的任何服务，以确保它为企业和消费者用户提供最佳的应用体验。

这可能意味着负载平衡，以确保规模和可用性。 它几乎肯定意味着安全——至少在防火墙方面，希望是应用程序安全，甚至更多。 它还可能暗示访问权和身份。 也许不适用于面向消费者的应用程序，但面向企业的应用程序可能需要纳入 SSO 或联合策略，以确保顺畅、轻松地访问。 就性能而言，可能也需要速度。

在应用程序为用户“做好准备”之前，所有这些事情都需要发生。 并且“生产”也知道这一点。 在我们的 2017 年application交付状况调查中，有 32% 的受访者表示“我们部署了 1-10 个这样的服务”，而大多数受访者表示“我们部署了超过 5 个”，其中 63% 的受访者表示目前已部署了 6-10 个。

无论“持续部署”问题如何，这些服务对于确保应用程序“为用户做好准备”而不仅仅是“为生产做好准备”都至关重要。

无数次地向生产交付产品固然很好，但更频繁地向市场交付产品才是真正的目标。 即使 DevOps 进入生产阶段（来吧！真的没问题！）来处理应用程序及其直接基础设施，仍然需要对上游服务进行调配、配置和测试，然后应用程序才能真正被视为“交付”。

更频繁地将应用程序发布到生产环境实际上并不会影响部署计划。 开源项目拥有“稳定”分支和“夜间构建”选项是有原因的。 当然，我可以获得最新和最好的版本，但作为用户，我更喜欢“稳定”选项，因为应用程序中断或随机崩溃对积极的应用体验没有任何帮助。

部署计划必须由业务部门驱动并由 IT 部门实施，这意味着让 IT（所有四个操作）参与进来，尽可能多地实现流程自动化。 因为应用程序还没有准备好让用户通过生产环境中周围的服务来确保其安全和加速。