1行まとめ

リリースにおける自分の関与をなくす

ハイライト

• 私がリリース作業を直接ひとつも担当しなかった、TinyPilot史上初のリリースを完了しました。
• リリース作業を委任して公開したことで、文書化されていなかったり、よく考えられていなかったりする手順が、リリースプロセスに数多くあることが分かりました。
• Zigでバイトコードインタープリターを書くのを、引き続き楽しんでいます。

目標の評価

毎月の初めに、その月に達成したいことを宣言しています。目標に対する結果は次のとおりです。

TinyPilot Pro 2.6.3を公開する

• 結果：リリースを公開しました。
• 評価：A

今回の目的は、意図せず私に属していたリリース手順をすべて洗い出すことでした。そのため、私がリリース手順を直接ひとつも担当しなかった初めてのリリースになりました。チームは共有ドキュメントをもとに、変更履歴やリリースのお知らせの作成など、すべての手順を実施しました。

TinyPilot Proのリリースプロセスを社内向けに文書化する

• 結果：リリースを実施するのに十分な内容は文書化できましたが、まだ改善の余地があります。
• 評価：B+

リリースプロセスの文書化は、とてもよい練習になりました。文書化されていなかったプロセスだけでなく、プロセス自体の弱点も明らかになったからです。

リリースプロセスには、これまで批判的に検討してこなかった部分が数多くありました。腰を据えて文書化してみると、不必要に手間がかかったり、ミスが起きやすかったり、車輪の再発明になっていたりする手順がいくつも見つかりました。

2023年分の税務申告をする

• 結果：書類の大半を集めましたが、まだ申告はしていません。
• 評価：B

TinyPilotのリリースに気を取られてしまい、まだ申告できていません。とはいえ、政府としては、今年のどこかの時点で申告してもらえるとありがたいでしょう。そろそろやったほうがよさそうです。

TinyPilotの統計

年次振り返りが注目を集めたことで、訪問者数は大きく増えました。ただ、TinyPilotの売上にはあまり影響しなかったようです。売上は17%減少しましたが、これは主に、1月が例外的に好調だったためです。月7万5,000～9万5,000ドルの売上が、通常の範囲です。

月次の利益を報告する新しい方法が必要です。契約製造業者に切り替えたことで、1か月単位の現金利益はほとんど意味を持たなくなったからです。毎月の利益は、3～4か月ごとに支払う製造費の請求タイミングに大きく左右されます。

とはいえ、直近3か月の平均利益は、私が望ましいと思っている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時間、バグ報告を監視する

リリースを告知する

1. TinyPilot Communityのリリースを公開する
2. リリースのお知らせのブログ記事を公開する
3. EUの販売代理店にリリースを共有する
4. 製造業者にリリースを共有する
5. 社内プレイブックのリンクを更新する
6. 公開メーリングリストにリリースのお知らせを送る
7. TinyPilotのTwitterでブログ記事を共有する

私が文書化して委任したのは、手動テストが必要な3つの作業だけでした。残りの22個は、まだ私が担当していたのです。

この一覧を見ると、リリースを実施するだけで25段階というのは多く感じます。実際には、特定の作業の中に数十個のサブステップがあるため、25段階をはるかに超えています。

手動の手順がこれほど多いと、もっと自動化すべきだという答えになりそうです。しかし、明らかに自動化すべき候補は見当たりません。たとえば変更履歴へのイメージハッシュの追加や、社内プレイブックのリンク更新は自動化できます。ただ、手作業を年間2時間減らすために、自動化に10時間ほどかかるでしょう。

私にとってより重要な教訓は、リリースに作業を追加するときは慎重になり、現在ある作業が本当に必要なのかを問い直すことです。

リリース前のバグをどう見つけるか

リリース作業の委任は、通常の委任より難しいことが分かりました。自分がどう判断したかを説明できても、その判断に必要な背景情報をチームメイトが持っていないことに気づいたからです。

例として、最終テスト中に遭遇したバグを紹介します。

通常、デバイスをネットワークに接続すると、ルーターが割り当てたローカルIPアドレスをそのまま受け入れます。しかし、固定された予測可能なIPアドレスを要求したいTinyPilotユーザーもいます。今回のリリースでは、固定IPアドレスを割り当てる機能をTinyPilotのウェブインターフェースに追加しました。

リリース前のテストでは、この機能は次のように動作していました。

