什么是 CI/CD？CI/CD，或持续集成/持续交付或部署，是由自动化实现的软件开发实践。频繁、可靠的更新通过持续的代码交付加快了发布周期。
CI/CD 说明CI/CD 是一个涵盖多个 DevOps 阶段的总称。CI（持续集成）是一种将代码更改一天集成到代码仓库中多次的做法。CD 有两个含义：持续交付可自动进行代码集成,而持续部署可自动向最终用户发布最终版本。 CI/CD的频繁测试可减少代码错误和缺陷,因此对每一个DevOps工作流程都至关重要。
什么是持续集成？(CI)持续集成 (CI) 是一个自动化的软件开发过程，可提高开发速度，同时确保每次部署都能有干净的高质量代码。持续集成要求开发者每天多次频繁签入/将其代码单元提交到中央共享代码仓库。
CI是DevOps最佳实践和DevOps生命周期中开发者将代码签入其共享代码仓库的阶段。自动化构建工具会验证签入或分支，以确保没有错误，并且已可用于生产环境。这样做的主要好处是，问题通常在滚雪球变成更大的问题之前就能及早发现。
实践 CI 意味着在更短的时间内集成少量更改，而不是花费更长和更少时间进行实质性更新。自动化测试、合并和签入共享代码仓库更改的工作流程意味着团队可以更快地交付更简洁的代码权重。更清晰的代码意味着更快的验证、更高质量的发布以及更高效且更易于扩展的开发管线。
持续集成是如何工作的？持续集成是一个从开发阶段开始到测试环境的简单、无缝的过程。持续集成可让所有开发者进行协作并跟踪他们的代码。每个개발자者都会以少量增量将代码“提交”到共享代码仓库（也称为主干代码仓库）。代码仓库由Unity VCS、Perforce或Git等版本控制系统维护。每次提交到代码仓库的主分支（或子分支，如果选择）时，都可以触发一个自动构建过程，该过程链接到获取代码并创建构建的构建管理系统。将代码合并到构建系统中后，开发者可以获得对其代码构建的完全访问权限。在这里，他们可以查看代码编译是否正确，或者是否有需要修复的错误。构建系统可以配置为支持各种测试框架。
一旦代码获得批准且构建周期成功，系统将触发自动化测试环境，以验证构建和后续版本的质量。由于测试和构建过程非常快速，因此可以快速传递代码提交的结果，从而使开发者能够及时修复任何剩余的错误。整个流程可以保证代码库保持正常运行，让每个人都能继续高效工作。
CI 规则和原则- 维护一个中央代码仓库
应尽量减少将不同团队中不同开发人员的代码临时存储在不同的代码仓库或单独的系统中。
- 经常向主代码仓库提交/签入代码
개발자者在未构建或测试代码的情况下掌握代码的时间越长，代码与存储在中央代码仓库中的内容不一致的可能性就越大。
- 维护单独的构建和测试服务器
团队应维护仅用于构建目的的专用机器。这可以加快构建过程，并最大限度地减少对其他开发者工作流程的影响。
- 构建和测试必须自动化
提交到中央源代码仓库的每一段代码都应该使用持续集成工具自动构建和测试。
- 使用类似生产的测试环境
测试环境应模拟最终的生产环境。这可确保测试环境的实用性，并在整个部署过程中保持预期一致。
- 质量保证团队应有权访问版本
当 QA 有权访问构建时，可以及早发现任何不符合生产要求的情况，从而减少以后必须返工代码构建的风险。
持续交付与持续部署持续部署和持续交付是采用新代码并尽可能快速有效地将其投入生产实践。持续交付遵循 CI - ⁇ 您可以将它视为最终产品发布给客户之前开发管线中的检查点阶段。一旦代码更改经过验证，它们将自动传递到中央代码仓库。
在 DevOps 生命周期中，持续部署遵循 CI，但这两个过程是相互关联的。CI 通过自动化将代码集成到构建中；CD 完成此过程。DevOps 自动评估更新的质量。一旦发现没有错误，它们将自动部署到生产环境中。
什么是持续交付?
持续交付是指构建、测试和交付软件的代码更改。在这个过程中，代码在被推送到生产环境之前，会经过各种测试环境，例如自动化单元测试、集成测试和系统测试。持续交付发生在类似生产的过渡环境中，QA 在其中审查代码、修复错误并运行自动化测试，以确保构建始终可以部署和发布。
在持续交付的情况下，我们的目标是保持变更集足够小，以免主构建的任何更新都会影响最终产品的“可用于生产”状态。最终产品可能包含一些微小的错误，但丝毫没有实质性的、足以影响用户体验的错误。
实践持续交付意味着开发者可以花更少的时间在内部测试，因为实践可以确保只有稳定的代码从一开始就能进入交付阶段。它使错误检测过程更简单，从而缩短解决问题的时间。
什么是持续部署?
持续部署的目的是在构建稳定后，从中央代码仓库持续将代码更改部署到生产环境中。运营团队会在不同环境(开发/测试、过渡和生产)中部署编译代码和下载量。每次更改都会经过自动化管线，将应用程序的工作版本推向生产环境。部署可采用不同的形式。暗色版本是一种对用户隐藏的部署，而功能开关或切换可用于将变更集的特定子集部署到一组用户进行测试和反馈。
持续部署可为开发者和客户带来诸多好处。使用持续部署解决方案的开发者不再需要担心手动构建部署，可以专注于更多基于技能的任务。自动化可缩短反馈流程，这意味着可以根据客户的输入更快地更新产品。通过持续部署，可以在模拟环境中运行和维护代码，确保质量并能够实时监控产品。持续部署的主要目标是一致地发布更新的代码版本，并将这些更改自动部署到最终用户。
CI/CD 和 DevOps 有何关联？所有软件开发都始于预生产（规划阶段），然后是生产（编码和资源创建）。DevOps 是一种文化和过程，旨在提高这些过程的效率。CI/CD 是 DevOps 生命周期中的一个阶段，强制要求随时间推移实施少量但稳定的代码更新，以确保最终产品的持续、迭代改进。
通过使用特定的工具和产品，可以实现代码更改的集成、交付和部署，从而实现定期、频繁的软件发布，这称为 CI/CD 管线。
CI/CD 管线是与工具和自动化相关联的一组特定阶段，这些工具和自动化使 DevOps 生命周期得以发生。虽然CI/CD是DevOps文化不可或缺的一部分，但DevOps在软件开发生命周期中所包含的内容要多得多——从协作到团队结构，再到可观察性、Version Control等等。
DevOps 的实施因组织而异,但归根结底,没有 CI/CD,DevOps 是不可能实现的。CI/CD 管线与 DevOps 文化及其小规模、频繁发布的流程有着内在的联系。
CI/CD 的优势- 快速迭代
在 DevOps 生命周期中采用 CI/CD 实践可以自动执行验证代码库并将更改部署到代码库的手动工作，从而加快开发速度。
- 代码简洁
全天签入大量微小更改可大幅降低将构建中断错误引入源代码的风险。
- 更快地修复错误
更频繁地将较小的变更集与 CI/CD 合并，可以更轻松地识别代码错误并在它们变成大问题之前修复它们。
- 缩短反馈循环
CI/CD有助于缩短反馈循环----核心DevOps原则---- ⁇ 因为较小的迭代更改更容易集成、测试和部署。
- 改善协作
CI/CD 通过定义代码提交和构建启动的流程和时间表，明确工作内容。有了更清晰的目标，团队才能更敏捷地前进。
- 客户更快乐
由于构建始终通过 CI/CD 做好发布准备，客户体验到的服务中断更少，他们的反馈可以更快地集成。
敏捷是否与 CI/CD 相同？敏捷的工作流程和 CI/CD 是相关的，但它们是不一样的！它们描述了软件开发管线的完全不同的方面。敏捷开发（Agile development），指的是软件开发中工作流的管理、进度的达成和团队组织的过程或方法。敏捷的方法论通过倾听和响应客户的需求并让他们参与开发过程的每个阶段，在拥抱变化的同时加快交付。
CI/CD 依靠自动化来消除在发布和改进软件时产生瓶颈的人为因素。在 CI 和 CD 中，测试在整个管线中都是自动化的，并且经常执行，以最大限度减少修复缺陷的成本和时间。
您应该每隔多久就部署一次以进行持续部署？对于 CI/CD，应始终频繁发布，以避免将来出现问题，并确保软件始终处于可发布状态 - 通常一天部署多次。CI/CD 团队的一个常见假设应该是实现“恒定”版本，但情况并非总是如此。发布周期可能会有很大差异，具体取决于您的产品、版本和您可能需要考虑的其他因素，例如：
1.是关键还是次要修复？
2.您是否在跟踪每个构建之间的回归计数？
3.是否有QA团队？
4.代码库是否有单元测试？
5.是否有代码重复？
这些只是考虑发布策略和管线时需要考虑的几个方面，但每个团队的情况大不相同。不同的产品需要不同的方法。
持续部署是否值得？这个问题没有一刀切的答案。在投资持续部署之前，企业必须先评估其产品的最大风险是什么，然后确定部署软件的方式的权衡。
产品的成功取决于能够快速迭代、获得客户反馈并持续进行更改。如果您优先考虑缩短反馈循环和构建高响应的业务，则持续部署将产生巨大的影响并带来丰厚的利润。
但是，如果业务没有很多客户，那么实施增量部署的好处是增加的价值更少，成本更高。您选择部署的暂存环境最终取决于您的业务需求、工作流程和预算。
持续交付的确鼓励配置，因为它会不断更改配置中的原代码。这可以确保配置能够跟上随时间推移可能出现的代码错误。