什么时候 Wavect 是合适之选
- 你想彻底拥有你的软件，而不是向供应商租用它。
- 你日后可能把项目转到内部或交给另一支团队。
- 你把文档、测试和权限当成默认配置来期待。
- 你想要一个从第一天就规划交接的构建者。
当一次构建结束时
软件交接清单：构建结束时你应该拿到什么
交接完成后，你的团队应能用自己掌控的账户运行、修改和恢复软件。应接收代码及历史、文档、测试、可用的部署流水线，以及所需系统的访问权限。签字前，请接手团队亲自部署并恢复一次。
预约三十分钟通话简短回答
让接手团队用已移交的代码、运行手册和自己掌控的账户构建、部署并恢复软件，实际验证交接。
适合
- 正在结束与一家公司或自由职业者合作的创始人
- 要把项目转到内部的团队
- 想避免被供应商绑死的买家
- 任何在为尽职调查或审计做准备的人
- 必须比第一支构建团队活得更久的产品
不适合
- 你从没打算维护的一次性原型
- 你刻意要终身留用同一家供应商的构建
- 没有生产足迹的内部脚本
- 还没达到可交付状态的工作
// 01
比较各个选项
如何分辨一次干净的交接和一个绑死陷阱。
维度
干净的交接
供应商绑死的危险信号
代码所有权
仓库在你的组织里，带完整 git 历史。
代码在供应商账户里，或一个没有历史的压缩包。
凭据
客户控制账户，服务凭据已重新签发或轮换。
密钥和登录信息留在供应商手里。
基础设施
你的组织控制所需的托管、DNS 和监控账户，并已分配运维角色。
供应商是生产环境唯一的管理员。
文档
架构、搭建步骤和运行手册都写了下来。
知识只存在原始开发者的脑子里。
测试与 CI/CD
自动化测试和一条你能自己跑的流水线。
没有测试，或只有供应商能触发部署。
绑死
任何称职的团队都能接手。
只有最初的构建者能改任何东西。
// 02
Wavect 的立场
接手团队应能独立部署和恢复软件。
我们将代码和完整历史交付到你的仓库，同时提供文档、运行手册、测试和部署流水线。约定每个生产账户由谁控制，以及接手团队如何部署、恢复服务和更换供应商。托管服务可能只允许访问自己的租户。请记录这些限制、数据导出方式和变更审批人。
让接手团队主导演练
请一位未参与开发的人在客户组织下重新检出仓库，照运行手册构建、测试并部署到安全环境，确认告警能送达新的值班人员。在隔离环境中恢复备份，核验有代表性的数据记录和一条关键用户流程。记录恢复用时以及这次恢复可能造成的数据丢失量，并与约定的恢复目标比较。AWS Well-Architected 恢复测试指南。
转移仓库也可能带来需要检查的配置。例如，GitHub 转移仓库时会保留关联的 Webhook、密钥和部署密钥。也要检查外部执行器、包仓库和部署身份。在客户账户中重新签发或轮换凭据，验证后撤销已被替换的访问权限。明确续费、账单、许可证和仍需使用的外部服务由谁负责。GitHub 仓库转移文档。
使用数据流水线验收清单，约定指标、对账、迟到数据、安全重放与报表责任。
// 03
成本、风险与周期
成本
构建的一部分约定的交接交付物包含在开发范围内。
风险
跳过就会被绑死漏掉一项，就会让你依赖最初的构建者。
时间
在交付时核验在你签字确认前就跑这份清单，而不是几周之后。
// 04
这里通常会出什么问题
- 收到一个没有 git 历史的代码压缩包，于是你失去了每个决策背后的缘由。
- 发现生产密钥和账户仍归供应商所有。
- 发现供应商是托管、DNS 或数据库唯一的管理员。
- 接手一套没有测试、也没有可运行流水线的代码库。
- 依赖只存在原始开发者脑子里的知识。
- 在没人核验过交接项之前，就宣布构建完成。
// 05
检查清单
在你接受交接之前，确认以下每一项。
边做边勾选。不会保存或发送任何内容。
// 06
在我们的工作中是什么样子
这些案例介绍已上线的产品。你可以通过演练来验收自己的项目交接。
1000+
并发用户
AR-RWA 平台：通过产品募集 200 万美元+、1000+ 并发用户，整整六周。
Solidity
Typescript
React
6周
从零到生产
AI 原生评估平台，在压缩的市场压力下 6 周内从零到生产。
NestJS
Next.js
LangChain
这些是精选项目，并非我们的全部作品。自 2018 年以来我们已交付 100+ 款产品。
// 07
什么时候适用，什么时候不适用
什么时候我们并不合适
- 你想要一个你永远离不开的供应商。
- 你把文档和测试看成可选的额外项。
- 你在做一个没有前途的一次性原型。
- 你不愿接管你自己的凭据和基础设施。
如果离开构建它的人你就跑不起来自己的软件，那你还没拥有它。
// 09
常见问题
在你拥有的仓库里、带完整 git 历史的代码。历史承载着每一次改动背后的推理，而一个没有它的压缩包把这些都丢掉了。其他一切都建立在这之上。
先取得账户控制权并替换系统使用的凭据。人员使用各自的账户，服务凭据保存在客户的密钥管理系统中。确认新凭据可用后，再吊销旧凭据并移除供应商不再需要的权限。
任何意味着只有最初的构建者能改动、部署或运维软件的情况。代码在他们的账户里、没有文档的系统，或他们不肯交出的管理员权限，全都是绑死。
需要。没有一套自动化测试和一条你能自己跑的流水线，未来每一次改动都既有风险又缓慢。正是它们让一支新团队在你接手后能安全前进。
在你为构建签字确认之前，而不是几周之后。趁最初的团队还在合作时跑这份清单，这样任何缺口都能立刻补上。
约定的交接交付物包含在开发范围内。额外的迁移、培训或支持需要另行约定。