1. 验收与交付总览

GitLab 研发平台的验收与交付，不是“装完软件、点一遍页面”这么简单。它本质上是一次围绕可交付能力展开的系统性确认：平台是否按设计目标建成、关键研发链路是否真正跑通、安全与权限边界是否可控、运维与备份是否具备接管条件，以及最终能否把平台连同文档、配置、账号、数据和责任一起移交给使用方与运维方。理解这一点，才能避免把验收做成“功能演示”，把交付做成“文件拷贝”。

一、定义：验收与交付分别确认什么

验收回答的是“建得对不对、够不够用”。它以需求与设计为基准，通过检查、测试和证据比对，确认 GitLab 平台的功能、性能、安全、可用性和集成能力达到约定标准。交付回答的是“能不能接得住、用得起”。它把平台资产、配置、文档、权限、运维流程和责任边界完整转移给接收方，使对方在不依赖原建设团队的情况下可以独立运行、维护和扩展。

两者关系紧密但不等同：验收偏“确认符合性”，交付偏“转移可运营性”。一个常见误区是验收通过就认为交付完成，结果运维方拿到平台却不知道备份策略、不知道 Runner 注册令牌放在哪里、不知道升级窗口如何安排。因此本课程始终把两者放在同一条链路上看待。

二、目标：四个可判定的结果

• 功能可用：代码托管、合并请求、CI/CD、制品库、议题与看板等核心能力按预期工作。
• 链路贯通：从代码提交到流水线执行、再到制品产出与部署的端到端路径可复现。
• 安全可控：认证、授权、审计、密钥与令牌管理符合安全基线，越权路径被关闭。
• 可运维可接管：监控、日志、备份恢复、升级与容量扩展有明确责任人和操作依据。

三、范围：验收与交付覆盖哪些对象

范围界定不清是验收争议的主要来源。建议从五个维度圈定边界：平台组件（GitLab 应用、数据库、对象存储、Redis、Gitaly、Runner、容器镜像仓库等）、集成接口（LDAP/SSO、邮件、Jira、制品仓库、Kubernetes 集群等）、研发流程（分支策略、MR 评审、流水线阶段、环境与发布方式）、非功能指标（并发、响应时间、可用性、备份 RPO/RTO）、交付物（架构文档、部署清单、配置基线、账号清单、测试报告、运维手册、培训记录）。

四、关键角色与职责

五、整体流程：从基线到移交

端到端流程可以概括为：需求与验收标准基线 → 环境与配置核查 → 功能与链路测试 → 安全与权限验证 → 非功能与故障演练 → 问题整改与复验 → 交付物整理 → 移交与培训 → 签字确认与质保。其中“验收标准基线”必须在建设早期冻结，否则后期测试无据可依；“问题整改与复验”是闭环关键，未关闭的高风险问题不应进入正式移交。

六、一个可参考的验收判定示例

以“代码提交到制品产出”这条核心链路为例，验收时不应只看页面能否打开，而应设计可复现的判定用例。假设试点项目为 payment-service，验收环境为预生产环境，判定标准可写成：

用例编号：AC-CICD-001
前置条件：项目已创建，Runner 在线，镜像仓库可写
操作步骤：
  1. 向 main 分支推送一次提交，提交信息含 [verify]
  2. 观察流水线是否自动触发，阶段为 build → test → package
  3. 检查制品库是否生成 payment-service:<commit-sha> 镜像
  4. 检查流水线日志中单元测试通过率与退出码
判定标准：
  - 流水线在 5 分钟内完成，状态为 passed
  - 镜像 tag 与提交 SHA 一致，可被部署环境拉取
  - 测试退出码为 0，无跳过关键用例
证据留存：流水线页面截图、镜像列表截图、Runner 日志片段

这样的用例把“功能可用”转化为可观察、可留证、可复验的结论。验收报告中的每一条“通过”，都应能追溯到类似的具体用例和证据，而不是一句主观评价。

七、常见误区与规避建议

• 只验功能不验运维：上线后才发现备份未配置、监控无告警。建议在验收阶段就执行一次恢复演练。
• 验收标准后置：建设完成才讨论“怎样算通过”，容易产生争议。标准应与需求同步冻结。
• 交付物缺失或过期：文档版本与现场配置不一致。建议交付前做一次配置与文档一致性核对。
• 权限移交不清：管理员账号仍留在建设方手中。移交时应完成账号归属变更与最小权限收敛。