一句話總結

讓發版流程不再非我不可

本月亮點

• 我們完成了有史以來第一次、我完全沒有親自執行任何發版任務的 TinyPilot 版本發布。
• 透過授權他人來發布版本，讓我們發現了發版流程中許多未被記錄或設計不佳的步驟。
• 我依然很享受用 Zig 撰寫 bytecode 直譯器的過程。

目標達成度

每個月月初，我都會宣告當月想完成的目標。以下是這個月的達成狀況：

發布 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. 撰寫 changelog
3. 撰寫安全性公告（若適用）
4. 撰寫版本發布公告
5. 更新測試計畫以涵蓋功能異動
6. 在 Voyager 裝置上測試候選版本
7. 測試從已發布版本更新至候選版本
8. 在 DIY 裝置上測試候選版本
9. 對實體裝置執行自動化端對端測試
10. 檢視測試結果
11. 決定是否正式發布

發布版本

1. 發布安全性公告（若適用）
2. 發布 changelog
3. 發布 TinyPilot Pro 正式版本
4. 驗證更新至最新版是否順利完成
5. 向 TinyPilot 團隊內部公告發版
6. 在 changelog 中加入映像檔雜湊值
7. 至少 48 小時內持續監控錯誤回報

對外公告

1. 發布 TinyPilot Community 版本
2. 發布版本公告部落格文章
3. 將版本資訊分享給歐盟經銷商
4. 將版本資訊分享給製造商
5. 更新內部操作手冊中的連結
6. 向公開郵件名單發送版本公告
7. 在 TinyPilot 的 Twitter 上分享部落格文章

我之前只記錄並授權了三項任務：那些需要手動測試的工作。但剩下的 22 項仍是我自己在做。

看著這份清單，光是發一個版就要 25 個步驟，聽起來就很多。而實際上遠不止 25 步，因為其中某些任務底下還有數十個子步驟。

面對這麼多手動步驟，直覺會想透過更多自動化來解決，但我看不到什麼明顯適合自動化的環節。我們當然可以把「在 changelog 中加入映像檔雜湊值」或「更新內部操作手冊連結」這類步驟自動化，但可能得花 10 小時去做自動化，一年卻只省下兩個小時的人工。

對我來說，更重要的啟示是：要對新增發版任務保持謹慎，並重新檢視現有步驟是否真的必要。

我們該如何揪出發版前的錯誤？

結果發現，授權發版任務比一般的授權更困難，因為我意識到，即使我能說明自己是怎麼做決策的，團隊成員仍缺乏做出那些決策所需的背景脈絡。

舉個我們在最終測試時遇到的錯誤為例。

通常把裝置接上網路時，它會接受路由器分配的區域網路 IP 位址。有些 TinyPilot 使用者希望裝置能要求一個固定、可預期的 IP 位址。在這次的版本中，我們在 TinyPilot 的網頁介面中新增了設定靜態 IP 位址的功能。

以下是這個功能在發版前測試時的樣子：

客服團隊執行了這項測試，回報沒有問題。頁面如測試計畫預期在新的 IP 位址上載入。支援工程團隊檢視了測試影片，也回報功能運作正常。

我看了影片後發現一個大問題。在網頁介面於新位址載入前的幾秒鐘，使用者會短暫看到這個嚇人的錯誤畫面：

當我把這個情況拿給開發團隊看時，他們相當沮喪。

我們已經投入了數週的開發時間在引導使用者從動態 IP 切換到靜態 IP 的介面上。這件事特別棘手，牽涉到 DNS 快取、本地 TLS 憑證，以及瀏覽器對跨網域請求的安全防護等複雜問題。經過大量測試與協調程式碼的撰寫，開發團隊以為終於搞定了，結果在 TinyPilot 辦公室的實際測試中卻沒有順暢運作。

那麼，要怎麼在不需要我鉅細靡遺地緊盯流程的情況下，揪出這類錯誤？又該如何避免不同團隊對功能預期落差所造成的脫節？

我們決定調整流程：當開發團隊推出新功能或變更既有行為時，要由他們親自檢視發版前的測試影片，確認實際運作符合他們的預期。

我們該如何決定要修哪些錯誤？

在授權發版流程時，下一個挑戰是：當發版負責人在發版前測試中發現錯誤時，該怎麼處理？要延後發版嗎？還是就這樣帶著錯誤發版？

當發版集中由我負責時，要發版還是要修錯誤的決策比較容易，因為我掌握跨團隊的脈絡。我與開發團隊保持密切聯繫，所以知道修復錯誤要花多久、過程中又有多大風險會弄壞其他東西。同時我也是產品負責人，所以清楚這個錯誤對客戶的影響有多大。如果某個功能夠重要，相對於修復成本來說值得等待，我就會延後發版來修復錯誤。

如果發版負責人不是我，他們要怎麼判斷何時該為了修復錯誤而延後發版？

我們新的策略是：發版負責人不直接做決定，而是從其他團隊蒐集所有相關資訊，再交由產品負責人來定奪。如此一來，我們把「蒐集決策依據」的過程與「做出決策」本身分開。這有助於實現我們的目標——盡量減少只有我才能執行的發版任務。

業餘專案

我寫出了全世界最快的（尚未完成的）Ethereum 實作

我上個月提過，我找到了一個有趣的方式來更深入學習 Zig、直譯器和 Ethereum——就是用 Zig 寫一個 Ethereum bytecode 直譯器。

Zig 讓開發者對效能有高度的掌控，所以我在開發這個直譯器時，最早做的事之一就是在持續整合中建立效能基準測試，把我的實作與官方的 Go 實作拿來比較。

有一陣子，我的 Zig 版本效能稍微落後於 Go 版本。接著，我重構了效能測試腳本，結果效能竟莫名大幅下滑。

我在 Ziggit 上求助，這是一個 Zig 論壇，結果發現我的效能測試腳本和 Zig 程式碼中都有錯誤。一旦修掉這兩個簡單的錯誤，我的 Zig 版本瞬間超越了 Go 版本。

我的 Zig 版 Ethereum 實作現在效能超越官方 Go 實作 30 至 40%。

公平來說，我的版本只實作了大約 3% 的 Ethereum 功能，所以算是佔了不公平的優勢，但這仍然是個很有趣的專案。

總結

完成了什麼？

• 發布了 TinyPilot Pro 2.6.3。
• 找出 TinyPilot 發版流程中未被文件化的步驟，並已將大部分完成文件化。

經驗收穫

• 當工作需要跨團隊協作時，授權任務會變得更加困難。
  • 有些決策最終仍需由產品負責人來做，但團隊可以調整流程，將「蒐集決策所需的相關資訊」與「做出決策」拆成兩個獨立的過程。

下個月的目標

• 補齊 TinyPilot 發版文件中的缺口。
• 完成 2023 年的稅務申報。