一句話總結

把自己從發布流程的關鍵路徑上移除

亮點

• 我們完成了史上第一次完全沒有由我親自執行任何發布任務的 TinyPilot 發布。
• 透過委派來發布版本，幫助我們找出發布流程中許多未被文件化或設計不佳的步驟。
• 我持續樂在以 Zig 撰寫 bytecode interpreter(位元組碼直譯器)。

目標評分

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

發布 TinyPilot Pro 2.6.3

• 結果：我們已發布此版本。
• 評分：A

我們試圖找出所有意外集中在我身上的發布步驟，因此這是第一次我完全沒有親自執行任何發布步驟的版本。團隊依據共享文件完成了每一個步驟，包括撰寫 異動清單與發布公告等工作。

在內部文件化 TinyPilot Pro 的發布流程

• 結果：已完成足以涵蓋此次發布的文件，但仍有待改進之處。
• 評分：B+

將發布流程文件化是一次很棒的練習。它不僅暴露出未被文件化的流程，也暴露出流程本身的弱點。

我們的發布流程中有許多環節未曾被仔細檢視。當我坐下來逐一記錄時，發現有好幾個步驟過於耗費人力、容易出錯，或根本是在重複造輪子。

申報 2023 年稅務

• 結果：已收集大部分文件，但尚未申報。
• 評分：B

我最後被 TinyPilot 的發布工作岔開了注意力，所以還沒申報。不過，我想政府應該會希望我今年內找個時間完成申報，所以我大概還是得去辦一辦。

TinyPilot 統計數據

訪客量大幅飆升，主要是因為我的年度回顧吸引了關注，但似乎對 TinyPilot 的銷售影響不大。銷售額下滑了 17%，但主要是因為 1 月份是異常強勁的一個月。每月銷售額 75,000 至 95,000 美元才是我們的正常區間。

我需要一種新的月度利潤呈現方式，因為改用合約製造商後，以單月為單位的現金利潤數字基本上已失去意義。每個月的利潤主要取決於我每三到四個月支付一次的製造費用帳單時點。

儘管如此，我們近三個月的平均利潤已回到我樂見的 10,000 至 20,000 美元區間。

原來我們的發布流程有 25 個步驟

最初，TinyPilot 的軟體發布完全由我一個人負責。隨著產品日趨成熟、流程中增加更多步驟，每次發布往往需要 10 到 20 小時的工作量。

大約 18 個月後，我將最困難的發布任務委派給團隊成員，其中包括大部分的手動測試。這讓我每次發布所需的時間縮短為三到五小時，當時我覺得自己已經做得很好了。

在最近一次的 TinyPilot 發布中，我挑戰自己要把所有事情都委派出去。我希望確保即使在我無法參與時，發布工作也能持續推進。

我開始為自己仍負責的任務撰寫操作說明，原本以為只需要記錄少數幾個步驟。

當我把每次發布仍由我執行的所有事項一一列出時，才發現每次發布其實包含了 25 項不同的任務：

測試 release candidate(候選版本)

1. 建立 release candidate 建置版本
2. 起草 changelog(異動記錄)
3. 起草 security advisories(安全性公告)（如適用）
4. 起草發布公告
5. 更新測試計畫以涵蓋所有功能變更
6. 在 Voyager 裝置上測試 release candidate
7. 測試從已發布的建置版本更新至 release candidate
8. 在 DIY 裝置上測試 release candidate
9. 針對實體裝置執行自動化 end-to-end tests(端對端測試)
10. 審查測試結果
11. 決定是否發布此版本

發布版本

1. 發布 security advisories（如適用）
2. 發布 changelog
3. 發布 TinyPilot Pro 正式版本
4. 驗證更新至最新版本是否順利完成
5. 向 TinyPilot 團隊發布發版通知
6. 將 image hashes(映像檔雜湊值)加入 changelog
7. 至少監控 48 小時的錯誤回報

發布公告

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

我原本只文件化並委派了三項任務，也就是需要手動測試的那些。但我其實仍親自處理其他 22 項。

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