カスタマーサービスチームがテストを実施し、問題はないと報告しました。テスト計画で想定していたとおり、新しいIPアドレスでページが読み込まれました。サポートエンジニアリングチームもテスト動画を確認し、機能は正しく動作したと報告しました。

私は動画を確認して、重大な問題に気づきました。ウェブインターフェースが新しいアドレスで読み込まれるまでの数秒間、ユーザーには次の恐ろしいエラー画面が表示されていたのです。

私が開発チームに見せると、彼らはひどく落ち込みました。

動的IPから固定IPへユーザーを誘導するUIに、開発チームは数週間の開発時間を費やしていました。DNSキャッシュ、ローカルTLS証明書、クロスドメインリクエストに対するブラウザーのセキュリティ保護が複雑に絡み合っていたため、これは特に難しい作業でした。大量のテストとオーケストレーションコードを書き、開発チームはついに正しく動くようになったと思っていました。ところが、TinyPilotのオフィスではスムーズに動作しなかったのです。

では、私がプロセスを細かく管理しなくても、こうしたバグをどうやって見つければよいのでしょうか。異なるチームが機能の動作に対して抱く期待のずれを、どうすれば避けられるのでしょうか。

私たちはプロセスを調整し、開発チームが新機能をリリースしたり既存の動作を変更したりするときは、リリース前テストの映像を確認して、自分たちの想定どおりに動作していることを確かめるようにしました。

どのバグを修正するか、どう決めるか

リリースプロセスを委任するうえでの次の課題は、リリース前テストで見つかったバグをリリースマネージャーがどう扱うかを決めることでした。リリースを延期するのか、それともバグを残したまま出荷するのか。

リリースを私に集中させていた頃は、出荷するか修正するかの判断は簡単でした。チーム横断の状況を把握していたからです。私は開発チームの議論にも参加しているので、バグの修正にどれくらいかかるか、その過程で別の何かを壊すリスクがどの程度あるかを知っていました。また、プロダクトオーナーでもあるため、そのバグが顧客にどれほど影響するかも理解していました。修正にかかるコストに対して重要な機能であれば、バグを修正するためにリリースを延期していました。

リリースマネージャーが私でない場合、バグを修正するためにリリースを延期するタイミングを、どう判断すればよいのでしょうか。

新しい戦略では、リリースマネージャー自身は判断を下しません。代わりに、他のチームから判断材料をすべて集め、プロダクトオーナーが決定できるようにします。こうすることで、判断に必要な情報を集めるプロセスと、判断そのものを分離できます。私にしかできないリリース作業を最小限にするという目標にもかなっています。

サイドプロジェクト

世界最速のEthereum実装（未完成）を書いた

先月、Zigやインタープリター、Ethereumについて楽しく学ぶ方法を見つけたと書きました。ZigでEthereumのバイトコードインタープリターを書いています。

Zigでは、開発者がパフォーマンスを高いレベルで制御できます。そのため、インタープリターで最初に取り組んだことのひとつは、継続的インテグレーションにベンチマークを設定し、自分の実装と公式のGo実装を比較できるようにすることでした。

しばらくの間、Zig版はGo版より少し遅い程度でした。ところが、ベンチマークスクリプトをリファクタリングした後、なぜかパフォーマンスが急落しました。

ZigのフォーラムであるZiggitで助けを求めたところ、ベンチマークスクリプトとZigコードの両方にバグがあることが分かりました。その2つの単純なバグを修正すると、Zig版はGo版を一気に追い越しました。

私のZigによるEthereum実装は、現在、公式のGo実装より30～40%高速です。

公平を期すなら、私の実装が対応しているのはEthereum全体の約3%だけなので、かなり有利な条件です。それでも、楽しいプロジェクトであることに変わりはありません。

まとめ

何ができたか

• TinyPilot Pro 2.6.3を公開しました。
• TinyPilotのリリースプロセスにある未文書化の手順を特定し、その大半を文書化しました。

学んだこと

• チーム横断の協力が必要な作業では、タスクの委任が難しくなります。
  • 最終的にプロダクトオーナーが判断しなければならないこともありますが、チームはプロセスを調整し、その判断に必要な情報を集めることと、判断を下すことを別のプロセスにできます。

来月の目標

• TinyPilotのリリース文書に残っている不足部分を埋める。
• 2023年分の税務申告を完了する。