源码交付是不是给一个压缩包就够了？
通常不够。还应核验版本历史、依赖锁定、数据库脚本、配置、构建部署、账号权限和可复现运行结果。
Software Delivery
软件项目变更与源码交接怎么约定
摘要：软件项目容易在“已经确认”和“顺便调整”之间失去边界，也容易把源码交付理解成最后发一个压缩包。更稳妥的做法是建立需求基线、变更记录和版本对应关系，并在每个里程碑持续核验源码、数据、配置、账号、文档和可部署性。
先建立可引用的需求基线
基线至少包含业务目标、用户角色、关键流程、页面与功能、数据接口、权限、部署环境、交付物和验收条件，并记录版本号、确认日期和确认人。后续讨论不能只说“按之前说的”，而应指出修改了哪个版本中的哪一项。
变更单需要回答五个问题
- 为什么变：业务、数据、合规、技术限制还是使用反馈？
- 变什么：页面、流程、字段、接口、权限、部署或验收条件？
- 影响什么：费用、周期、测试范围、历史数据、兼容和运维？
- 谁确认：提出人、业务负责人、技术负责人和项目负责人？
- 进入哪个版本：本期、下期、试点还是暂不实施？
缺陷修复、已确认范围内的实现调整和新增需求应采用项目约定的定义，不要仅按提出方的主观叫法判断。
源码交接应覆盖哪些内容
| 类别 | 应核验内容 | 验收方式 |
|---|---|---|
| 代码仓库 | 前后端、脚本、分支、标签、提交历史和访问权限 | 指定账号可拉取完整历史 |
| 依赖与构建 | 依赖清单、锁文件、运行时版本、构建命令 | 在干净环境完成构建 |
| 数据库与文件 | 结构、迁移脚本、初始化、备份和上传文件说明 | 恢复测试环境并核对版本 |
| 配置与密钥 | 环境变量说明、配置模板、证书和密钥移交方式 | 敏感值通过受控渠道交接 |
| 第三方组件 | 开源、商业组件、云服务、地图、短信和授权边界 | 核对账号、费用、许可和续费责任 |
| 文档 | 需求、原型、接口、部署、运维、测试和已知问题 | 按目录逐项打开并验证 |
交付源码后必须做一次复现
由接收方或双方共同使用交付资料，在约定环境完成拉取、安装依赖、配置、建库、构建、部署和核心流程测试。只有压缩包能打开，不代表系统能够持续维护。Git官方文档说明 git bundle可用于离线转移Git对象和引用，但仓库之外的环境配置、密钥、文件和第三方账号仍需单独交接。
依赖与第三方边界要单独列出
至少记录组件名称、版本、用途、来源、许可或商业授权、是否修改、已知替代方案和升级责任。需要机器可读的软件物料清单时，可参考 SPDX开放标准；是否采用及采用到什么深度，应结合企业安全和合规流程。
项目中途移交的顺序
先冻结并标记当前可运行版本，再备份数据库和文件，导出待办、缺陷、风险与变更记录；随后移交仓库、服务器、域名、证书、云服务、第三方账号和联系人；最后由接收方在新环境复现并完成核心业务回归。生产密钥不应直接写进源码或普通文档。
常见问题
什么情况应走项目变更？
已确认的范围、流程、接口、部署或验收条件变化，并影响工作量、周期或风险时，应形成可追踪记录。
项目中途换服务商，先接什么？
先冻结可运行版本，接收仓库与权限、环境清单、数据库和文件备份、已知问题、第三方账号及待办范围。
合同条款可以直接套用清单吗？
清单可用于业务和技术核验；知识产权、保密、数据和责任条款应由企业法务或专业人员审核。