CI/CD 最佳做法

确保所有源代码、配置文件、脚本、库和可执行文件都在源控制中，这是实施持续集成的第一步，让您能够跟踪所有更改。

然而，仅靠工具是不够的，关键在于如何使用。 持续集成旨在通过更频繁地共享较小的更新，使来自多个贡献者的更改更容易集成。

每次提交都会触发一组自动化测试，以提供有关更改的及时反馈。 定期提交可确保团队在相同的基础上工作，从而促进协作，并在整合大型复杂更改时减少麻烦的合并冲突。

为了发挥持续集成的优势，所有人都必须推送到主分支 (master) 与团队的其他成员共享更改，并更新有效副本以接收其他人的更改。 一般经验法则是尽可能每天至少向主分支 (master) 提交一次。

对于经常在长期运行的分支中工作的团队来说，经常将更改推送到主分支可能会导致不适应。 这可能是由于担心受到其他人的审查，也可能是因为任务的规模太大，无法在一天内完成。

营造一种协作性而非评判性的团队文化非常重要，而且，就像有效做法的任何改变一样，团队的工作方式也值得讨论。 作为一个团队，将任务分解成较小的独立块，可以帮助个人采用这种做法。

如果使用长期运行的分支来承载尚未准备好发布上线的新功能，另一个选择是使用功能标志。 这允许您控制特定功能在不同设置中的可见性，使代码更改可以合并并包含在构建中进行质量保证，而不必对最终用户开放。

通过构建解决方案，并在每次提交更改时运行一组自动化测试，CI/CD 管道可以为开发者提供有关其更改的快速反馈。

目的是避免在不良基础上构建，并使代码处于持续可发布状态。 这不仅能在问题出现时尽快解决，还能在生产中出现问题时迅速推出修复方案。

如果由于某种原因导致构建失败，那么使其恢复运作应该是整个团队的首要任务。 怪罪于最后更改的人，将解决问题的任务留给他们，这似乎是一种诱人的方案。 然而，指责其他成员很少能产生建设性的团队文化，更不可能发现问题的根本原因。 让整个团队负责处理失败的构建，并尝试了解导致失败的原因，这样可以改善整个 CI/CD 工作流。 当然，这在压力大、高度紧张的情况下知易行难；发展 DevOps 文化，也是一种持续改进的过程！

如果放弃一切去修复失败的构建，结果却发现根本原因是微不足道的语法错误或依赖项丢失，可能会令人沮丧。 为避免这种情况，团队成员最好在共享更改之前在本地进行构建并运行一组初始测试。 理想情况下，每个人都应该能够使用与 CI/CD 系统相同的脚本，以避免重复工作。 另外，考虑在您的组织中实施 CI/CD 工具。

一个常见的失误是为每个阶段创建一个新构建。

为不同的环境重建代码有引入不一致的风险，这意味着您无法确定先前的所有测试均已通过。 相反，相同的构建工件应该经过构建管道的每个阶段，并最终发布上线。

要将这一点付诸实践，需要构建与系统无关。 任何变量、认证参数、配置文件或脚本都应该由部署脚本调用，而不是纳入构建本身。 这允许将相同的构建部署到每个环境中进行测试，每个阶段都会增加团队对该特定构建工件的信心。

虽然最好将包括构建脚本、配置文件和部署脚本在内的所有内容与应用程序代码置于同一个源控制系统中，但这并不适用于构建工件本身。 作为这些输入的产物，构建不属于源控制。 相反，应对其进行版本控制并将其存储在中央工件仓库，例如 Nexus，再从中将其下拉并部署到各个实例。

虽然 CI/CD 在很大程度上依靠自动化测试确保软件质量，但这并不意味着您应测试所有可能情况。

毕竟，持续集成的目的是提供快速反馈，并以比传统方法更快的速度向用户提供有价值的产品。 这意味着要在测试覆盖率和性能之间取得平衡。 如果获取测试结果花费的时间过长，人们就会寻找理由和方法来规避这个过程。

首先运行最快完成的测试，尽早获得反馈，并且只在对构建有一定信心后，才进行较长的测试。 考虑到手动质量保证所需的时间，以及对检查执行团队的依赖，最好将这一阶段限制在所有自动化测试成功完成之后。

