什么是持续部署

管理软件开发和部署有 3 种常见的方法：持续集成、持续交付，然后是持续部署。尽管它们经常被混淆，但它们是明显不同的。

正如您将在本文后面看到的，它们相互融合，并补充彼此的风格。但这篇文章并不是关于他们三个。今天我们想重点关注持续部署：什么是持续部署，它与其他方法有何不同，甚至它的流程和工具。在本文结束时，您将了解持续部署是否适合您的组织。

那么，让我们开始吧。

什么是持续部署？
持续部署是一种将软件自动发布或部署到生产环境中的软件开发方法。在此模型中，没有人手动检查代码并将其推送到您的应用程序中。

现在，这并不意味着没有事先进行彻底检查。显然，您必须知道正在部署的代码在交付最终用户（您的客户）手中之前是否没有错误和错误。但这也可以通过软件来完成。代码会自动测试问题，如果没有发现问题，则部署代码。

为了实现这一目标，团队必须设计或实施各种其他自动化程序，以无缝地将软件从开发的后期阶段一直拉到发布。持续部署的目标应该是显而易见的：编写代码并尽快将其交到用户手中。

但这可能很危险。如果在此过程中没有适当的检查，错误的代码可能会部署到生产中并真正搞砸您的产品，这就是为什么许多使用此方法的团队只发布小的更改。更改足够小，如果确实出现问题，则存在被遗漏的错误，那么将其回滚并重新开始并不是太困难。

但这些变化也足够大，可以快速累积起来，并为开发人员节省了大量的时间，使他们可以花在重复测试上。这也意味着，为了使持续部署成功，您需要确保拥有强大的测试框架，并确信当代码通过测试时，它确实准备好立即部署，而无需任何人查看。

对于许多开发人员来说，这个概念非常可怕，这就是为什么他们选择更安全、更常见的持续交付和持续集成选项。

但这三种方法有什么区别呢？

请仔细阅读，找出答案。

持续集成和持续交付与持续部署
图片标题

持续部署经常与持续交付混淆，但两者之间存在明显的区别。

持续部署部分是持续交付的延续，部分是持续交付的替代。让我们回到它们的来源来解释：持续集成。

根据 Aaron Cois 的说法，持续集成是一种旨在不断地将“团队中所有开发人员的源代码更新合并到共享主线中”的技术。这种持续的合并可以防止开发人员的软件项目本地副本随着其他人添加新代码而偏离太远，从而避免灾难性的合并冲突。”

现在，持续交付又向前迈进了一步。持续交付创建可以随时发布到生产环境的软件，这意味着软件被编写、测试并推送到类似生产的环境中，以确保它在真实的生产环境中正确运行。它位于等待区，直到您准备好最终部署它。

现在您可能已经认识到其中的差异了。持续集成将单独的代码片段合并在一起以确保它们正常工作，经常这样做可以避免出现重大问题。持续交付测试所有合并的代码，一旦被认为准备好部署，就将其放入保留区域，直到开发人员将其推送通过。持续部署需要持续交付的自动化测试，但不会就此止步，而是将新软件自动发布到生产环境中，直接发布给最终用户。

什么是持续部署管道？
您可能了解持续交付管道，并且在谈到持续部署管道时可能会摸不着头脑。说实话，与其说它是一个管道，不如说它是一个过程。但管道有助于理解这一点，因为它是一条线性的、结构化的路径。

因此，持续部署管道有四个阶段：

部署到生产环境
验证解决方案
监控问题
响应并恢复
我们将在下面更详细地介绍每个阶段。

部署到生产环境
这是显而易见的第一步。软件自动部署到生产中。可能不太明显的是，以这种方式操作时会放弃多少。例如，可以在没有完整功能的情况下部署对软件的更改，有时甚至无需完整的用户故事。部署过程应该快速且轻松。但它也应该尽可能可靠，当您自动化整个部署过程时，从服务器配置和基础设施配置到数据库脚本编写和代码迁移，您应该在首次构建和实现它之后密切监视整个过程，以确保它有效地发挥作用。建议您将所有可部署资产保留在版本控制中，并使用部署自动化工具来编写所有部署步骤的脚本。

