リリース識別(Release Identification) †
要約 †
- リリース識別は「x.y.z.build」で
- A,RC,GA → やめようよ
- 公開しなくてもよいコンポーネント識別(Componet Identification)とは異なり、リリース識別はリリースが顧客に特定される方法にも影響を与える。完全な識別は、製品名と、適切な製品リビジョンとバリエーションを表現する情報で構成される(第9章を参照)。目標は、全体的な効率を向上させることが可能な、できるだけ少ない名前と識別子で必要な情報のすべてを取得することだ。
- ここで紹介するのは、私にとってよく働いて、多くのベンダーが使用する一見して任意の識別方式よりもかなり有用であることが証明されているのアルゴリズムだ。
フルリリース(完全なリリース)(Full or Complete Releases) †
ターゲットとしている人に関わらず、完全なリリースは最も以下を用いて決定される
- •製品の名前
- •x.y.z.buildの4桁のタプルは、リビジョン情報を表現する
- •製品のニーズに基づくバリエーション識別子の任意の数
- 4桁のタプルxyzbuildの部品は、表15-2で定義されているこの方式はリビジョンの自然なリニア順序を活用することに注意。
- マーケティングのためには顧客にだけメジャーとマイナーの識別子を公開するのが良い。
- 言い換えれば、顧客は、製品のバージョン3.4受け取るとき、バージョン3.4.2.129または3.4.7.13をかもしれない。
- できるだけ少ない名前と識別子にする主な動機は、販促資料、ライセンス契約、販売担保などの完全なタプルを管理しようとする費用だ。メンテナンスリリースために、すべてのこれらの資料の再印刷の費用を負担することは望まないだろう。
- 一部の人々は、適切な識別子を挿入することによって、この方式での配布のターゲットを含むことをお勧めしている。たとえば、Aはアルファ/内部のリリース、RCはリリース候補でQAに送るもの、マネージドリリースのためのMR、そして、一般的リリースのためのGA。すべてのyまたはz右側に挿入する(「SuperDraw? 4.5A」など)。私はこれをすることを望まない。それは全体的な命名規則が必要以上に複雑になり、それが対象とする人と一緒にリリースされているものを混合するからだ。
表15-2リリースタプルの定義 †
x (メジャーリリース) †
- メジャーリリース。メジャーリリース番号をインクリメントするための一つの動機はいくつかの大規模な、顧客から見えるアーキテクチャや機能変更があった場合だ。これらの変更は、順番に、マーケテクトによって定義され合意されなければならない。非常に大規模なデータベースを管理するシステムを考えてみよう。このようなシステムでは、以下の様な任意のリリースとメジャーリリースを定義するかもしれません。
- •データベースの構造を変更した。
- •以前のバージョンとは互換性がないような公開されたAPIを修正した。
- •削除された機能(もちろん、良いマーケテクトは不要な機能を削除する)
- •新しいオペレーティングシステムのサポートなど、実質的な新機能を追加した。
- 複数のコンポーネントに依存しているシステムでは、1つのxをインクリメントしても、別のxのインクリメントを意味するかもしれない。例えば、リリースx.*.*のクライアントのクライアント・サーバシステムは、サーバーxでの動作が保証されているといったように。
- xはまた、純粋にビジネス上の理由でインクリメントすることができる。例えば、顧客のサポート契約は、次のメジャーリリース後18ヶ月の間サポートされることを述べているかもしれない。Xをインクリメントすることにより、顧客をアップグレードへの強制的なパスにおく。
- ほとんどのマーケテクトは、できるだけ早くすべてのお客様にメジャーリリースを配布する強力な目標を設定する必要がある。
y (マイナーリリース) †
- 望ましい特徴または他の改善に関連付けられているのがマイナーリリースだ。リリースの機能のセットによって、マーケティングがそれが正当と認めるときは、マイナーリリース番号がインクリメントされる。xをインクリンメントするのかyをインクリメントするのかという決定は、任意のように見える。マーケテクトは、増分をトリガーするイベントを定義する必要がある。
z (メンテナンス・ドットリリース) †
- メンテナンスや「ドット」リリース。メンテナンスリリースは、リリースの内容によって影響を受けるすべての顧客が利用できるようにしている。任意のドットリリースは、同じメジャーおよびマイナーリリース番号を共有する他のドットリリースと互換でなければならない。
build †
- 製品に関連する特定の番号だ。コンパイル言語では、簡単にビルド番号を計算できる。インタプリタ言語の場合は、ビルド番号は完全にチェックインされたコードベースにラベルを付ける簡単なプログラムによって作成することができる。
- 通常、技術サポートに関連して、正確な識別目的のために必要としない限り、ビルド番号はめったに顧客に提示されない。
部分的なリリース †
- 主にマーケティング要因に依存する部分リリースのための識別方式を決定。コンポーネントや成果物がメインの頒布とは別々にオプションとして購入することができれば、それは前のセクションで指定されたガイドラインに従って、独自のx.y.z.build identification方式が最善です。命名の一貫性は、顧客が様々なオプションのコンポーネントのメンタルモデルを簡単に構築できるようになります。また、それが簡単に利用可能な製品の全体的なリストを構築することができます。
- 部分的なリリースを作成する際の重要な問題は、そのコンポーネントや機能と主要製品のそれらの間の依存関係を管理することだ。この章で後述するように、これらの依存関係は、リリースの識別子を管理する規則を介してやアーキテクチャの設計によって捕捉することができる。ルールアプローチの例としては、バージョンx.yのあるコンポーネントのすべてのリリースでは、すべてのバージョンとコンパチブルであることを、x.ynのyn部分が、yと同じかそれ以上を必要とすることで表現するかもしれません。例えば「SuperDraw?はレンダリングツール4.5を強化」する部分的なリリースは「SuperDraw? 4.5と SuperDraw? 4.6あるいはそれ以上のバージョンと互換性がある」ことを表現できます。
- これは忙しい仕事のように見えるかもしれませんが、それはあなたと顧客の多くの痛みを軽減させる(ライセンス契約は、これを必要とする場合もある)。
- なお、別々に販売されていない、将来的に改訂されることが期待されていない部分のリリース(例えばアンチウイルスファイル)では、特別に定義された名前と日付で通常は十分だ。
パッチリリース †
- パッチリリースは、通常は正確に既知のエラーを持ってインストール中の既存のコンポーネントを置き換える、製品のいくつかのサブセットであることを思い出してください。パッチ・リリースを識別することは特別な挑戦にあたる。パッチリリースは、使用している何らかに常に関連付けられており、潜在的にストレスの多い状況の顧客に対処することを意味する。また、パッチを作成したチームは、システムを作成したチームではないかもしれないので、以前のリリースの識別方式に精通していない可能性がある。
- パッチが既存の製品に大きく依存しているので、通常、パッチ識別子にその製品を参照させることが便利です。同時に、あなたは重大なミスがQAやリリースプロセスで作られていない限り、パッチはめったに改訂されていないので、x.y.z.buildの番号付け規則を採用する必要はない。
- 指定されたパッチは、以前のパッチの修正を含んでも含まなくてもよい。パッチはそのように設計されていない限りは累積されない。
- パッチは、多くの場合、それら自身の感情的なイベントやバグに関連している。これらのイベントやバグのいくつかの側面は、通常はパッチと関連づくので、私は名前と、あるいは日付でパッチを参照することをお勧めする。メンテナンスリリースとビルド番号は、必要とするパッチを識別することができるが、この命名規則ではオプションである。外部の顧客がみる名前は、「SuperDraw? 4.5 Repaginate Long Documentationのパッチ」のようなもので、このパッチは任意のSuperDraw? 4.5に適用することができることを意味するかもしれない。もしもパッチが特定のドットリリースに焦点を当てている場合は「SuperDraw? 4.5.2 Repaginate Long Documentationのパッチ」とする。
- 他のパッチに依存しているパッチは、ドキュメントを介してそれらの依存関係を呼び出すことができる。多数のパッチが製品に関連付けられている場合、私はメンテナンスリリースでそれらのすべてを収集することをお奨めする。これが不可能な場合は、別のアプローチは、同じことを行うサービスパックです。あなたのドキュメントは、サービスパックが累積的であるかどうかについては明確にしなさい。
- 誰もがパッチに名前を付けると同意するわけではないことに注意しなさい。あなたのパッチがエラーを持っていることを想像してみてください。(もちろん、考えられること)これは、バージョン管理する必要があり、バージョンは番号を介して処理されることがベストであることを意味します。あなたが最初のバージョンに問題がある場合は「SuperDraw? 4.5 Repaginate長い文書Serverパッチを、「SuperDraw? 4.5 Repaginate長い文書Serverパッチ バージョン2」と呼ばれる第二のバージョンをリリースすることができるこの問題を解決することを選択したけれども、最終的には制限を超えた事態に遭遇するだろうから命名上の任意の制限を課さない。
- 非常に洗練されたアーキテクチャは、インストールされ、インストールされていないものを追跡し、一緒にパッチをパッケージ化するのに十分に賢い。一部の企業は、自社のソフトウェアでこれを行って、そして自動更新を可能にする。例えば、あなたが、パッチマネジメントを含むようにアーキテクチャを拡張したいと仮定しよう。これは自動更新が正しくインストールされたことを判断でき、そして何かが間違っている場合、変更をロールバックできる必要がある。これらは一般的に、非常に複雑な要件なので、私はこの方法はお勧めしません。
コラム:バグ修正は無料である必要はない †
- バグ修正はライセンスの一部として含まれていない場合、マーケテクトはそれらを修正するタイミングを決定する必要があります。時に正しい選択は、顧客との良好な意志を構築するための方法としてそれらを修正することであり、時に正しい選択は修正を待つことだ。
- 私は一度、サポートされていない製品のバグを修正する、極めて緊急の要求をもった顧客を抱えていた。具体的には、製品を使用するための永久ライセンスを持っていましたが、彼らがインストールされていたバージョンはサポートされなくなった。彼らはいくつかのリリースの過程で彼らのシステムをアップグレードしようとして失敗していたので、本当の意味では、彼らは自分自身でこの問題をもたらしました。私は元々は「No!もしバグ修正をしたい場合は、アップグレードすることができます。」と述べてました。
- ことわざは、「お金がものをいう」。 。かつて修正のための実質的な手数料を交渉することができたので、私は、NoからYesになりました。私のチームはのバグを押しやり早い時間で修正しました。顧客は、あまりにも長い間遅れていた主要なアップグレードを回避できるこのサービスに感銘を受けてました。
バリエーション †
- バリエーションは、パッチのように、単調に増加するリビジョン番号を持っていない。それらを名づけたり、全体的な識別文字列に名前を挿入や付加したりすることが最良の方法です。たとえば、私たちのSuperDraw?クライアント/サーバ・システムは、LinuxとSolarisをサポートしていることとする。これらのオペレーティングシステム用のバイナリは、機能的に同等だが、物理的に異なっている。したがって、あなたは、「Solaris用SuperDraw? 4.5」「Linux用SuperDraw? 4.5」バージョン4.5のリリースと呼ぶかもしれない。
- システムまたはコンポーネントは、通常、移植性、国際化、または性能特性に関連付けられており、複数のバリエーションをサポートしている場合は物事はより複雑になる。SuperDraw?は、シングル(デフォルト)およびマルチCPU、6つの言語、2つのパフォーマンスのオプションを持っていると仮定する。ここでは、これが扱われるかもしれないいくつかの方法がある。
- “SuperDraw? 4.5, German Language for Linux” for a full release of the single- CPU version
- “SuperDraw? 4.5, German Language for Linux, multi-CPU,” for a full release of the multi-CPU version
- “SuperDraw4.5emailNotificationWorkflowPatch?,Germanlanguage,forLinux”
- 一般的なルールとして、より多くのオプションにはより複雑な名前となる。顧客は毎日これらの名前に対処しないし、彼らはほしいまたは必要なものを明確に覚えているので、これは良いことだと考えている。