當有這麼多手動步驟時，直覺會認為解法是進一步自動化，但我看不到有明顯適合自動化的項目。我們當然可以把像「將 image hashes 加入 changelog」或「更新內部 playbooks 中的連結」這類步驟自動化，但可能得花上約 10 小時的自動化開發時間，一年卻只能省下兩個小時的手動工時。

對我而言，更重要的收穫是要對新增發布任務持保守態度，並質疑現有步驟的必要性。

我們如何在發布前捕捉錯誤？

委派發布任務比一般的委派更困難，因為我發現即使我能說明自己如何做決策，團隊成員仍缺乏做出這些決策所需的背景脈絡。

舉例來說，我來分享一個我們在最終測試階段遇到的錯誤。

通常，當你將裝置接入網路時，它會接受路由器指派的任何本地 IP 位址。有些 TinyPilot 使用者希望裝置能要求一個固定的、可預期的 IP 位址。在最近一次的版本中，我們在 TinyPilot 的網頁介面中新增了指派 static IP address(靜態 IP 位址)的支援。

以下是此功能在發布前測試時的樣貌：

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

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

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

我們已投入數週的開發時間，打造引導使用者從動態 IP 轉換至 static IP 的使用者介面。由於涉及 DNS 快取、本地 TLS 憑證以及瀏覽器對 cross-domain requests(跨網域請求)的安全防護等複雜因素，這項工作特別具有挑戰性。經過大量測試與協調程式碼的撰寫後，開發團隊以為終於大功告成，結果卻發現在 TinyPilot 辦公室內並未順暢運作。

我們該如何在我不鉅細靡遺地介入流程的情況下，捕捉到這類錯誤？又該如何避免不同團隊對功能運作預期的落差？

我們決定調整流程，讓開發團隊在發布新功能或變更既有行為時，會檢視我們的發布前測試影片，以確保運作方式符合他們的預期。

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

在委派發布流程的過程中，下一個挑戰是釐清 release manager(發布經理)在發布前測試中發現錯誤時該如何處置。他們該延後發布嗎？還是按原狀帶著錯誤發布？

當發布流程集中在我身上時，要決定「照常發布還是先修復」相對容易，因為我掌握跨團隊的脈絡。我與開發團隊保持密切聯繫，所以知道修復錯誤需要多久、過程中破壞其他功能的風險有多高。同時我也是 product owner(產品負責人)，能理解錯誤對客戶的影響程度。如果某項功能夠重要，且相對於修復成本而言值得等待，我就會延後發布以便修復錯誤。

如果 release manager 不是我，他們該如何決定何時該為修復錯誤而延後發布？

我們的新策略是，release manager 不直接做決定，而是從其他團隊蒐集所有資訊，再交由 product owner 定奪。如此一來，我們將「蒐集決策所需資訊」的過程與「做出決策」本身分離開來。這也符合我們盡量減少只有我才能執行的發布任務之目標。

業餘專案

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

我上個月提到，我找到一個有趣的方式來更深入學習 Zig、interpreters(直譯器)與 Ethereum——我正在用 Zig 撰寫一個 Ethereum bytecode interpreter。

Zig 讓開發者對效能有高度的掌控，因此我在開發 interpreter 時最早的任務之一，就是在 continuous integration(持續整合)中建立 benchmarks(基準測試)，將我的實作與官方的 Go 實作進行比較。

有一段時間，我的 Zig 版本表現略遜於 Go 版本。接著，我重構了基準測試腳本，效能卻莫名大幅下滑。

我在 Zig 論壇 Ziggit 上請求協助，結果發現我的基準測試腳本和 Zig 程式碼中都有錯誤。一旦我修正了這兩個簡單的錯誤，我的 Zig 版本便一舉超越了 Go 版本。

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

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

總結

完成了什麼？

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

經驗心得

• 當工作需要跨團隊協作時，委派任務會變得更加困難。
  • 有些決策最終仍需由 product owner 做出，但團隊可以調整流程，將「蒐集決策相關資訊」的過程與「做出決策」分離。

下個月的目標

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