少し前に、ジェフ・アトウッドはツイッターで次のように述べました。
ほら、私は迅速な新しいソフトウェアのリリースが大好きですが、WordPress のリリースの頻度はばかげています。
どのくらいの頻度でソフトウェア アップデートをリリースする必要があるのでしょうか。
- 毎日?
- 毎週?
- 毎月?
- 毎年?
最適なリリース戦略は?
少し前に、ジェフ・アトウッドはツイッターで次のように述べました。
ほら、私は迅速な新しいソフトウェアのリリースが大好きですが、WordPress のリリースの頻度はばかげています。
どのくらいの頻度でソフトウェア アップデートをリリースする必要があるのでしょうか。
最適なリリース戦略は?
WordPressの特定のケースでは、「セキュリティ更新」と「機能更新」を混同しています。これは悪いです。
これは、毎週小さなパッチをダウンロードするのではなく、セキュリティ バグが見つかるたびに Windows をインプレースで再インストールしなければならないようなものです。
WordPress には、セキュリティ更新のためにシンプル、高速、簡単なセキュリティ パッチ メカニズムが必要です。新しいバージョンの通常のアップグレード フローとは別のプロセス。
Wordpress のリリース頻度は、セキュリティに配慮し、既知の脆弱性をできるだけ早く修正するアップデートをリリースするため、頻繁にリリースされます。Wordpress の機能更新の頻度はずっと低く、4 か月から 6 か月ごとだと思います。
これは良いモデルだと思います。新しい機能を定期的にリリースすることで顧客を満足させますが、セキュリティ上の欠陥を見つけた場合は、すぐに修正をリリースしてください。
次のことを提案します。
updateTime (秒単位) - ユーザーが更新を実行するのにかかる平均時間
releaseDelta (日) - リリース間の最小時間
releaseDelta = updateTime/((1/365)*(60*60*8))
この式は、ユーザーがアプリケーションの更新を待機するのに 1 年間に 8 時間を超えてはならないという私の理論に基づいています。
これにより、更新がエンド ユーザーを混乱させることなく透過的な方法で行われる限り、頻繁な更新も可能になります。
これはあなたの特定の状況に大きく依存すると思います。そうは言っても、真面目なビジネスアプリケーションを毎日リリースするのはまったくばかげていると思います。毎日リリースしている場合は、ビジネス ルールが絶えず変更されるような非常に奇妙な状況でない限り、深刻な問題が発生している可能性があります。
iTunes のアップデートよりも頻度が低い。
私は次の、できれば単純な 2 部構成のガイドラインを使用しようとしています。
したがって、私たちにとって、デスクトップ アプリケーションや Web サービスなどは通常、最初のルールに該当し、Web サイトなどは 2 番目のルールに該当します。現在、開発期間は約 4 ~ 6 週間ですが、来年は 2 ~ 4 週間に短縮されます。これは、スクラム ハイブリッドへの「導入」でした。
製品は必ずしも開発中 (またはイテレーションに参加している) とは限らないことに注意してください。最初のルールが適用される場合、変更が必要になるまで、製品が古くなったままになる可能性は十分にあります。
それは、構成管理に対する顧客のアプローチに依存します。
彼らには選択肢があります。最終的に、彼らはあなたの製品を使用しないことを選択できます。
顧客があなたが毎日何かを変更することを受け入れ、彼らが気にしない場合、トレーニングや構成管理への影響はありません。自動更新があります。
SOE (標準動作環境) のお客様は更新を嫌います。
一部の顧客は、ソフトウェアの "calling home" を受け入れないことに注意してください。彼らは、独自のアップデートをホストしたいと思うでしょう。彼らの IT 担当者が関与する必要があります。これは彼らにとってより多くの仕事です。
一部のお客様は、独自の QA を行いたい、または行う必要があります。お客様とソフトウェアの種類によって異なります。
顧客がソフトウェアを承認/展開するためにテスト/作業を行う必要がある場合は、テスト/展開サイクルの長さの倍数をリリースします。顧客がインターリーブされた展開とテストに問題がない場合を除きます。それは、彼らが常に新しいバージョンをテストし、ロールアウトする場所です。
例: テストに 2 週間、リリースは 8 週間を超えない。
結果が重要なソフトウェアでは、リリース テストに数か月かかる場合があります。彼らは結果にビジネスを賭けており、当然のことながら慎重です。そのため、リリースは約 6 か月ごとです。
安全性が重要なソフトウェアでは、何ヶ月もかかる場合があります。毎年、または約 18 か月ごとは珍しくありません。頻度がさらに低いのはごく普通のことです。
正解はありません。製品によって異なります。
せいぜい毎月と言います。もちろん、アプリケーションの更新が自動化された透明な方法で行われない限り、毎週/毎日はあまりにも頻繁です。たとえば、Firefox の更新システムなどです。
必要に応じて何度でもリリースできます。ユーザーを苛立たせているのは、新しいバージョンが必要かどうかがわからないことです。これは、実装した新機能、修正したバグ、およびセキュリティの問題を修正したかどうかを明確にする必要があることを意味します。さらに重要なことは、ユーザーは、新しいバージョンをインストールしても何も壊れていないことを信頼できることを望んでいるということです。
可能であれば、必要なときにソフトウェアを自動的に更新して、更新プロセス全体をできるだけスムーズにし、ユーザーに見えないようにする必要があると思います。
私が働いている産業制御の分野では、めったにありません。通常、メジャー リリースはわずか 2 年で行われます。マイナー リリースは 3 ~ 6 か月ごとです。バグパッチはもちろん別の話で、必要に応じてリリースされます。それでも、既存のシステムをアップグレードする顧客はほとんどいません。もちろん、他のドメインでは、アップグレードはより受け入れられます。
これは、アップグレードの性質と、それを達成するために必要なユーザー介入の量によって異なります。
Web サイトであれば、何も壊さない限り、毎日アップグレードできます。
無料のセキュリティ アップデートの場合、ASAP は常に高く評価されます。
無料のバグ修正アップグレードは、ユーザーがインストールする必要がある場合、2 か月に 1 回を超えるべきではありません。
支払わなければならないものは年に 1 回しかありません。オペレーティング システムなど、特定のクラスのソフトウェアの場合はなおさらです。
リリースする価値のある新機能/バグ修正があるときは?? なぜスケジュールにあるのですか?
セキュリティ バグが見つかったらすぐに修正されることに異論はありませんが、そもそももっと堅牢なコードを書いてくれればよかったのにと思います。私が反対するのは (少なくとも Wordpress に関する限り)、プラグインを壊す可能性のある機能強化のリリースが早すぎることです。2.5 から 2.6 になるのにどのくらいかかりましたか? 2.7 も間もなくリリースされます。
自動または半自動アップグレードはその問題の一部を軽減しますが、プラグイン作成者もアップグレードするか、セキュリティ修正を機能変更から分離して、たとえば 2.5 を使い続けてもセキュリティを最新の状態に保つことができる場合のみです。私が使用するすべてのプラグインが 2.6 または 2.7 または (その時点で) 4.0 で動作することを確認するまで、パッチを適用しました。
必要なときはいつでも。一部のユーザーは、定期的に更新を取得する方が安全だと感じている一方で、毎日「129 個の新しい更新プログラムをインストールする必要があります。ここをクリックしてダウンロードするのに 20 分待ってから、さらに 10 分待ってインストールしてください! ...あなたは私のポイントを参照してください。