安全优先

数据泄露和安全漏洞会给企业带来严重影响，也说明安全不能缺位。持续集成与持续交付（CI/CD）流水线往往持有代码库和部署凭据，因此容易成为攻击目标，并可能成为恶意活动的入口。

为了自动化，敏感凭据常被保存在私有仓库中。应把 CI/CD 系统隔离在受保护的内部网络内，并遵循最小权限原则，以减少风险暴露面。

虚拟专用网络（VPN）、可靠的双因素认证以及身份与访问管理方案，都能增加一层保护。例如，可以将执行代理容器化，并把它们放在受保护的网络中。

还应在项目从开始到结束的整个过程中持续落实安全要求。把安全融入整个开发生命周期的方式通常称为 DevSecOps。

采用微服务架构

如果项目基于单体架构，重构现有应用会带来很大挑战。不过，微服务架构的价值在于：新增功能时不必重新设计整套系统结构。

也可以采用渐进式迁移：保留关键业务系统，同时逐步引入新架构，再有节奏地替换旧系统。这样能让过渡过程更加平稳、可控。

像 Bunnyshell 这样的环境即服务（EaaS）平台，可以在 Kubernetes 上自动部署包含所需微服务的全栈环境，用于 CI 测试。这类自动化有助于构建一致、可重复的测试环境，从而提升 CI 工作流的可靠性。

尽早提交、频繁提交并减少分支

CI/CD 的基本原则，是尽早把改动集成到主要的共享代码库。若多个开发者在发布前才合并大量分歧明显、彼此冲突的改动，集成成本会很高。CI/CD 系统一般只监控和测试一个或少数几个分支上的提交，这能促成持续、渐进的集成，降低集成风险，也让协作过程保持更稳定。

减少甚至消除长期分支，目标是优化开发流程并缩短处理版本控制的时间，把更多精力留给实际开发工作。

要充分发挥 GitOps 的作用，应规律地提交改动，理想情况下至少每天一次。改动既可以直接提交到主分支，也可以从本地分支合并进来。较小、可控的集成增量能避免在发布前集中合并多条分支时出现的大量返工和集成痛点。

这种做法能够简化工作流、改善协作效率，让开发周期更高效。

生产环境只能通过一种路径部署

CI/CD 能提升开发实践和代码质量，部分原因在于它用工具把测试与部署规范落实成门禁。每一项改动都必须遵循组织既定的标准和流程，才能继续通过 CI/CD 流水线。流水线失败会立刻暴露，并阻止相关版本进入后续阶段，从而保护关键环境不受未经信任代码的影响。

要获得这些收益，必须保持部署纪律，让对生产环境的每一次变更都通过 CI/CD 流水线完成。流水线应成为将代码引入生产环境的唯一机制：既可以在测试通过后自动持续部署，也可以由 CI/CD 系统对已充分测试的版本进行人工晋级和审批。这样能够形成可靠、受控的生产发布过程，提高代码质量并降低出错风险。

尽量保持生产与测试环境一致

CI/CD 流水线会推动改动依次通过不同的测试套件和部署环境。改动满足某一阶段的要求后，会自动部署或等待人工部署到限制更严格的环境。早期阶段的目标，是验证改动是否值得继续测试，并逐步推进到更接近生产的环境。

要让测试结果能反映生产行为，测试环境，尤其是后期环境，应尽可能复刻生产环境。预发布环境与生产环境差异很大时，存在问题的改动可能在测试中没有被识别，最终却进入生产。线上环境与测试环境的差异越多，测试对发布后代码表现的预测就越不可靠。因此，测试环境应尽量贴近生产环境，以保证 CI/CD 全流程中的测试有效且准确。

明确测什么、何时测、在哪里测

测试可以分为两类：轻量测试和重量测试。

以一个持续两周以上的 Sprint 为例，可以在 Sprint 结束前 3 天把开发改动合并到预发布分支。这样能留出时间测试、修复关键缺陷并为演示准备环境。预发布代码可以先进行人工测试；如果没有发现关键缺陷，再合并到发布分支。合并进入发布分支后，代码即可自动部署到生产环境。

在把功能分支合并到主开发分支之前，必须先让功能分支同步最新的开发改动。否则可能出现这样的情况：功能分支和开发分支各自的测试都通过，但合并结果却有缺陷。为了保持质量稳定，应先将功能分支合并到开发分支再测试。这个过程可以由 CI/CD 自动执行，并且只有测试通过后，合并结果才应构建并推送到仓库。这样可以保证功能分支合并后，开发分支仍然稳定。

测试套件不同部分的执行速度天然不同。CI/CD 是所有改动进入系统的关口，因此越早发现失败，越能减少在问题构建上浪费的资源。应优先执行速度最快的测试，先用小而快的测试验证构建，再进入更复杂、耗时更长的测试。

如果当前条件不支持隔离测试环境，应在提交到共享仓库前先做本地测试，避免阻塞其他成员。虽然本地开发环境通常无法运行完整的类生产测试套件，但它至少可以确认改动已通过基础测试，值得进入更大的代码库进行集成。

避免重复构建

应避免任何导致源代码被多次编译的做法。即使软件分发前还需要打包或捆绑等步骤，编译过程也应只执行一次，之后分发已编译的二进制产物。CI/CD 流水线的目的，是为改动建立信心，并降低意外影响的概率。

同样，每次迭代都应为最终产物建立版本并发布到 Git。这样在后续拉取或访问仓库时，构建结果仍能保持一致，不会偏离最初状态。

尽可能使用自动化

从手工流程迁移到自动化流程时，首先该自动化哪些任务并不总是明确。渐进式推进看起来更容易，但也可能带来取舍上的困难。因此，应先确定需要优先自动化的任务。

合理的起点是自动化代码编译，因为这能减少人为错误。开发者每天提交代码时，自动化冒烟测试也很有价值。接下来通常优先做单元测试，以减轻开发者的负担。

随后可以自动化功能测试，再自动化用户界面测试。功能测试通常比 UI 测试需要更少的脚本维护，因为 UI 更容易频繁变化。制定自动化优先级时，还应考虑测试之间的依赖关系及其对整体工作流的影响。

使用按需测试环境

可以考虑在容器中运行测试，以减少开发与生产环境之间的变量和差异。这样既能提高 CI/CD 周期效率，也能让测试过程更具敏捷性。

基于容器的临时测试环境能给 QA 团队带来明显收益。与其从 CI 服务器拉取构建后再安装到单独测试环境中，不如直接针对隔离的应用环境执行测试，避免影响其他正在进行的测试。这种方式可以节省时间，并减少出错机会。

创建容器通常不需要单独安装或配置，建立测试环境更方便。容器在不再需要时也可以轻松销毁，清理工作因此更简单。

基于容器的测试能够简化测试工作流，提升环境一致性，并改善整体开发与测试效率。

像 Bunnyshell 这样的环境即服务平台，可以在 Pull Request 触发时，在 Kubernetes 上创建并部署基于容器的隔离测试环境。这样就能在受控、可复现的环境中自动测试改动，提升开发流程的效率和可靠性。

如果希望进一步了解临时测试环境的价值，可以阅读 Bunnyshell 的相关文档，或注册其免费账户。

相关阅读：微服务 E2E 测试为何失败 · E2E 测试完全指南 · 自动化测试的 8 个最佳实践 · 持续测试、持续集成、持续交付、持续部署和 DevOps · 冒烟测试与宇宙飞船