在第 3 章中，我们探讨了持续集成的基础，重点关注 CI/CD 流水线中的早期步骤：主要是构建与部署前测试。我们还演示了一个在打开 PR 时触发的示例流水线，如图 4-1 所示。
该流水线会构建并打包代码、执行静态代码分析，并运行早期且快速的测试（包括单元测试和轻量级集成测试），同时把构建与测试反馈回 PR。这些步骤确保 PR 中的代码已"可合并（merge-ready）"，让我们有信心在合并后代码按预期工作且不会引入回归问题。假设 PR 中的改动已就绪，开发者即可合并该 PR。
新代码合并后，下一步就是为上线做准备：先部署到测试环境，再运行一系列测试。AI 和机器学习（ML）工具正被集成到部署流程中，它们帮助团队做出更好的部署决策、前瞻性地识别潜在问题，并简化验证流程。良好落地的 AI 不会增加复杂度，反而能降低开发者的认知负担并提升部署可靠性。
在 CI 步骤与正式发布之间，我们的关注点主要在测试：我们要判断该版本是否已经准备好面向用户。如果可以安全发布，就应尽快交付，以提升用户体验，并有望提高客户参与度和忠诚度；如果软件存在问题，则需要尽快发现并处理。这种取舍会影响有价值更新的发布节奏；而缺陷从被引入到被反馈回开发团队之间的时间越长，相关代码对开发者来说就越不"记忆犹新"，他们需要花更多时间重新熟悉相应代码，从而提高修复成本。如果开发者已经投入到下一个任务，也可能被打断，导致该任务成本上升。
当版本准备就绪，我们会将其部署到一个或多个环境，在真实运行的应用上进行测试。正是在这些预生产环境中，我们弥合了开发与真实使用场景之间的鸿沟，确保软件不仅功能正确，也足以应对真实世界的状况。
图 4-2 给出了整个交付流程的高层示意。越来越多的 AI 正被嵌入到这条流水线中，用以强化测试与部署决策。
在本章中，我们将介绍如何准备基础设施、将应用部署到一个或多个预生产环境，并在其上开展测试。此外，我们还将涵盖以下关键最佳实践：
- 使用 IaC 创建与生产一致（但更小）的低阶环境
- 采用"类生产（production-like）"的部署方式，使应用在各环境中的迁移一致
- 将测试与部署流水线打通
- 明确哪些环节适合引入 AI、哪些环节需要保持谨慎
这一阶段是流水线中的关键路口，开发与运维的关切在此交汇。通过理解并落实这些最佳实践，无论项目规模与复杂度如何，你都能为项目确定合适的测试环境数量与类型，在开发速度与运行稳定之间取得平衡，确保软件经过充分验证、随时可发布。
建立统一的部署流程
继续沿着交付流水线迈向生产环境，我们需要确定所需的部署步骤与部署环境。若想让交付过程可预测、可依赖，就要让部署步骤与环境同样可预测、可依赖。
本节将介绍从测试到生产保证可预测性与可靠性的最佳实践。第 8 章将更详细讨论生产发布与生产环境。
在所有环境中一致部署
自动化是 DevOps 的基石；交付流水线的一项关键职能，就是自动化预生产环境的搭建以及对这些环境的部署。正如在发布前要验证软件本身一样，我们也需要验证部署方法本身。
做法是：对预生产与生产使用同一套部署方法。这样不仅能验证部署流程，也能在把同样步骤用于生产时将突发问题的风险降到最低。
以下实践有助于达成这种可预测性。
使用一致的工具链
不少团队里，开发者会用简单工具为测试环境"自建"轻量部署流程；运维团队则专注于面向生产的企业级流程。两套流程不一致，往往导致"出事才沟通"：开发改了流程却没通知运维，直到某个环节出错。
应避免这种做法，它既削弱了非生产环境测试的有效性，也导致自动化脚本的重复劳动。应为所有部署采用统一的工具链。
推动一致性的一个办法，是向开发者提供易用的预置模板流水线（常称为"黄金流水线""铺就之路 / paved roads"）。第 10 章会详述。至少，开发与运维应就一套共同的部署工具达成一致。
统一的流水线步骤与部署策略
无论你使用 CI/CD 工具还是自定义脚本，各环境中的动作顺序都应保持一致。金丝雀（canary）、蓝绿（blue-green）等高级策略通常用于降低生产发布风险------如果生产使用了这些策略，预生产也应复用。同理，若生产用特性开关逐步发布功能，测试环境也应用特性开关进行验证。策略一致可最大程度减少因差异或疏漏而引入的问题。
第 7、8 章将深入讲解生产发布与上述渐进式部署策略。此处只需记住：在各级环境中复用相同的步骤与策略。即便测试环境因成本或资源限制更小，也要"按生产方式部署"。例如，生产中的滚动发布可能一次在 10 个目标中的 2 个节点上滚动；测试环境可改为在 3 个目标中的 1 个节点上滚动。这样可以确保每个版本在测试环境中就已把生产部署步骤与策略跑通。
第 7 章还会讨论如何用 AI 校验部署是否在新环境中引发问题------这些方法同样应在低阶环境中使用，以验证环境有效，避免在"坏安装"上执行测试。
用参数化处理差异
环境之间难免存在差异：目标名、服务 URL、密码等。不要为每个环境单独写脚本，而应通过变量来承载差异。这样你只需维护一份可复用的脚本/流水线，并在运行时按目标环境注入参数。
通过一致性的部署，你将构建出稳健可靠的交付流水线，增强团队对无缝高效发布的信心。
用 AI 加速流水线创建
第 3 章已讨论自动生成流水线。模板化依然是良好范式------让你的 AI 基于组织模板，为项目与团队自动填入正确的调整与变量。无论是人工还是由 AI 创建/维护流水线，"让流水线代码越少越好"。
借助基础设施即代码（IaC）确保部署一致性
我们希望交付到生产的环境是可预测、可一致的。IaC 不仅能带来一致性，还能让我们像管理应用代码一样严谨地管理配置------从本质上讲，IaC 把基础设施配置当作软件代码来对待。
工程师在本地修改 IaC 并测试，通过后像提交应用代码一样把变更提交到版本控制系统（VCS）。借助 VCS 与 CI/CD，我们可以：
- 协作与代码评审：多人并行修改、解决冲突，并可通过策略要求对基础设施变更进行评审。
- 分支与试验：用分支试验不同配置，不影响主环境。
- 可追溯与审计：完整的变更历史与提交信息记录"为何而变"，满足安全合规审计。
- 回滚与恢复：若配置变更引发问题，快速回滚到稳定版本；灾难恢复时也可用版本化配置重建到已知良好状态。
- 自动化测试：在流水线中对 IaC 进行语法检查、安全扫描、合规测试；随后将变更应用到预发布环境做集成测试，最终按谨慎的发布策略推进到生产。
- 安全：用版本控制来约束配置变更的权限与流程，确保只有授权人员可修改。
许多人都经历过这样的场景：应用在开发与预发布环境一切顺利，一到生产就"翻车"。根因往往是各环境的基础设施配置不一致。用 IaC 描述配置，你可以确保从开发到生产的环境按同一标准构建。
这种方法让基础设施以可控、可预测的方式演进，消除"在 QA 好好的"为何到生产就不行的问题。把基础设施与应用代码同等对待，你会获得一致性、可靠性与敏捷性。
IaC 的收益还不止于此：你可以一条命令拉起一套与现有基础设施完全一致的新环境；环境既是可复现流程，也是最新、准确的"活文档"。环境易建易毁，用完即拆既省资源又降成本，并且随时可无痛重建。
要有效实施 IaC，需要合适的工具。Terraform 及其更开放的分支 OpenTofu 走云中立路线；如果你深度采用某一云，AWS CloudFormation、Azure Resource Manager 等原生工具可能更合适。
此外，得益于大语言模型，IaC 很快就从 AI 中受益良多：AI 编码助手能够生成与讲解 IaC，降低上手门槛。未来，若能结合云端运行时数据（如性能与成本）或平台侧的云成本能力与 IaC 管理，代码生成工具还可能基于真实负载做出如下运行时优化建议。
结合 Git 工作流运用 GitOps
GitOps 是一种较新且日益流行的软件部署方法，建立在代码仓库的能力之上。采用 GitOps 时，你会用受版本控制的配置来描述基础设施的期望状态 ，这种描述是声明式 的。GitOps 工具包含一个代理（agent），会定期将实际环境与 Git 中配置所描述的期望状态进行对比并自动对齐（reconcile） 。与其运行脚本直接部署软件，你只需更新代码仓库里的配置 来触发部署。该方法及其工具通常用于 Kubernetes 环境，以在机器集群上编排容器化应用。
在这种方式下，你依赖代码仓库来执行安全与治理 并落实组织的策略（例如通过代码评审与审批实现监督）。你的更新可追踪、可审计；你可以协作、试验，并对用于部署的软件配置进行回滚。一旦你提交并合并了更改，GitOps 的对齐代理就会接手，获取更新并把变更落实到目标环境。
之所以广受青睐，是因为用代码仓库来管理复杂编排云系统的繁复配置非常契合其能力。此外，GitOps 还能解决**环境漂移（environment drift）**问题------也就是运行中的环境偏离了期望状态。对齐代理会自动检测并修复，防止环境不一致。
需要注意的是，把 GitOps 融入 CI/CD 流水线比"用脚本直接推应用"更复杂。采用 GitOps 时，流水线需要自动化以下步骤：
- 从代码仓库拉取配置；
- 更新配置以引用你应用的最新版本；
- 将更新后的配置合并回 Git；
- 随后交由 GitOps 对齐去完成部署。
当你的应用跨地域、多集群 部署时，也会遇到复杂性：许多 GitOps 对齐器更擅长在单集群 部署，跨集群的一致性与同步会较难。你可能需要在"单一事实源 "与"针对特定集群定制配置"之间取得平衡。商用 GitOps 工具通常在这些更复杂场景下提供更好的编排与可观测性，弥补开源工具的不足。
尽管存在挑战，但就协作、可追溯性与自动对齐而言，GitOps 对重度使用 Kubernetes 的组织仍是极具吸引力的选择。
CI/CD 流水线中的持续交付、部署与测试
既然我们已经理解了可预测、可依赖 的部署步骤与环境的重要性，接下来回到交付流水线本身：当新代码合并 后，我们希望把它部署到一个或多个环境 ，以便在运行中的应用上开展测试。图 4-3 展示了一个示例流水线。
在本节中，我们将聚焦于这条流水线：
- 代码触发
拉取请求（PR）已评审、通过并合并到主分支。在这条流水线中，PR 合并会触发流程。 - 持续集成
流水线会重复上章回顾的持续集成步骤：检出代码、构建并执行 CI 测试。 - 预置基础设施
流水线会预置测试所需的预生产环境。 - 部署到一个或多个预生产环境
流水线将应用部署到一个或多个预生产环境。 - 对已部署应用进行测试
流水线对已部署的软件进行测试。可运行的测试类型取决于软件类型以及组织的优先级。下一节我们将详细介绍多种测试类型。流水线可以并行或串行地运行多类测试。有些测试可以复用同一预生产环境，另一些则可能需要为测试量身定制的预生产环境。一般而言，会优先执行更快速的测试。 - 部署到生产环境
最后一步是将版本部署（或"提升"）到生产环境。根据你的交付流程，是否部署到生产可以自动化决策，或要求人工审批。第 7 章我们将讨论提升策略及生产部署步骤。
持续交付 vs 持续部署
"持续交付"（Continuous Delivery）与"持续部署"（Continuous Deployment）这两个术语常被混用。通常、宽泛地讲，持续交付是指将发布过程自动化到"生产部署之前"的所有环节，在上线前需要一次人工批准；而持续部署则是将整个流程完全自动化，包括部署到生产。
之所以会产生混淆，是因为流水线会自动部署到中间的测试环境。有些人用"持续交付"来涵盖这些自动化的中间环境部署；也有人把它限定为"不自动部署到任何环境"的流程。同样地，"持续部署"有时也被广义地用来指代任何自动化部署（包括到测试环境）。
为避免歧义，我们倾向于广义使用"持续交付"，指频繁向用户交付软件的过程。减少人工步骤通常会让这一过程更频繁。当我们讨论某个具体交付流程中的部署步骤时，会说明部署到的环境（中间或生产）以及部署方式（自动或人工）。
测试类型
测试环境对运行测试至关重要，但具体选择哪些测试高度依赖于应用类型、目标用户、软件架构，以及时间与预算约束。比如，网站的测试侧重点通常与嵌入式软件或 Web API 大相径庭；强监管行业的测试优先级也会不同于面向海量零售用户、需追求直观易用的软件。你选择的测试类型与频次，会显著影响应用质量、基础设施成本与整体交付速度。
AI 驱动的测试平台越来越多地使用机器学习来优化测试策略。这些平台会分析历史测试数据、代码变更、应用架构以及以往部署问题，智能选择与排序测试。例如，AI 驱动的测试选择工具会找出对每次代码变更最有影响力的测试，从而显著加快测试周期。Harness、Tricentis SeaLights、CloudBees Launchable 等厂商都在使用 AI/ML 技术优化测试选择。
以下是此阶段常见的测试类型：
端到端（E2E）/ 功能测试
最直观的测试类型：以真实用户场景为蓝本，验证从头到尾的业务流程，判断软件是否按预期工作。可以手工或自动执行；现代团队更多采用自动化。Selenium 是常用的开源自动化框架，许多商业工具也基于它构建。ML 早已用于这些工具，而如今正逐步转向"AI 优先"的方式，稍后我们将深入介绍。
AI 驱动测试
AI 可自动生成测试用例、识别边界场景，并从既往测试运行中学习，聚焦最可能出问题的区域。AI 测试很可能会补充或成为你端到端（功能）测试方案的一部分。
API 测试
一种功能测试，验证 API 是否按预期工作。在分布式系统中，服务通过 API 交互，因此保证 API 表现良好很重要。常见工具包括 SoapUI、Postman、Insomnia 与 Swagger。AI 增强的 API 测试不仅做简单校验，还会智能探索 API 行为与边界情形；它们可基于 API 文档或实际使用模式自动生成测试场景。
用户体验（UX）测试
开发者、测试人员与产品经理评估新功能是否易于、直观地被使用。虽然测试的系统可能与端到端测试相同，但关注点在"可用性"。
用户验收测试（UAT）
作为最终检查，确保软件满足终端用户需求、满足需求规格并按预期运行。UAT 往往会包含多种测试（端到端、用户体验、性能等），从用户视角对发布进行正式验收。
无障碍（可访问性）测试
确保软件可被视力、听力或认知障碍等人群使用，同时满足法律、合同与合规要求。开源扫描器包括 Lighthouse 和 Pa11Y。包括 accessiBe 在内的一些公司也开始提供 AI 增强的测试与修复工具。
本地化测试
面向全球用户的软件需要进行本地化测试。它全面评估产品在特定目标语言与文化下的语言准确性、文化适配性与功能正确性，包括校验翻译、调整视觉以适应文化敏感点，并确保软件在本地格式与法规下正确运行。
性能测试
通过模拟负载来评估应用在不同条件下的速度、响应与稳定性，帮助定位性能瓶颈并确保能承载预期流量。对于有季节性高峰的应用尤为关键。常见工具有 Apache JMeter、Gatling、Grafana k6。AI 可利用性能测试数据推荐应执行的韧性测试；这些 AI 性能测试系统相较传统阈值法能更准确地检测性能异常：它们会建立基线并识别微妙偏差，提示潜在问题。更先进的平台还能将测试结果与代码变更、架构拓扑关联，定位导致性能退化的具体组件或变更。
韧性（容错/混沌）测试
在现代分布式系统中，组件众多，"某处出故障"几乎是必然。韧性测试（又称混沌测试）评估当依赖服务失效时软件是否仍然"可用"。第 6 章我们将重返这一主题。
安全测试
识别应用中的漏洞与薄弱点，防止被攻击者利用，确保安全与完整性。动态应用安全测试（DAST）是自动化渗透测试的一种，会在运行中的应用上查找安全缺陷，模拟恶意用户的攻击方式。常见免费工具为 ZAP，商业产品如 Veracode、Checkmarx 等。第 5 章我们将再次讨论安全测试。
需要注意的是，上述分类并无放之四海而皆准的标准，不同组织术语也会不同。你选择哪些测试、如何归类，取决于你的开发流程、架构与风险偏好。
基于"意图"的功能/端到端测试
传统的功能与端到端自动化测试多依赖脚本或简单的录制回放。虽然上手快，但只要 UI 发生细微变化，这些测试就很脆、维护成本高，常导致团队放弃自动化或缩小范围。
一种新兴的"AI 优先"测试思路------基于意图的测试 ，旨在化解这些痛点。团队不再显式编写或手动录制每一步，而是描述测试场景的意图：即期望的结果，而非达成结果的具体操作序列。AI 原生测试工具会像真人用户一样与应用交互，动态生成并执行测试。
例如：与其录制电商结账流程中的具体点击与输入，不如直接描述目标："使用信用卡购买一件商品"。AI 会自动找出应用中最合适的路径，智能地与按钮、表单和流程交互。
显著收益之一是测试的鲁棒性 大幅提升，解决了 UI 测试"脆"的问题。即便 UI 后续改版，AI 也能适应新布局或交互，大幅降低维护开销。多年来，自动化测试工具尝试用追踪 DOM 对象、引入 ML 等方式做"自修复"；而理解测试"意图"、在 UI 大改时尝试重生整段脚本，使可恢复性达到了新水平。
这种工具也有助于从"专业测试人员"向"开发者自持测试"的转变：它们会基于现有测试推荐补充的测试与断言，提醒乐观的开发者覆盖边界与异常场景。
更高级的用例包括：把 Selenium、Playwright 等传统工具编写的测试迁移到基于意图的工具中；不仅生成并运行单个测试，还能生成并执行完整的测试用例集。
传统测试 vs "挖空中间层"策略
在传统开发模式下，测试往往被切割到各自独立的环境中，以确保例如：手工的用户体验测试不会被并发的性能测试干扰。但代价是环境数量膨胀、成本高且管理繁琐。当单个新版本必须闯过众多关卡时，面对日益加快的发布节奏与升级的应用复杂度，这种方式愈发难以为继。
随着你加速发布、系统变得更复杂，在多个阶段、每个阶段都要新建环境的做法将越来越不可持续。图 4-4 展示了这种分阶段的方法。
另一方面，更现代的测试思路对这种模式提出了挑战，这种做法有时被称为"挖空中间层"。它不是在多个环境中按顺序进行多轮测试，而是减少环境数量，在更少的环境里并发运行测试。这一实践主张测试同时"左移"和"右移"。
我们在第 3 章介绍了安全左移。通过把 SAST、SCA、依赖扫描和密钥泄露检测前置到预部署步骤，我们的示例流水线体现了左移。我们把这些关键测试前置，并将其作为合并代码的前提条件。单元测试和其他早期测试作为合并流程的一部分完成，也属于左移做法。这有助于更早发现问题，减少后续大量下游测试的需要。
右移则主张把某些传统上位于后期环节的测试类型，放到线上生产环境针对新版本执行。与其在一个或多个预生产环境中反复迁移发布并在这些隔离环境里测试，不如直接把应用部署到生产并在那里完成验证。比如，负载测试往往难以做好，且可能需要很大的环境。把新版本仅部署到生产的一部分目标上，对这部分基础设施施加负载，并用生产可观测性工具衡量影响，就可能成为传统负载测试的可行替代方案。图 4-5 展示了这一方法。
我们可以看到，去掉对"与生产高度相似"的预生产环境的依赖，确实能节省成本并减少维护负担。但在生产环境里做大量测试，怎么保证安全？"右移"依赖于新的工具与生产发布实践。借助先进的流量管理、可观测性工具以及容器化，许多组织发现这些测试其实可以在生产环境中以极小副作用完成。除了显著降低基础设施开销，这种做法还有一个优势：结果更贴近真实。我们将在第 7 章讨论这些新工具与生产发布实践。
"挖空中间层"优化了测试流程，是当下组织加速交付的一种现代策略。通过重新设计软件在环境之间的流转方式，我们也能同样提升交付效率。接下来在"在环境之间进行晋级（Promotion Between Environments）"中，我们将看看为什么以及如何在环境之间"晋级"发布版本。
在环境之间进行晋级（Promotion Between Environments）
在上一节里，我们看到了一个典型的交付流程：软件需要依次经过多轮测试，每一轮测试都在单独的预生产环境中进行。在这个过程中，我们希望尽可能快速且"聪明"地晋级发布版本------也就是让新版本在没有不必要等待的情况下，进入下一环境与下一阶段。
AI 正在这一晋级过程中扮演越来越重要的角色：它会分析测试结果、性能数据与历史发布记录，智能决定何时、以何种方式晋级。此类系统能够同时评估多项指标，捕捉暗示风险的细微模式，并通过机器学习不断提升判定准确性。
理想情况下，我们的晋级过程很简单：只要某一阶段的测试通过，发布就立刻被晋级到下一个环境，而该环境随时就绪、可供下一轮测试使用。晋级决策是自动且即时的，仅基于上一阶段是否通过测试。现实中，即使只是测试环境之间的晋级，也常成为许多流程的瓶颈。常见原因包括：
- 由委员会决策
晋级决策未自动化，需要集体评审与批准测试结果。 - 晋级依赖繁琐的手工步骤
需要人工介入去触发下一次部署，从而形成卡点。 - 测试环境数量不足
如果下一个环境正忙着测试另一个版本，新版本只能排队等待。
本节将给出相应的缓解措施。这些实践既适用于在预生产环境之间移动发布，也适用于晋级到生产。不过最终进入生产还有一些特殊考量，我们会在第 7 章展开。
从"委员会拍板"到"自动决策"
无论是小组碰头还是由某位权威拍板，只要涉及人工决策，晋级就难免被拖慢------需要通知相关人员、分析测试结果、达成结论并执行操作。虽然不一定费力，但一定费时。
传统自动化往往依据简单的"通过/失败"条件，而 AI 系统可以做更复杂的决策。现代 AI 晋级引擎能同时评估数百项指标，不只看单一测试结果，而是整体分析系统行为。它们可能考虑性能趋势、错误类型、用户影响评估，甚至基于以往发布模式评估本次代码变更的风险等级。通过对这些因素合理加权，AI 能做出比基于规则的系统更细腻的判断。我们的目标就是：把晋级决策自动化。第 7 章将对此做详细讨论。
从"人工触发"到"自动晋级"
一旦把决策自动化，真正执行晋级就容易多了。关键在于：一旦决定继续，立刻触发部署到下一个环境，消除不必要的等待。
如何实现，取决于你选用的持续交付工具。有些工具提供端到端流水线与内置触发器，能在阶段间无缝晋级；另一些允许在当前流水线中调用后续流水线/作业，灵活但需要更多配置。尽管实现难易不同，要达到这种自动化几乎总是可行的。
不过，正如我们在"结合 Git 工作流的 GitOps（Leverage Git Workflows with GitOps）"里提到的，GitOps 式部署在这里会有特殊挑战：要执行部署，我们需要自动化修改 GitOps 配置，而不是手动更新。通常做法是在 CI/CD 流水线内自动创建 PR 并自动化其审批。这样既保留 Git 作为 GitOps 的"单一事实来源"，又把每一步晋级动作自动化。
举个例子：假设流水线判定某个构建已准备好晋级到 UAT（用户验收测试）环境。若流水线能自动生成所需的 PR、触发必须的审批，并在获批后自动合并至主分支，那么流水线就能无缝地触发对 UAT 环境的 GitOps 部署。
打破环境瓶颈
要把阶段与环境间的晋级自动化，最后一个挑战是确定你需要多少个环境。环境太多会因基础设施成本而负担沉重；环境太少又会形成资源争用的瓶颈，拖慢发布向前推进的速度。
短暂（弹性）环境（Ephemeral Environments） 是常见解法：按需创建测试环境，用完即销毁。云之前，创建环境可能要几天；而如今借助可编程的云基础设施，几分钟就能拉起并释放。
基础设施即代码管理（IaCM）工具 让这种短暂环境更易实现。这类专用的 CI/CD 平台负责以代码的方式自动化资源的创建、配置与部署。与专注应用的传统 CI/CD 不同，IaCM 工具侧重管理底层基础设施。你用声明式模板描述期望的基础设施状态，使配置更易管理、维护与版本化。
理想情况下，为了达成"与生产相似"的测试环境，同一份模板应同时用于创建预生产测试环境与生产环境，只通过变量做必要差异化。当流水线与 IaCM 工具无缝集成时，部署到"Test"阶段会自动触发相应"Test"环境的创建。环境一旦就绪，并写入 IP、密码等环境特有变量，便可继续部署与测试。测试完成后，IaCM 工具会高效拆除环境，释放资源。
需要注意的是，创建/销毁环境会在整体测试周期上增加几分钟。因此，若你的目标是"以分钟计"的极高速交付节奏，短暂环境未必最合适。但对于以小时、天或周计的节奏，短暂环境能有效打破瓶颈、提升一致性并优化基础设施成本。
总结
本章我们继续梳理交付流程，聚焦于持续集成之后的持续交付步骤。这些步骤以测试为主，我们回顾了用于验证软件各个方面的重要测试类型。我们还讨论了可依赖、可预测的预生产环境之于测试的重要性，以及实现这一点的最佳实践。通过将测试阶段之间的版本晋级实现全流程自动化（包括晋级决策），我们可以显著加速软件交付。
在完成测试之后，要把最新的软件版本交到用户手中只剩最后一步：实际部署到生产环境。我们将在第 7 章再谈这一环节。在此之前，接下来的几章将讨论如何加固我们的发布，使其更安全、更具韧性、也更可靠。