因此，您的持续部署流程应从软件成功构建开始，然后进行轻松集成，并进行彻底验证，最后进行全面部署。理想情况下，整个工作流程将实现自动化，并通过“一次点击”操作。但不仅仅是自动化，持续部署还应该足够可靠，可以在一年中的任何一天运行，即使是在高峰时段。

以这种方式部署软件的能力需要您做七件事：

将软件部署到生产环境，而不向最终用户发布功能
在代码中实现切换，以便您可以在新旧功能之间切换。
自动将经过全面测试的软件从前一阶段部署到生产环境。
能够根据地理位置、用户角色和其他标准将软件部署到不同的生产环境中。
“自助”部署功能允许您使用单个命令将软件从暂存阶段转移到生产环境，以防未实现完全自动化或无法正常工作。
版本控制下的环境维护。
蓝/绿部署，因此您可以在两种不同的环境之间切换：部署和实时。
验证解决方案
现在，我们一直在讨论如何将软件部署到生产环境，然后发布给最终用户，但您可能没有意识到测试可以而且应该在生产环境中进行。根据软件测试帮助：“持续部署不必是‘发布到生产’。但代码已部署到生产中，并使用“功能切换”保持静音，当代码准备就绪时，功能切换将打开。”

这意味着部署和发布有时是耦合的，并且是背靠背发生的。但其他时候，它们是解耦的，为您提供了进行最后一轮测试的空间。您可以在此处执行多种测试：

烟雾测试
用户验收测试
压力测试
性能测试
其中一些只能在生产环境中完成。

这使得持续部署对于许多团队来说不再那么可怕。

如果您遵循持续集成，那么您就已经获得了质量保证，以确保软件按其应有的方式运行。但以后最好减少不愉快的意外发生的次数。特别是因为您不想回滚或尝试快速修复可能严重扰乱生产环境和业务流程的重大错误。

监控问题
软件最终部署完成了吗？几乎不。

虽然在生产过程中没有发生任何问题，但您的工作是监视部署的新代码的性能，以确保其继续按预期方式运行。这或多或少是持续部署的真正最后一步。您收集的见解越多，就越能实现战略业务成果。这些见解来自于增强的监控功能，您应该在软件发布之前就已经具备这些功能。

当然，在软件完全发布给最终用户之前，有很多商业价值指标是无法跟踪的。无论如何，安装监控系统可以让您跟踪每个软件功能，从而提高对任何生产问题的响应能力。

响应和恢复
虽然监控是持续部署管道的官方最后一步，但如果出现问题，它不会是您采取的最后一步。除了出色的自动化测试之外，有效持续部署的秘诀在于能够响应生产和发布中不可预见的问题并从中恢复。最重要的是，任何生产问题都会影响您的客户和最终用户。这对您的团队和业务都不利。对您的应用程序的信任可能会迅速消失。

大多数软件都需要某种修复和补丁的组合。但重新开发、重新测试和重新部署是另一个令人头疼的问题，您应该尽力避免。这就是为什么能够在问题被理解为问题之前主动检测问题并快速从中恢复至关重要的原因。当您的团队对快速找到问题的根本原因并在发现问题后立即解决问题的能力充满信心时，您就已经达到了持续部署的最佳状态。

但你必须小心，因为你不想陷入仓促改变的陷阱。这可能会使问题变得更糟并导致长期风险。

这就是为什么你应该确保你正在练习以下内容：

主动在软件中创建故障，以便在可能的问题和错误出现之前发现它们。
跨价值流合作来发现和解决问题。
重播最终用户会话以更好地了解事件并再次根除问题。
能够回滚到以前的环境。
无需改变生产环境。
在版本控制下维护环境。
如何开始持续部署
持续部署是一个部分、一个过程，可能会也可能不会作为完整 DevOps 计划的一部分来实现。这意味着，在开始使用持续部署之前，您需要将团队切换到 DevOps 框架。

DevOps 最好的部分是，它将最终与新软件项目交互的所有团队聚集在一起，并允许他们同时协作、提供和接收反馈，并加快开发和部署周期。