对于开发人员来说，CI/CD 是什么

软件开发生命周期包含许多活动部分。许多大型公司面临的一个巨大问题是维护一致的部署流程。书面步骤有时会被跳过，手动部署容易出错，而且自制的部署脚本通常只有编写脚本的人才能理解。像 Netflix、Etsy 和 Amazon 这样的公司需要确保部署周期顺畅，并尽可能在流程早期发现错误。

当你无法持续在客户所在地进行生产时，你的公司就会开始失去用户的信任和信心。这时，DevOps 就派上用场了。

什么是 DevOps

DevOps 是公司处理部署流程方式的一次转变。在许多组织中，代码由开发人员处理，部署由运维团队负责。DevOps 解决的根本问题是错误修复和新功能发布的周期缓慢。

瀑布式开发周期至今仍被广泛使用，其最大的缺点是从开发到部署所需的时间过长。在 DevOps 文化中，开发人员可以在一定程度上控制应用部署到生产环境的方式。这使得变更能够更快、更一致地发布，并减少影响用户体验的错误。

在 DevOps 中，您会注意到流程与瀑布循环类似，但更加精简和自动化。

DevOps 生命周期包含多个阶段：版本控制、持续集成、持续交付和持续部署。版本控制是开发人员始终以 Git 和其他工具（例如 GitHub 或 BitBucket）的形式进行的工作。

持续集成是开发人员在 DevOps 链中首先接触到的内容之一。在这一环节，你的代码会被编译、审查和测试。假设我们正在尝试将一个 Web 应用程序部署到生产环境，我们将介绍一个典型的 CI/CD 流水线的流程。

大多数 DevOps 流水线都是由推送到分支或其他一些提交条件触发的。这将启动构建阶段，这是大多数流水线的起点。

在构建阶段，您的所有代码都会被编译，以生成最终要部署的工件。应用构建完成后，第一轮测试将立即开始。

通常情况下，单元测试会在这里运行，并清除所有简单的代码错误。如果任何测试失败，它会向负责这些更改的开发人员或团队发送通知。

所有这些在初始阶段进行的检查，都是为了确保问题能够尽早得到解决。您肯定不希望构建好的工件一直到部署阶段才发现生产环境中的表单配置错误，因为有人使用了双重相等比较而不是三重相等比较。

这是 DevOps 的一大目标。当你每周甚至每天多次部署变更时，尽早检测并修复错误和安全问题至关重要。当问题发生时，通过停止流水线的其余部分运行，可以节省你的时间。你不必等到最后才向开发人员提供反馈。

一旦单元测试完成，您的工件可能会被部署到暂存或质量保证环境。

CI/CD 中的“CD”实际上代表了 DevOps 流程中的两个阶段：持续交付和持续部署。持续交付是将应用程序推送到不同环境背后的自动化过程。

集成测试通常也在这里运行。很多时候，此部署与其他任务并行处理。您可能还需要清除要部署到的服务器的缓存，或根据要部署到的环境设置配置。

这也意味着您的应用程序开始被推送到相应的服务，例如数据库服务或 Web 服务器。持续交付就像在将更改推送到面向客户的服务器之前，为部署到类似生产环境而进行的测试运行。一旦您运行了最后几个集成测试、进行了一些 Q/A 测试并通过了一些安全测试，您就拥有了一个可用于生产的有效代码库。

持续部署是 DevOps 努力实现的总体目标。这意味着你的代码变更最终会被发布到生产环境并交付给客户。DevOps 之所以需要持续部署，主要是为了消除运维过程中所有手动步骤。当你需要人工执行一系列步骤时，总会有一些小问题被忽略。

无论是像不更新环境变量这样简单的问题，还是像将空的工件部署到生产中这样的问题，持续部署都是解决该问题的方法之一。

如果您想知道是否应该尝试为您的项目实施 CI/CD 管道，请考虑以下几点。

市面上有许多开源和企业级工具可用于构建 CI/CD 流水线。不妨研究一下这些工具，找到最适合你应用的工具。

在构建 CI/CD 流水线时，您可以实施多种策略。这主要取决于您希望向用户提供什么。如果您有大量微服务和第三方服务，您可能需要研究某种编排策略。如果您有一个现有的动态应用程序，您可能需要专注于流水线的测试阶段。

即使只是实施一个基本的 CI/CD 流水线，也能节省您数小时的调试时间，并使您的部署更加顺畅。花时间寻找最适合您项目的工具确实值得。选择既经济高效又具备您所需功能的工具需要权衡利弊，但最终获得的客户满意度将物有所值。

如果您还在犹豫应该先尝试哪个工具，不妨试试Conducto ，它能帮助您构建 CI/CD 管道。它非常容易上手，并且在实时调试时也更加便捷。

请务必在Twitter上关注我，因为我一直在发布有关此类内容和其他技术主题的帖子！