CI/CD 最佳做法
CI/CD 的优势众所周知，但怎样才能充分利用这些 DevOps 流程呢？
持续集成、交付和部署简化了构建、测试和发布代码的流程。 与传统方法相比，这些流程可以帮助您更快地将正常运行的产品交付到用户手中。 正确执行的自动化构建管道将帮助您和您的团队持续地快速交付正常运行的软件，并及时获得对最新更改的反馈。
我们来探索您应该考虑应用于管道的持续集成和交付最佳做法。
更早提交，更常提交
确保所有源代码、配置文件、脚本和依赖项均存储在版本控制中是实施持续集成的重要初始步骤。
但只有版本控制系统还不够 – 如何使用它才是关键。 持续集成的目标是使来自多个贡献者的更改实施起来更容易。 这种方式的关键在于更频繁地提交和共享代码更改。
运作方式如下：
- Each commit triggers a set of automated tests, providing rapid feedback on your changes to address any bugs quickly. 您提交的频率越高，越能定期收到反馈。
- 与团队频繁共享更改可以确保大家都基于相同的基础进行构建，从而可在整合大型、复杂的更改时帮助您进行协作并降低合并冲突的风险。
- 您的分支策略决定了将更改推送到的分支，是 main 分支、专用功能分支，还是指定的开发分支。
- 作为指导原则，目标是让团队中的每个成员每天至少提交并共享一次更改。
克服最初的障碍
频繁提交最开始可能会让人感觉不适，这通常是由于害怕受到审查或处理的任务超出了一天的工作量。 在团队内打造一种协作而非评判的文化至关重要。 实施对工作做法的更改时，讨论如何作为团队开展工作会很有帮助。 将任务拆分成更小、更容易管理的区块可以帮助个人采用这种做法。
保持绿色构建
如果您维护一个持续可发布的代码库，便可充分利用 CI/CD 做法。 这种方式可以在 bug 出现时予以立即解决，从而提高效率，并在生产中出现问题时迅速找到修正方法。
自动化测试和管道阶段可对代码是否可发布提供即时反馈，而这种最佳做法则侧重于如何应对其高亮显示的任何问题。
协作解决问题
团队应共同承担构建责任，在出现故障时优先快速修复。 团队成员应协作解决问题，而不是责怪最后作出更改的开发者，以此培育一种建设性文化，加强 CI/CD 工作流，支持持续改进，尤其是在面临压力的情况下。
预防简单故障
为了降低由于语法错误或缺少依赖项等简单错误造成的构建失败的风险，团队成员应先在本地构建并运行初始测试，然后再共享自己的更改。 大家都应该使用与 CI/CD 系统相同的脚本，以避免重复劳动。
只构建一次
一个常见的错误是为 CI/CD 管道的每个阶段创建一个新构建。 为不同的环境重新构建代码会带来不一致的风险，并意味着您无法确信之前的所有测试都已通过。
相反，应在构建管道的每个阶段推进使用相同的构建工件，并最终将其发布上线。
维护不受系统约束的构建
在部署脚本中调用变量、身份验证形参、配置文件或脚本，而不是将它们嵌入到构建本身，从而确保构建不受系统约束。
集中对构建工件进行版本控制和存储
将构建工件视为源代码的产物。 在 Nexus 等中央工件仓库（而不是源控制系统）中对它们进行版本控制和存储。
自动部署
使用 CI 服务器将相同的构建工件自动部署到每个测试环境。 随着工件通过每个阶段，您的团队成员对其可靠性的信心会逐渐增强。
简化测试
虽然 CI/CD 在很大程度上依赖于自动化测试来确保软件质量，但这并不意味着您应测试每一种可能出现的情况。
平衡测试覆盖率与性能至关重要。 如果测试需要过长的时间才能得出结果，则存在个别人寻找理由和方法来绕过或加快此流程的风险。
采用分层测试覆盖范围
分层构建自动化测试覆盖范围，从单元测试开始，然后是集成或组件测试。
优先处理快速反馈
先运行快速完成的测试，以尽早获得反馈。 通常情况下，单元测试运行速度最快。
考虑并行测试
考虑将测试拆分成多个批次，然后并行运行这些批次，从而更快地获得结果。
逐步引入时间较长的测试
仅当速度较快的测试已通过且您已对构建建立信心时，再引入运行时间较长的测试。
限制对人工 QA 的依赖
考虑到人工质量保证需要的时间和人力，最好将这一阶段限制在所有自动化测试均已成功完成之后。
侧重于较高级的测试
不要使用运行时间较长的测试来检查每种可能出现的情况。 优先通过较低级别的测试对更广的覆盖范围进行测试，并针对产品和用户的特定高风险领域集中进行较高级别的测试。
清理环境
使预生产环境长时间运行会导致其设置与原始设置之间产生差异，并且各设置之间也存在差异。 这种配置偏离会导致测试结果不一致，从而破坏 CI/CD 流程。
在每次管道运行之间刷新测试和暂存环境是值得投资的最佳做法。
使用容器或虚拟机
将测试环境托管到容器或虚拟机中，以实现快速刷新。
采用“基础架构即代码”的方式
编写创建或拆除环境过程的脚本。 随后，您可以通过 CI/CD 服务器自动执行这些步骤。
考虑可扩缩性
编写环境创建脚本可以更轻松地扩展 CI/CD 流程并同时运行多个管道。
避免静态环境
如果您选择静态环境，则需要对每个环境进行维护，以避免出现配置偏离。 这样会拖慢 QA 流程并推迟发布时间。
确保管道安全
CI/CD 管道会让人接触到要部署到生产的代码和凭据，这使得 CI/CD 通道成为攻击者的首要目标。 因此，务必向 CI/CD 流程应用安全最佳做法。
- 版本控制访问：保护对版本控制仓库的访问，要求贡献者使用多重身份验证。 如果您允许第三方贡献更改，则应制定相应的流程在触发构建前审查第三方的更改。
- 凭据管理：要在 CI/CD 管道中访问服务和环境，通常需要使用凭据和 API 密钥。 切勿将凭据存储在源代码中。 应使用专用的密钥库，并确保凭据未泄露到日志或构建工件中。
- 依赖项检查：作为持续集成检查的一部分，检查第三方依赖项是否存在已知漏洞。
- 安全通信：确保 CI 服务器与构建机器之间的通信是安全的，并确保所有机器可以及时安装最新补丁。
- 最小特权原则：在管道中应用最小特权原则。 这样，如果帐户被入侵，攻击者就更难以进行跳岛攻击。
- 更改管理：为管道配置实施更改管理，以便在应用任何更改前进行审查。
坚持使用您的流程
一旦您投资了 CI/CD 策略并构建了让您对发布充满信心的可靠管道，您就不想让个别人绕过该流程，从而破坏您为此所做的努力。
人们经常想绕过 CI/CD 流程来实施次要或紧急更改。 但千万不要妥协，原因如下：
- 跳过自动化质量保证阶段可能会引入本来可以发现的 bug。
- 如果没有可用于测试的构建，发布到生产中的问题更难以再现和调试。
- 诊断和修正“紧急”发布中的问题所需的时间可能比采用正常自动化流程的时间更长。
如果有人要求绕过该流程，请耐心向其说明 CI/CD 管道的优势。 还可以问一下现有流程中是否有任何部分可以改进。
监控和衡量您的管道
管道设置流程的一个组成部分是为生产环境（即产品）实施监控。
最佳做法是为 CI/CD 管道本身设置类似的监控形式。
分析 CI/CD 指标
使用您的 CI/CD 工具收集的指标确定可能存在的问题和需要改进的领域。
监控构建频率
对比每周、每天或每小时触发的构建数量，以了解您的管道基础架构的使用模式。 监控有助于确定您是否需要扩缩，并识别峰值负载时间。
跟踪部署速度
跟踪一段时间内的部署速度，以发现趋势，并评估何时投资进行性能优化。
通过自动化测试生成洞察
使用自动化测试得出的统计数据找出可以受益于并行化的领域。
审查 QA 结果
找出日常被忽略的 QA 结果，查看可在哪些方面简化测试覆盖范围。
团队合作
制定成功的 CI/CD 工作流取决于团队和组织文化，而不仅仅是您采用的流程和工具。
持续集成、交付和部署是核心 DevOps 流程。 目标是打破开发者、QA 工程师和运营人员之间的传统壁垒，鼓励各学科之间进行协作。 采用这些 DevOps 最佳做法有几点好处。
增强可见性和协作
团队成员可以全面了解整个工作流程，并有机会开展协作，从而获益于不同领域的专业知识。
共同担责
共同承担维护管道的责任可以防止任何一个人成为单点故障。
赋权和贡献
鼓励共同承担软件交付的责任可以让所有团队成员都能做出贡献，无论是修正构建、自动执行任务，还是改进流程。
打造信任文化
打造信任文化，让团队成员能够尝试和分享想法，让组织从中受益，并改进您交付的软件。
出现问题时，您可以借此机会学习，并进一步提高 CI/CD 做法的稳健性和有效性。
为何遵循 CI/CD 最佳做法？
遵循持续集成、交付和部署的最佳做法具有诸多好处。
加快交付速度
自动执行构建、测试和部署任务可以加快发布流程，让您能够更快速地交付软件更新。 自动化 CI/CD 对于缩短上市时间和快速向用户交付功能至关重要。
定期反馈
更频繁地部署更改让您可以定期收集用户反馈。 您可以使用用户的洞察来帮助完善计划和调整策略。
提高代码质量
自动化 QA 流程可以在开发周期中更早地检测到 bug，从而能够更快地解决问题，并促进交付质量更高的代码和更强大的软件。
提高用户满意度
自动化检查可以确保按照一致的标准对每个更改进行检查，从而最大限度地降低 bug 影响生产的风险。 因此，用户的体验更加顺畅，停机的可能性也会大大降低。
有更多时间发挥创造力
由于自动执行构建、测试和部署软件的重复步骤，团队成员可以将更多时间投入到开发新功能、进行创新设计或加强整体 DevOps 做法等创造性任务中。
如何实施 CI/CD 部署策略
实施持续集成、交付和/或部署可能让大家觉得是一项艰巨的任务。 成功的 CI/CD 策略涉及到多个关键元素，并需要一定的时间才能打造出坚实的 DevOps 文化。
制定清晰的目标
就像在软件开发项目中一样，制定目标并向团队传达非常重要。
无论目标是每周发布一次并持续交付到预生产环境，还是追求通过向用户提供更新进行持续部署，制定明确的目标都至关重要。
处理可管理的区块
制定目标后，将达成目标所涉及的步骤分解成可管理的区块。 逐步实施管道意味着您可以从一开始就体验到 CI/CD 的优势。
从 CI 开始
大多数团队的起点是持续集成。 CI 涉及到版本控制、分支策略、添加或扩展自动化测试覆盖范围，以及开始自动执行构建和测试等任务。 使用 CI 服务器可以帮助您协调这些活动、整理结果并实施逻辑，以自动执行构建和测试的连续阶段。
继续进行 CD
制定自动化 CI 流程后，您可以进一步实现持续交付或部署。
长远看来，自动执行环境创建可以节省时间，并提高您的管道的可靠性和稳健性。 您随后可以使用自动创建的环境运行更多自动化测试和人工测试。
分析数据
实施期间和制定 CI/CD 策略后，您都可以分析 CI/CD 工具提供的数据并与团队成员互动，以确定改进流程的机会。 这种迭代方式可以确保实现持续改进，并最大限度地发挥 CI/CD 为您的团队和组织带来的优势。
总结
采用这些 DevOps 最佳做法将帮助您最大限度地利用持续集成、交付和部署流程：
- 经常提交代码更改。 这让您可以更轻松地集成更改，并意味着您可以定期通过自动化构建和测试获得工作反馈。
- 优先确保构建不存在错误。 将代码库保持为可部署状态可以提高代码质量，并确保您能解决生产中的紧急问题。
- 只构建一次。 在连续的环境中推进同一个构建工件意味着您可以确信代码已经通过每个阶段的测试。
- 简化自动化测试。 即使是自动化测试，也需要一定的时间来执行。 先运行提供最快反馈的测试。
- 每次管道运行后刷新环境。 这样可以避免配置偏离，并确保您可以信赖每个 CI/CD 阶段的结果。
- 确保管道安全。 CI/CD 管道可以访问源代码和生产环境，可能会成为黑客有利可图的目标，因此实施 CI/CD 安全至关重要。
- 坚持使用您的流程。 当更改比较微小或紧急时，绕过 CI/CD 管道似乎很诱人，但长远看来，代价往往更大。
- 监控和衡量您的管道。 分析管道提供的数据可以帮助您提高管道的稳健性和效率。
- 让流程成为团队合作的成果。 维护管道绝不是一个人的工作。 采用 DevOps 思维可以提供一系列优势。
TeamCity 如何提供帮助
TeamCity 是一个 CI/CD 自动化平台，设计宗旨是帮助您构建和扩缩 CI/CD 管道。 无论您现有的构建和测试自动化水平如何，都可以轻松上手 TeamCity。
广泛集成所有主流版本控制系统、支持流行的构建和测试框架、采用直观的基于 Web 的 UI，这意味着您只需几分钟便可创建第一个管道。 全面支持“配置即代码”允许您通过 UI 生成所有管道定义并将其存储在版本控制中。
TeamCity 的高度可扩缩和高性能设计可以确保通过自动化测试快速获得反馈，同时，无论您的工作地点在哪，与主要 IDE 和消息传递平台的集成都可以提供通知。 广泛的安全功能可以帮助保护您的源代码和管道免受攻击。
随着您的流程的日趋成熟，您可以利用 TeamCity 的内置测试覆盖率报告、不稳定测试识别和构建代理统计数据来不断优化您的 CI/CD 流程。
