製品のリリース頻度を減らす
自社で開発しているミドルウェアパッケージ製品のリリース頻度をどうすれば下げられるかというのが最近の自分の中での課題になっている。
パッケージ製品というのは自社で動かすわけではなく、顧客の環境で動かすわけでアップデート頻度が高い場合、作業負担を強いることになる。
そこでできるだけリリース頻度を下げていきたいと考えているが、なかなか難しいので、どうやってみているかを書いていきたい。
現在のリリース頻度
リリースは Ubuntu を真似して 4 月と 10 月で、年 2 回がリリース。致命的なバグ修正や、ブラウザアップデートによる不具合対応などは、修正ができ次第すぐにリリースしている。
クライアント側のバージョンアップへの対応
自社製品は WebRTC という技術を使っており、これはブラウザに搭載されている機能の一つになる。ただ Chrome は 6 週間ごと、 Firefox は 6–8 週間ごと、Safari は 6 ヶ月ごとにアップデートが行われる。
つまり機能追加や、機能削除をコアとなるライブラリやメーリングリストなどから追いかけ続けて行く必要がああり、実際にやっている。
WebRTC のメーリングリストは Slack と連携しているし、コアとなるライブラリのコミットログは最低週 1 回は目を通している。
今後必要になりそうな対策を前倒ししまくって対応していく。例えば WebRTC は QUIC への置き換えが予定されているが、その雰囲気が出てきた去年の秋から QUIC の実装を始めている。
また、RFC も WebRTC に関連しそうなのは目を通し、それがコアのライブラリに実装されたタイミングで、こちらも対応だけはするようにしている。
一番怖いのは自社製品にとって必須や依存している部分が削除になることだ。
ちょうど WebRTC の利用している暗号方式である DTLS が 1.0 が無効になり、DTLS 1.2 が採用された。これは昨年の 11 月から検討されていたようで、今年の 4 月に適用されるようだ。
これは最初から最新のバージョンへ対応をしていたことにより回避できた。結果的ではあるが 3 年以上前に対応していたため、特に何も問題がないことになった。
- 最新への追従をできるだけ優先する
- メーリングリストから流れを読み解く
- コアライブラリの実装から流れを読み解く
- 実装の課題から流れを読み解く
これを守ることで半年間隔でもブラウザのバージョンアップについていけるようになると考えている。
機能を減らす
リリース頻度が増える原因の一番の要因は致命的なバグだろう。これを減らすにはとにかく機能を減らすしかないと考えている。
ここで言う機能を減らすというのは余計な機能を減らすという意味だ。つまり「見栄えのためだけに実装した機能」や「使いみちがない機能」を減らしていくしかない。
良いと思って作っては見たが全く使われなかった機能なんていうのもあった。
これらの機能を減らして行くためには「実装してから一定期間はプレビュー版として提供する」という方式を取っている。プレビュー版の機能を使いたい場合はかならず連絡をしてもらい、サポートや実際どう使いたいのかをヒアリングしていく。
次のリリースまでに連絡がない場合は使われていないと判断し、 更に次のリリースで機能の削除を行う旨を周知するという方法だ。
機能削除は本当に難しい。1 人でも顧客が使っている場合はその機能をずっと残し続ける必要がある。そのため基本的に「新機能」と呼ばれる機能はよほどのことがない限りは追加しないようにしている。
それよりは既存の基本的な機能の改善を優先している。より安定的に、より CPU を使わないように、より連携するシステム側のコードが減らせるようになどだ。
特に連携するシステム側のコードを減らせるような機能は積極的に搭載するようにしている。これは既存機能が不便だからコードでなんとかしているという状況のため、既存機能の改善をすることでコードを減らすことができる。
システム側の実装負担を減らすのがミドルウェアとしての役割だと考えている。
依存ライブラリを減らす
もともとライブラリへの依存が好きではないため、できるだけ自作するようにしている。直接依存しているライブラリはかなり少なく10 個以下になる。それもかなりメジャーなライブラリでログ、UUID、JSON 、HTTP サーバ/クライアントなどだ。つまりよく使われているデファクトスタンダードなライブラリだけに抑えている。
それ以外のライブラリはすべて自社で開発している。できるだけ他のライブラリに依存しないように開発している。
自前ライブラリの最大のメリットは必要な機能だけを実装できるという点だと考えている。つまり自社製品に利用するライブラリであれば WebRTC に必要な部分だけを実装していくだけでよい。
実際 DTLS や RTP/SRTP や STUN/TURN といったプロトコルのライブラリは WebRTC で利用しないものは一切実装していない。そのためコードの量自体を抑え込めるようになる。
コードや機能を抑え込めればバグが生まれる可能性も少しだけ低くなる。またテストも書きやすくなる。
結果的にバグを少しでも減らしやすくなり、致命的なリリースをする可能性が少しだが減る。
まとめ
ここまで書いて、なんかやって当たり前の話に思えてきたが、気にしないことにする。
最近は XaaS なサービスなどが多いため、リリースを積極的に行うというのが流行りだが、正直羨ましい。
ミドルウェアパッケージにとっての理想は、一度リリースしたらそれ移行はアップデートが不要で淡々と売れていくというのが、開発側にも顧客側にも良い。ただ、そうも行かないのでいろいろやってみている。
