一句话总结

让自己不再处于发布流程的关键路径上

亮点

• 我们完成了有史以来第一次我没有直接执行任何发布任务的 TinyPilot 版本发布。
• 通过授权他人来发布版本，帮助我们发现了发布流程中许多未记录或设计不佳的步骤。
• 我仍在乐此不疲地用 Zig 编写 bytecode interpreter(字节码解释器)。

目标评分

每个月初，我都会宣布本月想要完成的目标。以下是这些目标的完成情况：

发布 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 个月后，我把最艰巨的发布任务委托给了同事。这包括大部分的手动测试。这让我的工作时间缩短到每次发布三到五个小时，我觉得自己在授权方面做得不错。

在上一次 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 小时内监控缺陷报告

公布版本

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

我之前只记录并委托了三项任务：那些需要手动测试的任务。但其余 22 项仍由我来做。

看这份清单，光是发布就要 25 步，听起来就很多。而实际上，远不止 25 步，因为某些任务中还包含几十个子步骤。

当有这么多手动步骤时，感觉答案应该是进一步自动化，但我看不到明显的自动化候选。我们可以把像向更新日志添加镜像哈希或更新内部手册中的链接这类步骤自动化，但可能要花大约 10 小时的自动化工作，才能每年节省两小时的手动时间。

对我来说更重要的收获是，要谨慎对待向发布流程中增加任务，并对现有任务的必要性提出质疑。

如何捕捉发布前的缺陷？

委托发布任务比一般的授权更难，因为我意识到，即使我能解释自己是如何做决策的，同事们仍然缺乏做出这些决策所需的背景信息。

举个例子，分享一下我们在最终测试中遇到的一个缺陷。

通常，当你把设备接入网络时，它会接受路由器分配的任意本地 IP 地址。一些 TinyPilot 用户希望设备能申请一个固定的、可预测的 IP 地址。在上一个版本中，我们在 TinyPilot 的网页界面中增加了分配静态 IP 地址的支持。

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

客服团队执行了测试，并报告没有问题。页面按测试计划预期在新的 IP 地址上加载。支持工程团队审阅了测试视频，也报告该功能运行正常。

我审阅了视频，发现了一个重大问题。在网页界面于新地址加载之前的短暂几秒内，用户会看到这个令人不安的错误页面：

当我展示给开发团队时，他们很受打击。

我们已投入数周的开发时间来打造引导用户从动态 IP 切换到静态 IP 的界面。由于涉及 DNS 缓存、本地 TLS 证书以及浏览器对跨域请求的安全保护等复杂性，这项工作尤其具有挑战性。经过大量测试和编排代码，开发团队以为终于做对了，结果发现在 TinyPilot 办公室里并不能顺畅运行。

那么，在不由我事事紧盯的情况下，我们如何捕捉这类缺陷？如何避免不同团队对功能预期的脱节？

我们决定调整流程：当开发团队发布新功能或修改旧有行为时，由他们来审阅我们的发布前测试录像，以确保其运行符合预期。

如何决定修复哪些缺陷？

委托发布流程的下一个挑战是弄清楚发布经理在发布前测试中发现缺陷后该怎么做。是推迟发布？还是带着缺陷按原样发布？

当发布集中由我负责时，发布还是修复的决策更容易一些，因为我对各团队的情况都有了解。我与开发团队保持同步，所以我知道修复缺陷需要多长时间，以及在此过程中破坏其他功能的风险有多大。我也是产品负责人，所以我了解缺陷对客户的影响程度。如果某个功能足够重要，相对于修复缺陷的成本而言，我就会推迟发布以修复缺陷。

如果发布经理不是我，他们该如何决定何时为了修复缺陷而推迟发布？

我们的新策略是，发布经理不做决定，而是从其他团队收集所有信息，交由产品负责人来定夺。这样，我们就把为决策收集输入的过程与决策本身分离开来。这符合我们尽量减少只有我才能做的发布任务的目标。

业余项目

我写出了世界上最快（但尚未完成）的 Ethereum 实现

我上个月提到过，我找到了一种有趣的方式来深入学习 Zig、解释器和 Ethereum——我正在用 Zig 编写一个 Ethereum bytecode interpreter。

Zig 让开发者对性能有高度的控制，因此我在解释器上最早的任务之一就是在持续集成中设置基准测试，将我的实现与官方的 Go 实现进行对比。

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

我在 Zig 论坛 Ziggit 上求助，结果发现我的基准测试脚本和 Zig 代码中都有缺陷。一旦我修复了这两个简单的缺陷，我的 Zig 版本便一举超越了 Go 版本。

我的 Zig 版 Ethereum 实现现在比官方 Go 实现快 30-40%。

公平地说，我的版本只实现了约 3% 的 Ethereum 功能，所以我占了不小的优势，但这仍然是一个有趣的项目。

总结

完成了什么？

• 发布了 TinyPilot Pro 2.6.3。
• 识别出 TinyPilot 发布流程中未记录的步骤，并对其中大部分进行了记录。

经验教训

• 当工作需要跨团队协作时，任务的委托会变得更加困难。
  • 有些决策最终需要由产品负责人来做，但团队可以调整流程，将为决策收集相关信息的过程与做出决策的过程分开。

下月目标

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