自动化测试的第一层通常是单元测试，您可以用它提供广泛的覆盖范围，并提醒您最新更改引入的任何明显问题。 在单元测试之后，您可能会有一层自动化集成或组件测试，测试代码不同部分之间的交互。

除此以外，您可能会引入更复杂的自动化测试，如 GUI 测试、性能和负载测试或安全测试，最后再进行手动探索性和/或验收测试。 为了使这些运行时间较长的测试（无论是自动还是手动）更加高效，应关注对您的特定产品和用户构成最大风险的方面。

为了充分利用 QA 套件，建议在每次部署之间清理预生产环境。

当环境长时间运行时，很难跟踪已应用于各个环境的所有配置更改和更新。

随着时间推移，环境与原始设置以及环境之间都会产生差异，这意味着在一个环境中通过或失败的测试在另一个环境中可能不会返回相同的结果。 维护静态环境也会带来维护成本，这会拖慢 QA 流程速度，延迟发布流程。

使用容器托管环境和运行测试，以基础架构即代码方法为这些步骤编写脚本，即可为每个新的部署轻松启动和拆除环境。 每次实例化一个新容器都可以确保一致性，并允许您更轻松地扩缩环境，因此可以根据需要并行测试多个构建。

构建可靠、快速且安全的 CI/CD 管道，将使您对构建质量充满信心，您肯定不希望这一流程由于任何原因被绕过而使这份努力遭到破坏。

通常，规避发布流程的要求是出于改动不大或紧急（或两者兼有），但听从此类要求可能会得不偿失。

跳过自动化质量保证阶段有可能引入可避免的问题，而由于构建无法随时部署到测试实例，因此重现和调试问题要困难得多。

在某些时候，您可能会遭遇绕过该流程的要求：“仅此一次”。 那时您可能完全处于救火模式，但仍然值得回顾或事后了解其背后动机。 这个流程看起来太慢了吗？ 也许在性能上还有待改进或完善。 关于何时使用是否存在误区？ 传达 CI/CD 管道的优势有助于让利益相关者参与进来，并在下次时间紧急时避免这类要求。

作为设置 CI/CD 管道的一部分，您可能对生产环境实施了监控，以尽早提醒您注意问题的迹象。

就像您正在发布的产品一样，您的构建流程也将从反馈循环中受益。

通过分析 CI/CD 工具收集的指标，您可以确定潜在的问题和需要改进的地方。

• 比较每周、每天或每小时触发的构建数量，可以提供实用的洞见，让您了解管道基础架构的使用方式、是否需要扩缩规模以及何时出现峰值负载。
• 随时间推移跟踪部署速度并监视其花费的时间是否有增加的趋势，可以指示何时应投入性能优化。
• 来自自动化测试的统计数据有助于确定将从并行化中受益的领域。
• 审查 QA 结果，找出经常被忽略的结果，可以衡量精简质量保证覆盖范围的潜力。

构建有效的 CI/CD 工作流，既关乎团队和组织文化，也关乎您使用的流程和工具。

持续集成、交付和部署均为 DevOps 做法。 它们依赖于打破开发者、QA 工程师和运营部门之间的传统孤岛，以及鼓励各学科之间的协作。

打破孤岛可以使团队对端到端工作流有更多的了解，有机会展开协作并从不同的专业领域获益。 维护管道绝不是一个人的工作。 实施 CI/CD 平台也可能有助于改善您的运营实践。

建立交付软件的共同责任感，您可以让团队中的每个人都能做出贡献。无论是修复构建、容器化环境，还是将一个经常难以完成的手动任务自动化。

促进信任文化，让团队成员能够尝试和分享想法，这不仅有利于员工，也有利于组织和您交付的软件。 如果出现问题，与其把重点放在将责任归咎于某个团队成员，不如从失败中吸取教训；了解根本原因以及今后如何避免。

借此机会改善您的 CI/CD 做法，使其更加稳健高效。 让团队成员在不必担心受到责备的情况下进行实验和测试，您将创造一个持续改进的良性循环。