4. 部署基础
测试平台从代码仓库走到可用服务，中间要经过一整套可重复、可审计的部署过程。部署基础决定了平台能否稳定交付、快速恢复和持续演进。本节围绕五个关键概念展开：部署模式、环境划分、发布策略、回滚机制与部署流水线，它们共同构成测试平台交付的骨架。
一、部署模式：平台以什么形态运行
测试平台常见的部署模式有三种：物理机/虚拟机部署、容器化部署、以及混合部署。物理机或虚拟机部署把应用直接安装在操作系统上，依赖由运维手工维护，适合早期工具或强依赖特定硬件的场景；容器化部署把应用及其依赖打包成镜像，通过 Docker、Kubernetes 等编排运行，环境一致性和弹性更好；混合部署则把核心服务容器化，把需要独占资源或特殊驱动的组件保留在虚拟机上。
选择部署模式时，重点看三个因素：依赖复杂度、扩缩容需求和团队运维能力。测试平台通常包含 Web 前端、API 服务、任务调度、执行机、数据库和缓存，容器化能显著降低环境差异带来的问题，但执行机若需要访问特定设备或内网资源，则要单独规划。
二、环境划分：从开发到生产的隔离与递进
环境划分的核心目的是隔离风险、逐级验证。典型划分包括开发环境、测试环境、预发布环境和生产环境。开发环境供研发自测，允许频繁变更；测试环境供测试团队验证功能与接口；预发布环境尽量贴近生产配置，用于发布前最终验证；生产环境承载真实用户和真实数据。
环境之间应保持配置隔离、数据隔离和访问隔离。配置隔离通过环境变量或配置中心实现，避免把生产数据库地址写进测试配置；数据隔离要求测试环境使用脱敏数据或独立数据集；访问隔离则通过权限控制限制生产环境的操作入口。
| 环境 | 主要用途 | 数据特征 | 变更频率 |
|---|---|---|---|
| 开发环境 | 研发自测、联调 | 模拟数据、可重置 | 高 |
| 测试环境 | 功能、接口、回归验证 | 脱敏数据、独立库 | 中高 |
| 预发布环境 | 发布前验收、性能抽检 | 接近生产、只读为主 | 低 |
| 生产环境 | 真实用户使用 | 真实数据、严格审计 | 低且受控 |
三、发布策略：如何把新版本交给用户
发布策略决定新版本以什么节奏、什么范围暴露给使用者。常见策略包括停机发布、滚动发布、蓝绿发布、灰度发布和金丝雀发布。停机发布最简单，但会造成服务中断；滚动发布逐批替换实例，适合无状态服务；蓝绿发布准备两套完整环境，切换流量后快速回退；灰度发布按用户、流量或地域逐步放量；金丝雀发布先让少量真实流量进入新版本，观察指标后再扩大。
测试平台自身也可能被多个团队使用，发布策略要结合影响面选择。若平台只服务内部少量用户，滚动发布加快速回滚通常足够；若平台承载关键质量门禁，建议采用蓝绿或灰度，先验证核心链路再全量。
# 以 Kubernetes 滚动发布为例
kubectl set image deployment/test-platform-api \
api=registry.example.com/test-platform-api:v2.3.1
kubectl rollout status deployment/test-platform-api
kubectl rollout history deployment/test-platform-api四、回滚机制：出问题时如何快速恢复
回滚机制是部署安全的底线。回滚不只是“把旧镜像换回来”，还要考虑数据库变更、配置变更和缓存状态。若新版本包含不兼容的数据库结构变更，简单回滚应用可能造成数据错乱。因此，回滚设计要遵循“向前兼容”原则：数据库变更尽量采用扩展-迁移-收缩三步法，先加字段、双写、再切换、最后清理。
回滚触发条件应提前定义，例如接口错误率超过阈值、核心任务成功率下降、响应时间明显劣化。回滚操作要尽量自动化，并保留版本记录和操作日志。对于测试平台，回滚后还要确认任务调度、执行机注册、报告生成等关键链路恢复正常。
五、部署流水线：把上述环节串成自动流程
部署流水线把代码提交、构建、测试、镜像打包、环境部署、验证和回滚串联起来。典型阶段包括：代码检出与静态检查、单元测试与接口测试、构建镜像并推送仓库、部署到测试环境、自动化验收、部署到预发布、人工审批、部署到生产、健康检查与指标观察。
流水线的价值在于把部署模式、环境划分、发布策略和回滚机制固化为可重复执行的步骤。它让每次发布都有记录、有验证、有退路。对于测试平台，流水线还应包含平台自身的冒烟用例，例如创建任务、触发执行、查看报告，确保部署后核心功能可用。
六、案例与常见误区
某测试平台早期采用手工部署，每次发布需要登录服务器替换 jar 包并重启服务，环境配置靠文档记录。一次数据库字段变更后，测试环境正常，生产环境因漏执行 SQL 导致任务创建失败，回滚时又发现旧版本不兼容新表结构，恢复耗时超过两小时。复盘后，团队引入容器化部署和流水线，把数据库变更纳入版本管理，并规定生产发布必须经过预发布验证和灰度观察。
常见误区包括：把环境划分当成“多搭几套机器”，却忽略配置和数据隔离；只关注发布成功，不设计回滚触发条件；流水线只做构建不做验证；灰度发布没有指标观察，变成“小范围全量”。这些问题的共同点是：把部署当成一次性动作，而不是可重复、可验证、可恢复的工程过程。
在实际落地时，建议先从环境划分和流水线入手，把构建、测试、部署、验证串起来；再根据平台重要程度选择发布策略；最后把回滚预案写成可执行的脚本或流水线步骤。这样，测试平台的每次发布都有据可查、有路可退，维护成本也会随着自动化程度提高而下降。