Resource Guide
软件项目源码、部署与账号交接清单
摘要：这份清单用于软件定制项目里程碑交付、最终验收、运维接管或更换服务商时，逐项核对源码、版本、构建环境、数据库、配置、部署、账号、第三方服务、备份回滚和交接证据。重点不是确认文件“已经发过”，而是验证接收方能够在受控环境中复现并继续维护。
这份清单什么时候使用
建议从项目启动阶段就建立交付目录，在每个里程碑更新，而不是等验收前临时收集。需要更换服务商、迁移服务器、调整运维责任或准备审计时，也可以用同一张表盘点当前掌握程度。合同、知识产权、保密和数据责任仍需由相关专业人员结合项目约定审核。
源码交接不等于发送一个压缩包
可维护的源码交付应能说明代码仓库、默认分支、版本标签、提交历史、依赖锁定、构建命令、数据库迁移、配置模板和发布制品之间的关系。前端、后端、定时任务、脚本、移动端或三维工程如果分散在不同仓库，也应分别列出，不能只交付当前页面能运行的一部分。
账号和密钥要分开处理
表格只记录账号用途、所属平台、权限级别、交接方式和责任人，不应直接写入密码、令牌、证书私钥或生产密钥。敏感凭据应通过双方确认的受控渠道移交，并在接收后完成权限核对、必要的密钥轮换和旧账号回收。
建议按什么顺序交接
- 冻结并标记当前可运行版本，记录交接基线和已知问题。
- 移交代码仓库、分支标签、构建工具、运行时和依赖说明。
- 核对数据库结构、迁移脚本、文件存储、配置模板与备份。
- 按服务器、域名证书、云服务和第三方平台逐项移交账号权限。
- 由接收方在约定环境重新构建、部署并执行核心流程回归。
- 记录未关闭问题、临时方案、后续责任和最终验收证据。
哪些字段必须一起核对
| 字段组 | 核对重点 | 完成标准 |
|---|---|---|
| 代码与版本 | 仓库、分支、标签、提交历史、制品对应关系 | 指定接收账号可访问并定位当前生产版本 |
| 构建与依赖 | 运行时、锁文件、构建命令、私有依赖和镜像 | 干净环境可以按说明完成构建 |
| 数据与配置 | 数据库迁移、初始化、文件存储、配置模板和密钥边界 | 能恢复测试环境且敏感值未写入普通文档 |
| 部署与回滚 | 服务器、发布步骤、健康检查、备份、回滚和验证 | 完整执行一次部署与约定的恢复验证 |
| 账号与第三方 | 域名、证书、云服务、短信地图、许可、费用和续费责任 | 权限归属、到期时间和后续责任可追溯 |
必须做一次可复现验证
接收方应使用交付资料完成代码拉取、依赖安装、配置、建库或迁移、构建、部署、健康检查和核心流程测试。测试过程要记录环境、命令、输入数据、结果和问题。只验证压缩包能打开或服务器当前能访问，不能证明项目已经具备持续维护条件。
未完成项不能用“后续补”代替
暂时无法交付的项目应标记状态、缺失原因、影响、责任人、计划完成时间和临时措施。涉及商业组件、云资源、外部账号或客户侧系统时，要区分“无权交付”“尚未授权”“等待对方提供”和“可替代”，避免把责任不清的内容统一写成待办。
参考依据与适用边界
Git 官方文档中的 git bundle 可用于离线转移 Git 对象和引用，但仓库之外的配置、数据库、文件、密钥和第三方账号仍需单独交接。系统与软件质量考虑可参考国家标准全文公开系统中的 GB/T 25000.10-2016。本清单是技术交接工具，不替代合同、知识产权、保密、数据合规或财务审查。
常见问题
源码给一个压缩包是否足够？
通常不够。还要核对版本历史、依赖、数据库、配置、构建部署、账号权限、第三方服务和可复现运行结果。
账号密码可以直接填写在 CSV 中吗？
不应这样做。表格只记录账号用途、权限和交接方式，密码、令牌和私钥应通过受控渠道移交并按需要轮换。
服务器当前能访问是否代表部署交接完成？
不代表。还应由接收方按文档完成一次部署、健康检查和核心流程回归，并验证备份或回滚路径。
这份清单可以直接作为合同附件吗？
可以作为技术范围讨论基础，但正式合同中的知识产权、保密、责任和费用条款应由专业人员结合项目审核。
下载与相关资料
继续阅读 软件项目变更与源码交接怎么约定、使用 软件服务商交付能力对比清单 和 上线运维、备份与恢复清单。网站内容责任与审核边界见 公司与网站信息。