一句话总结

把自己从发布流程的关键路径中摘出来

亮点

• 我们完成了 TinyPilot 有史以来第一次由我完全不直接参与任何发布任务的版本发布。
• 通过授权他人来发布版本，帮助我们发现了发布流程中许多未形成文档或设计不佳的环节。
• 我依然乐在其中地用 Zig 编写字节码解释器。

目标完成情况

每月初，我都会定下当月想要完成的目标。以下是本月的完成情况：

发布 TinyPilot Pro 2.6.3

• 结果：已发布该版本。
• 评分：A

我们想找出那些被意外集中在我一人身上的发布环节，因此这是第一次我没有直接执行任何发布步骤。团队完全依据共享文档完成了所有流程，包括撰写更新日志和发布公告等。

在内部完善 TinyPilot Pro 发布流程的文档

• 结果：已完成足以支撑本次发布的文档，但仍有待改进之处。
• 评分：B+

梳理发布流程是一次很有价值的练习。它不仅暴露了未形成文档的环节，也暴露了流程本身的薄弱之处。

我们的发布流程中有许多环节此前从未被认真审视过。当我坐下来逐一整理时，发现有不少步骤要么过于繁琐费力，要么容易出错，要么完全是在重复造轮子。

完成 2023 年报税

• 结果：已收集大部分材料，但尚未提交申报。
• 评分：B

结果被 TinyPilot 的版本发布岔开了精力，所以还没来得及申报。不过，我想政府大概还是希望我在今年内的某个时候完成申报，所以我最好尽快去办。

TinyPilot 数据

由于我的年度回顾带来了不少关注，访客量出现了大幅增长，但似乎对 TinyPilot 的销量影响不大。销售额下降了 17%，主要是因为 1 月份本来就是异常强劲的一个月。我们通常的月销售额在 7.5 万至 9.5 万美元之间。

我需要一种新的月度利润统计方式，因为改用合约制造商后，按单月计算的现金利润数据已经基本失去意义。每个月的利润很大程度上取决于我每三到四个月支付一次的制造成本账单的入账时间。

不过，我们近三个月的平均利润已回到了我比较满意的 1 万至 2 万美元区间。

原来我们的发布流程有 25 步

最初，TinyPilot 的软件发布完全由我一人负责。随着产品逐渐成熟，流程中的步骤也越来越多，每次发布需要投入 10 到 20 小时的工作量。

大约 18 个月前，我把最繁重的发布任务交给了团队成员，其中主要包括大部分手工测试。这让我的投入时间缩短到每次发布 3 到 5 小时，当时我觉得自己授权做得已经不错了。

在上一次 TinyPilot 发布中，我给自己提出了一个挑战：把所有事情都授权出去。我想确保即便在我无法参与时，发布也能照常推进。

我开始为自己仍在负责的任务编写操作说明，原以为只需要记录寥寥几步。

当我把每次发布仍由我亲自完成的事项全部列出来时，才意识到每次发布竟然包含 25 项不同的任务：

测试候选版本

1. 创建候选版本构建
2. 起草更新日志
3. 起草安全公告（如适用）
4. 起草发布公告
5. 更新测试计划以覆盖功能变更
6. 在 Voyager 设备上测试候选版本
7. 测试从已发布版本升级到候选版本
8. 在 DIY 设备上测试候选版本
9. 针对实体设备运行自动化端到端测试
10. 审核测试结果
11. 决定是否发布该版本

发布版本

1. 发布安全公告（如适用）
2. 发布更新日志
3. 发布 TinyPilot Pro 正式版
4. 验证升级到最新版本是否正常
5. 向 TinyPilot 团队内部通告发布
6. 在更新日志中补充镜像哈希值
7. 至少 48 小时内持续关注 Bug 反馈

对外宣布

1. 发布 TinyPilot Community 版本
2. 发布版本公告博文
3. 将发布信息同步给欧盟分销商
4. 将发布信息同步给制造商
5. 更新内部操作手册中的链接
6. 向公开邮件列表发送发布公告
7. 在 TinyPilot 的 Twitter 上分享博文

此前我只文档化并授权了三项任务——也就是那些需要手工测试的部分，但其余 22 项仍由我亲自完成。

看着这份清单，单是一次发布就要走 25 步，听起来就很多。而实际上远不止 25 步，因为其中不少任务内部还包含几十个子步骤。

面对这么多手工步骤，直觉上会觉得应该多做自动化，但我看不到什么明显的自动化切入点。我们当然可以把“在更新日志中添加镜像哈希”或“更新内部手册链接”这类步骤自动化，但可能要花 10 小时去做自动化，一年却只能省下 2 小时的人工。

