什么是持续集成 (CI) 和持续交付 (CD)？为什么这种更新软件交付方法已成为使用 DevOps 方法的先进、现代软件开发方法的标志？在本篇文章中，Travis CI 将为您解答。
要理解 CI/CD，首先了解 DevOps 非常有用。DevOps 是 CI/CD 紧密关联的开发方法。事实上，可以说，CI/CD 支撑着 DevOps 赖以构建的整个方法论。
DevOps 是一种软件开发方法，旨在弥合开发 (dev) 和 IT 运维 (ops) 两方在开发过程中的传统隔阂。
历史上，软件交付过程的这两个重要部分各自为政，"dev" 编写新代码，"ops" 将其部署到面向客户的（生产）基础设施上。即使软件工程师和网络管理员坐在同一间房间里，这种断断续续的方法也不可避免地会导致功能发布滞后，因为一个流程必须结束才能开始另一个流程。
对于依赖于基于代码产品的及时发布和开发的组织来说，这个问题日益严峻，例如 SaaS 公司的吸引力往往取决于其提供的功能。发布周期缓慢会导致客户流失，并损害企业的盈利能力。
安全性也开始成为一个迫切的问题。随着黑客在发现和利用漏洞方面变得更加有组织和高效，安全工作（修补这些漏洞）必须迅速完成，几乎是立即完成。等待 dev 推出修复程序，然后几个月后才实施，不再是可行的方法。
如果“dev”和“ops”是桥的两端，那么 CI/CD 将连接这两端。或者更确切地说，它是允许信息（开发版本）在其两端之间无缝且持续传递的技术和工作流。
使用 CI/CD，代码更新不是等待间歇性的发布周期，而是由软件开发人员持续推动，他们可以尽可能利用自动化来解析和集成代码更新。
CI/CD 管道强制执行一系列严格的检查，旨在标准化重要的 QA 流程，尽管人类监督着整个流程，并且可以随时手动参与。最终，代码会持续发布到生产服务，从而供最终用户使用。在更高级的管道中，部署基础设施以适应新的代码迭代甚至可以成为管道管理工具本身的一部分。
如果我们回到 CI/CD 是连接“dev”和“ops”的桥梁的比喻，那么持续集成和持续交付就是其两个端点。
继续我们的比喻，持续集成指的是桥的“起点”。
开发人员以团队的形式工作，以生成代码，这些代码稍后将被编译并以分阶段发布的形式交付给最终用户。
此代码需要持续集成到 CI/CD 管道中。因此，CI 归根结底是开发工作流的一种自动化形式。它不仅通过存储库管理系统接收代码，而且还会将代码按顺序地进行一系列质量控制检查，以确保其质量足以真正发送给最终用户。
在我们这台虚拟桥的另一端，我们拥有持续交付。CI/CD 中的 CD 也可以代表持续部署。
持续交付和持续部署有什么区别？它们之间有一个关键的区别：在持续部署中，对最终用户的发布（开发管道的最后阶段）是自动完成的。持续交付在此之前的阶段停止，将自动化一直贯穿到部署之前的最后阶段（因此得名）。
持续交付涉及引导代码经过一系列阶段，这些阶段在完成管道的集成部分（通常包括构建和初始测试）后进行。这些阶段包括：|
● 验收测试：旨在确保在较高层面上，更新符合正在开发的系统或软件的规格
● 部署到登台：在此，代码将从开发服务器移动（“部署”）到登台服务器。如果此流程成功完成，管道将转至
● 部署到生产：持续交付和持续部署的区别就在于此。在持续交付中，此最终流程需要人工（手动）干预。
CI/CD 管道指的是代码由开发人员生成并通过一系列自动化测试以最终交付给用户的过程中所执行的一系列步骤。我们在上面已经介绍了许多步骤，特别是 CD 阶段的步骤。
为了填补缺失的部分
正如我们所见，管道的持续集成部分关注的是集成源代码、构建包，然后开始对其进行测试。
具体而言，以下步骤至关重要
| 触发 | 首先，需要有一个自动化机制，通知 CI/CD 管道新的代码已提交。在实践中，这是通过使用存储库管理器（例如 Assembla、Bitbucket 或 GitHub）来实现的。这些工具允许多个开发人员在同一代码库上进行协作，而不会相互产生代码冲突。一旦更新提交，管道就会收到通知。管道的这一部分是完全自动化的。一旦收到提交请求，它就会开始进一步处理代码。在此阶段，管道管理器还会从存储库中签出代码。 |
| 编译 | 接下来，需要从源代码编译程序。在现代工作流中，通常使用 Docker 容器来管理在可轻松移植的环境中针对代码运行测试的过程，这些环境复制了实际运行时。 |
| 单元测试 | 在此阶段，QA 流程开始。代码库会经过一系列测试。在大多数管道管理器中，用户可以选择使用标准化测试、编写自定义测试，或者（非常常见）选择对代码进行标准化测试和自定义测试的混合测试。存储库管理器和那些遵循 CI/CD 管道的人会收到通知，告知测试结果是通过还是失败。如果测试失败，管道将自动停止，以便开发人员可以查看测试结果，并在下一次代码更新中进行修复。 |
最后，管道向部署阶段过渡，首先推送到登台服务器，最后推送到生产服务器。
与大多数技术革命一样，CI/CD 可能是提高生产力的绝佳方式。或者，它也会造成混乱和沮丧。在部署 CI/CD 管道管理器并转向 Dev-Ops 方法时，最终结果是成功还是失败的关键在于您是否遵循最佳实践。
以下是一些需要牢记的最佳实践
在传统的开发方法中，团队领导可能会鼓励开发人员尽可能长时间地保留自己的代码。理想情况下，在进一步传递之前，应该先解决初步的错误。
CI/CD 要求采用完全不同的方法，需要将这种方法传达给所有团队成员。由于测试阶段是自动化的，因此它鼓励开发人员尽快完成他们最擅长的工作——开发。
由于 QA 是自动执行的，但该流程只有在管道被触发后才能启动，因此鼓励开发人员尽可能频繁地提交代码是有意义的。
一些集成开发环境 (IDE) 甚至具有自动定期提交的功能。但是，即使您的技术堆栈没有此类工具，也可以鼓励开发人员尽可能频繁地将代码提交到存储库。代码可以更频繁地集成到管道中，迭代周期就可以更快地自我改进，从而更快地发布产品。
如果代码开发人员和生产环境之间存在障碍，团队成员不可避免地会倾向于寻找最简单的路径。
不要低估开发人员可能会寻求开发自己的技术以绕过 CI/CD 管道的可能性。这可能是以部署影子技术或找到跳过测试流程部分的方法的形式出现。
因此，必须确保您的 CI/CD 管道是一个严密的看门人，是代码从开发人员工作站到客户接触到的产品的唯一可行路径。
开发一个成功且高效的 CI/CD 管道需要付出很多努力：确保所执行的一系列测试能够将代码库从其原始格式转化为峰值状态（理想情况下是无错误状态），以供用户使用。
不幸的是，"设置并忘记" 并不是最好的方法。鉴于典型的 CI/CD 管道利用了大量自动化，因此也应注意分析（大多数管道具有此功能）。
哪些测试导致了最多的失败？哪些团队最频繁地忽略最佳实践？这类信息可以作为宝贵的资料来源，用于迭代地改进开发流程。
QA 流程的一个重要部分是模拟打包后的代码在预期运行的系统类型上的性能。
鉴于许多开发团队的任务是为多个不同的操作系统和体系结构同时开发产品，这很快会导致“虚拟机蔓延”，即必须部署大量资源密集型系统，仅用于执行基本系统测试。
使用 Docker 等容器程序是另一种可行的替代方案。这些程序将操作系统压缩成精简的软件包，因此也使其在不在同一个物理位置的团队之间易于移植。使用这种技术可以更有效地快速启动管道所需的新的测试环境。
CI/CD 管道管理工具已成为基于 DevOps 的开发方法的基本构建块，大大提高了代码交付的效率，并减少了令人讨厌的内部孤岛（从而也减少了开发团队内部的挫败感）。
像 Travis CI 这样的 CI/CD 工具可以让您
● 快速获得用户友好的分析，以易于阅读的格式呈现复杂的测试数据，允许开发人员快速进入修复阶段
● 组织并自动优先处理要修复的测试结果，为它们分配唯一的 ID，并自动将它们路由到团队中最合适的资源
● 将 CI/CD 管道无缝集成到团队已经使用和喜欢的堆栈部分中，例如 GitHub、Hooray 和 Heroku。甚至还有一个 Slack 集成，允许您的管道将更新推送到团队中央通信中心监控该管道的人员。
从传统的开发方法过渡到以 DevOps 为中心的开发方法，还可以
● 允许您大大提高功能管道发布的速度，使您的产品在竞争对手的产品中脱颖而出。
● 允许您的开发资源将更多时间花在开发代码和规划功能上，而将更少时间花在消除错误和缺陷上。CI/CD 工具是开始向更细分开发工作流程过渡的绝佳方式，可以让 QA 资源专注于他们最擅长的工作。
● 让您的团队和组织成为未来人才更具吸引力的雇主。如今，基于 DevOps 的工作流程已成为开发界的标准。需求旺盛的人才最渴望加入已经利用现代开发和发布方法的组织，例如那些围绕 Travis 和 CI CI/CD 管道构建的组织。
| 考虑使用 Travis CI 来满足您的 企业 CI/CD 需求。立即获取 Travis CI 免费试用。 |