DevOps：加速数字化转型的驱动力

“几乎每个人都在做持续集成。持续部署有点像圣杯” ——Theo Kim，GoPro DevOps 工程负责人

软件市场的竞争迫使组织分配最好的资源，以更快的速度开发和交付高质量的软件。 这种敏捷性水平的关键是在开发和 IT 运营之间建立高度协作和交流的关系。

现代转变

“DevOps”一词于 2008 年首次出现，旨在让软件开发人员和 IT 运营专业人员能够共同快速高效地创建应用程序。 十年后，DevOps 已成为许多组织成功不可或缺的组成部分，包括亚马逊、Netflix 和富达全球投资等大型公司，这些组织拥有庞大的客户群，需要卓越的服务和可访问性。

从表面上看，DevOps 似乎并不是一项突破性的技术：让团队合作以更好更快地交付似乎是一个显而易见的目标。

敏捷开发过程通过增加开发团队和业务利益相关者之间的沟通来缩短开发时间。 但是当最后一行代码写完并且最后一个测试用例通过时，软件项目还没有完成。 应用程序必须打包以供发布、部署到生产中、监控可能的问题，并通过新功能和必要的错误修复进行增强。

这些后期开发任务中的每一个都需要时间，从而延迟向用户交付新特性和业务功能。 DevOps 将敏捷重点放在开发人员和运营团队之间的沟通和协作上，使开发后的流程具有同等的响应能力。

今天，DevOps 被认为是最有效的软件开发方法。 使用 DevOps，软件组织可以降低开发复杂性，更快地检测和解决问题，并持续交付高质量的创新软件。 持续集成 (CI)、持续交付 (CDE) 和持续部署 (CD)是一些有助于组织在不影响质量的情况下加快速度的实践。

持续集成

持续集成 (CI) 是软件开发行业中广泛建立的开发实践，旨在尽早并经常将各个开发人员的工作产品集成到中央存储库中。 团队成员经常集成和合并他们的开发工作。 CI 确保及早发现集成错误，从而促进团队内部的更好协作，从而产生更优质的产品。

CI 使集成过程变得简单、易于重复，并使组织能够享受更短和更频繁的发布周期，提高软件质量并提高整体生产力。

但是，应该考虑一些权衡。 CI 过程不提供任何额外的质量保证。 许多组织发现这种集成成本高昂，因此更喜欢手动程序以确保新代码不会引入新错误，即使这意味着按时妥协。 为了减少集成任务期间的摩擦，CI 依赖于测试套件和自动化测试执行。 然而，重要的是要意识到自动化测试与连续测试有很大不同。

持续交付

持续交付 (CDE) 是持续集成的自然延伸，从 CI 中断的地方开始。 持续交付旨在确保应用程序在成功通过自动化测试和质量检查后始终处于生产就绪状态。 CDE 通过采用一组实践（例如 CI 和部署自动化）来确保软件没有错误，从而自动将软件交付到类似生产的环境中。

持续交付依赖于团队用来自动化测试和部署过程的部署管道。 管道本身是一个自动化系统，它针对构建执行一组渐进式测试套件。 在管道的每个部分，构建都可能无法通过关键测试，从而提醒团队。 如果没有，它会继续下一个测试套件，并且连续的测试通过将导致自动升级到管道中的下一个部分。 管道中的最后一部分将构建部署到生产等效环境。

AWS 上提供了现代 CI/CDE 管道的最佳示例之一。 Amazon 提供了令人印象深刻的 CI/CDE 管道环境，并提供了一个演练过程，您可以在其中从许多开发资源中进行选择，并将它们链接到一个易于配置且易于监控的管道中。

持续部署

虽然许多人将持续部署 (CD) 与持续交付混淆，但这个过程通过更进一步自动和持续地将应用程序部署到生产来区分自己。 以自动、稳定地将每个更改部署到生产环境中为目标，持续部署实践意味着持续交付实践，但反之则不然。

虽然持续交付中的最终部署是一个手动步骤，但重要的是要注意持续部署中没有手动步骤。 一旦开发人员提交更改，更改就会通过部署管道部署到生产中。 此外，持续交付实践可以应用于所有类型的组织，而持续部署实践可能只适用于某些组织类型。

采用 CD 方法的组织将受益于用户对其新部署的快速反馈。 功能可以快速交付给用户，并且可以立即处理任何明显的错误或缺陷。

随着 DevOps 采用的巨大增长，有助于实施 CI/CD 管道的自动化工具也显着增加。 这些工具与各种开发人员工具集成，包括代码存储库系统（如 Github）和错误跟踪系统（如 Jira）。 此外，随着 SaaS 已成为一种流行的交付模式，这些工具中的大多数都在云上运行。 一些最流行的工具是 GitLab CI、TeamCity、Bamboo、GoCD、Jenkins 和 Circle CI。