对我而言，更重要的启示是：要谨慎地为发布流程增加任务，并不断质疑现有每个环节是否真的必要。

如何在发布前发现 Bug？

事实证明，发布任务的授权比一般的授权要困难得多，因为我意识到，即便我能解释自己是如何做决策的，团队成员仍缺乏做出这些决策所需的背景信息。

举个例子，分享一下我们在最终测试阶段遇到的一个 Bug。

通常情况下，把设备接入网络后，它会接受路由器分配的任意局域网 IP 地址。一些 TinyPilot 用户希望设备能主动请求一个固定、可预期的 IP 地址。在上一个版本中，我们在 TinyPilot 的网页界面中新增了设置静态 IP 的功能。

以下是该功能在发布前测试时的表现：

客服团队执行了测试，并报告没有发现问题。页面如测试计划预期的那样在新 IP 地址上正常加载。技术支持团队复核了测试视频，也认为功能运行正常。

我复看视频时却发现了一个严重问题。在网页界面于新地址加载出来之前的几秒钟内，用户会看到这样一个令人不安的错误页面：

当我把这个问题展示给开发团队时，他们很是沮丧。

我们已经为这个引导用户从动态 IP 切换到静态 IP 的界面投入了数周的开发时间。由于涉及 DNS 缓存、本地 TLS 证书以及浏览器对跨域请求的安全限制，实现起来格外复杂。经过大量测试和编排代码，开发团队本以为已经做得很完善了，结果在 TinyPilot 办公室的实测中却并未顺畅运行。

那么，在不需要我事无巨细地介入的情况下，我们该如何捕捉这类 Bug？又该如何避免不同团队对功能预期不一致而产生的脱节？

我们决定调整流程：当开发团队发布新功能或修改原有行为时，由他们来复核发布前的测试录像，以确认实际表现符合他们的预期。

如何决定修复哪些 Bug？

授权发布流程的下一个挑战，是明确发布负责人在发布前测试中发现 Bug 后该如何处理。是推迟发布？还是带着 Bug 照常发布？

当发布由我一人统筹时，“发布还是修复”的决策要容易得多，因为我掌握着跨团队的背景信息。我与开发团队保持密切沟通，所以清楚修复一个 Bug 需要多久、又有多大风险会引入新的问题。同时作为产品负责人，我也了解这个 Bug 对用户的影响程度。如果某项功能足够重要，且修复成本相对可控，我就会选择推迟发布以修复 Bug。

如果发布负责人不是我，他们又该如何判断何时应该为修复 Bug 而推迟发布？

我们的新策略是：发布负责人不直接做决定，而是从其他团队收集所有相关信息，再交由产品负责人来定夺。这样，我们把“为决策收集信息”的过程与“做出决策”本身分离开来。这也有助于实现我们的目标——尽量减少只有我才能完成的发布任务。

业余项目

我写出了世界上最快（但未完成）的以太坊实现

我上个月提到，我找到了一种有趣的方式来深入学习 Zig、解释器和以太坊——用 Zig 编写一个以太坊字节码解释器。

Zig 让开发者对性能有很高的掌控力，因此我在开发解释器早期就着手在持续集成中搭建基准测试，将我的实现与官方 Go 版本进行对比。

有一段时间，我的 Zig 版本性能略逊于 Go 版本。随后，我重构了基准测试脚本，性能却莫名地大幅下滑。

我在 Zig 论坛 Ziggit 上发帖求助后发现，我的基准测试脚本和 Zig 代码中都存在 Bug。一旦我修复了这两个小 Bug，我的 Zig 版本性能一下子就超过了 Go 版本。

现在，我的 Zig 版以太坊实现比官方 Go 实现快了 30% 到 40%。

公平地说，我的版本只实现了以太坊约 3% 的功能，所以这个优势并不完全公平，但这仍然是一个很有趣的项目。

总结

完成了哪些工作？

• 发布了 TinyPilot Pro 2.6.3。
• 找出了 TinyPilot 发布流程中未形成文档的环节，并完成了大部分文档化工作。

经验教训

• 当工作需要跨团队协作时，任务授权会变得更加困难。
  • 有些决策最终仍需由产品负责人来做，但团队可以调整流程，将“为决策收集信息”与“做出决策”拆分为两个独立环节。

下月目标

• 补齐 TinyPilot 发布文档中的缺口。
• 完成 2023 年的报税。