リリースサイクルという悩み

自社のリリースサイクルいろいろ悩んでいいるが、最近なんとなくやってみてることを書き出してみます。

零細 IT 軽企業のパッケージミドルウェアが前提です。さらに中長期的な製品で、3 年以上は使ってもらう想定の製品で考えています。

  • メジャーリリースは半年に一回、つまり年に二回。
  • メジャーリリース時に下位互換をできるだけ破壊しない
  • 新機能は必ずプレビュー版として追加する
  • マイナーリリースでプレビュー版の下位互換を破壊する
  • プレビュー版機能の正式版化は慎重になる
  • プレビュー版機能は積極的に追加していく
  • プレビュー版機能は正式版機能に影響を与えてはいけない
  • 下位互換性を壊すときは 1 年以上時間をおいてから壊す

メジャーリリースは半年に一回

Ubuntu モデルで 18.04 と 18.10 という感じで、4 月と 10 月のリリースにしています。真似してるだけです。考えないというのは楽です。

メジャーリリース時に下位互換をできるだけ破壊しない

もともとはメジャーリリースでは下位互換性を壊して新機能を!というタイプだったのですが、それをやめました。

メジャーリリースこそ気軽にアップデートしてもらえるべきと考えたからです。

壊すときも今のままでも使えるが、今のままのオプションはあと1年後には使えなくなるから早めに切り替えてくれよな。みたいな感じで提供することにしています。

新機能は必ずプレビュー版として追加する

新しい機能をいきなり正式版として提供するのではなく、プレビュー版としてまずは導入し、使ってみたいお客様と連携しながら育てていくという戦略をとっています。

メジャーリリース時にとつぜん正式版として下位互換性を壊せない新機能を入れるのをやめました。

マイナーリリースでプレビュー版機能の下位互換を破壊する

プレビュー版機能を利用するときは事前に連絡してほしいと伝えているため、使っているお客様を把握できます。そのため、下位互換を壊すときも連携が取りやすいのがポイントです。

プレビュー版機能の正式版化は慎重になる

プレビュー版機能は長生きさせて安定して、もうこれ以上は変えるところないなと思ったタイミングで正式版にするようにしています。

焦って正式版にしてしまうと下位互換が壊せなくなってしまうため、徹底的にプレビュー版の状態で育てていきます。より使いやすくより安定できるように育てて、育ちきって枯れたタイミングで正式版としてリリースするくらいの気持ちでいます。

プレビュー版機能は積極的に追加していく

新機能は追加したとしても誰にも使われない可能性はあります。ただそれを恐れずまずこんな機能を実現できるよ!と体験できることを重視しています。プレビュー版として新機能を追加していくことにしています。

プレビュー版の追加は慎重にならず、まずは追加してみるという方針でやってみています。

プレビュー版機能は正式版機能に影響を与えてはいけない

最も重要なことはこれです。新しく追加したり、下位互換を壊すプレビュー版機能は「正式版機能」への影響を与えてはいけません。

プレビュー版機能を使っていない人に迷惑をかけてはいけません。

下位互換性を壊すときは 1 年以上時間をおいてから壊す

どんなに枯れていても下位互換壊す必要が出てくることはあります。その場合はまず突然変えるのではなく切り替えるチャンスを 1 年以上提供することにしています。

デフォルトでは切り替わるけど、昔の機能も使えます。廃止されるのは 1 年後ですので、移行をお願いしますという感じです。

とにかくパッケージ版のミドルウェアの場合は自社の環境で動く事が無いため、顧客の作業数を増やしてしまうのをできるだけ避ける必要があります。こちら都合で変える以上は 1 年以上は待つべきと考えています。

パッケージ製品のリリースサイクルとにかく難しいです。何が正解というのはない世界なので今後も考え続けていこうと思います。

Erlang/OTP / 時雨堂 / WebRTC / E2EE

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store