持续集成持续部署持续交付_持续部署：简介

持续集成持续部署持续交付

本文是“ 持续集成，交付和部署”系列的一部分。

持续部署是软件Craft.io的最终顶点。 我们的技术水平必须很高，以便我们有信心连续自动地将软件部署到生产中。 这是持续集成和交付的自然发展。 我们通常从与正在构建的软件的持续集成开始，并在每次提交VCS时执行测试。 随着我们对流程的了解越来越好，我们将继续不断交付流程，尤其是测试，因为它们做得很好，因此我们有信心通过所有验证的任何软件版本都可以部署到生产中。 只要按一下按钮，我们就可以随时发布软件。 当我们摆脱该按钮并将每个“绿色”构建部署到生产中时，便完成了连续部署。

本文将尝试探索连续部署最后阶段的目标，即部署本身。 假定正在执行静态分析 ，正在运行单元 ， 功能和压力测试， 测试代码覆盖率足够高，并且我们有信心在每次提交后我们的软件都能按预期执行。

部署过程的目标是：

• 经常跑步
• 自动
• 快一点
• 提供零停机时间
• 提供回滚功能

经常部署

软件行业不断承受着提供更高质量和更快交付的压力，从而缩短了产品上市时间。 在提供更多功能的同时，我们更经常地在不牺牲质量的情况下交付产品。 在开发某些功能并将其部署到生产之间所花费的时间是浪费的时间。 理想情况下，我们应该在将新功能推送到存储库后立即交付它们。 在过去，我们习惯于交付软件的瀑布模型。 我们会计划一切，开发所有东西，测试所有东西，最后将项目部署到生产中。 花费数月甚至数年的时间并不少见。 将数月的工作投入生产通常会导致部署困难，许多人在周末工作以将无数的新代码投入生产服务器。 很多时候，事情并没有按照最初的计划进行。 从那时起，我们了解到使用功能而不是项目并在完成后立即交付它们会带来很大的好处。 交付通常意味着在开发一项功能后立即交付。

自动化一切

使任务自动化可以使我们消除部分“人为错误”，并更快地完成工作。 使用BDD作为定义需求并在将功能推送到存储库后立即对其进行验证的一种好方法，以及将TDD作为驱动开发并在单元级别上持续验证代码的一种方法，我们可以获得对代码按预期执行的信心。 相同的自动方法应适用于部署。 从构建工件到供应环境，直到实际部署。 生成工件是在相当长的一段时间内运行良好的过程。 无论是针对Java的Gradle还是Maven （更多信息，请参见Java Build Tools文章），针对Scala的SBT ，针对JavaScript的Gulp或Grunt或您正在使用的任何其他构建工具或编程语言，如今几乎没有人遇到问题来构建他们的软件。 调配环境和部署构建工件是一个仍有很多工作要做的过程。 Chef和Puppet之类的置备工具并未完全兑现其承诺。 它们要么不可靠，要么使用起来太复杂。 Docker提供了一种全新的方法（即使容器不是什么新鲜事物）。 有了它，我们可以轻松地部署运行我们软件的容器。 即使可能仍需要服务器本身的某种类型的配置，如果需要的话， Chef和Puppet之类的工具的使用也会（或将大大减少）。 使用Docker ，只需执行一个命令，就可以轻松部署功能齐全的软件，并提供所需的一切。

快一点

持续部署的关键是速度。 如果从检查代码到通过测试直到部署都需要花费大量时间，那么我们希望得到的反馈很慢。 这样做的想法是尽可能快地获得有关提交的反馈，以便在出现问题时可以在我们开发另一个功能之前修复它们。 上下文切换非常昂贵，来回切换非常浪费时间。 对速度的需求不仅适用于测试运行时，还适用于部署。 我们会尽快部署，尽快开始集成，回归和压力测试。 如果这些服务器未在生产服务器上运行，则它们成功后将进行另一次部署。 乍看之下，5分钟到10分钟之间的差异似乎很小，但总的来说。 检出代码，运行静态分析，执行单元，功能，集成和压力测试，最后进行部署。 我认为，这两个步骤加起来总共要花几个小时，而我认为整个过程的合理时间不应超过30分钟。 快速运行，快速失败，快速部署并从在线获得新功能中受益。

零停机时间

连续部署或至少经常部署意味着必须实现零停机策略。 如果我们每个月部署一次，或者一年只部署几次，那么在短时间内使应用程序不可用可能不是一件坏事。 但是，如果我们每天部署一次，甚至一天要部署许多次，那么停机时间（无论多么短）都是不可接受的。 达到零时间的方法有多种， 蓝绿色部署是我的最爱。

回滚能力

无论我们进行了多少个自动化测试，总有可能出问题。 如果发生意外情况，可以选择回滚到以前的版本，这可以为我们节省很多麻烦。 实际上，我们可以以回滚到通过所有测试的任何先前版本的方式来构建软件。 回滚需要与按按钮一样容易，并且回滚必须非常快，以便能够以最小的负面影响恢复应用程序的预期功能。 停机或不正确的行为会花费金钱和信任。 持续时间越短，我们损失的钱就越少。

完成回滚的主要障碍通常是数据库。 NoSQL倾向于以更大的宽限度处理回滚。 但是，现实是关系数据库不会很快消失，我们需要习惯于以所有更改都向后兼容的方式编写增量脚本。

摘要

对于许多人来说，持续部署听起来太冒险了，甚至不可能。 是否冒险取决于我们正在构建的软件的体系结构。 通常，将应用程序拆分为较小的独立元素会很有帮助。 微服务是去，如果有可能的方式。 除了风险，在许多情况下，没有商业原因或不愿意采用连续交付的意愿。 尽管如此，软件仍可以连续部署以测试服务器，从而可以连续交付。 无论我们是进行连续部署，交付，集成还是不进行任何工作，具有零停机时间和回滚功能的自动快速部署都将带来巨大的好处。 如果没有其他原因，是因为它使我们有更多的工作要做和有益的工作。 我们应该设计和编码我们的软件，然后让机器为我们完成其余的工作。

下一篇文章将在我们停止的地方继续，并探讨部署软件的不同策略。

翻译自: https://www.javacodegeeks.com/2014/12/continuous-deployment-introduction.html

持续集成持续部署持续交付