5

私の会社は、サポートにお金を払っている大規模な組織にオンサイトでインストールされたアプリケーションのコンテキストで、メンテナンス リリースと「通常の」リリースの問題に苦しんでいます。まず、私の用語を定義させてください。

  • 製品のバージョン 1.0、1.1、および 1.2 をリリースしたとします。これらは、私が「通常の」リリースと呼んでいるものです。つまり、開発のメイン ブランチからの次のリリースであり、最新かつ最高のバグ修正と機能強化がすべて組み込まれています (リリースごとにそれぞれ数十もの可能性があります)。
  • ここで、1.0 の大物顧客が、これまで誰も遭遇したことのないショーストップの問題を報告したと想像してください。この問題は 1.2 にもまだ存在しており、残念ながら 1.3 は数週間または数か月でリリースされません。そこで、コードを 1.0 で分岐して、問題を修正する 1 つの変更だけを含む1.0.1 の「メンテナンス」リリースを作成します。

このアプローチでは、次の通常のリリースまで数週間待たせる代わりに、1 日ほどで問題を修正できるため、お客様は満足しています。また、メンテナンス リリースには小さな変更が 1 つしか含まれていないため、大規模な UAT プロセスを実行する必要はありませんが、次の通常のリリースにアップグレードする場合は、いくつかのバージョンが含まれている可能性があり、おそらく 30 または 40 を受け取ることになります。 (彼らのリスク回避的な意見では) 大規模な UAT を必要とする製品の変更。

問題はそれです：

  • ソフトウェアの複数のバージョンを作成してサポートするにはコストがかかります
  • これにより、泥沼に固執する顧客が最新バージョンから大幅に遅れることができます
  • インストールが他のすべての 1.0 の顧客と微妙に異なるため、これらの顧客を将来最終的にアップグレードするプロセスが複雑になります (データベースのアップグレードは、メンテナンス リリースで何らかの形で変更された場合に特に複雑になります)。

それで、この問題に対する他の人たちのスタンスはどうなのかと思っていましたか? メンテナンス リリースの急増によって自分自身の背中のためにロッドを作成せずに、どうすれば顧客を満足させ続けることができますか? たとえば、一部のカテゴリの修正をメンテナンス リリースとして実行することを許可しますが、他の種類の修正は次の通常のリリースで実行することを主張しますか?

明確化: バグのないソフトウェアを書くことは完全な解決策ではありません。なぜなら、上記の文脈における「問題」は、私たちの製品が依存する外部システムの動作に対する予測不可能な変化である可能性があるからです。

4

7 に答える 7

3

複数のアジャイル チームのバージョン管理、特にリリース ブランチのセクションを読むことをお勧めします(N チームで機能するものは 1 チームでも機能します)。

これまでにさまざまな回答やコメントを読んだことから、良いアドバイスが見つかるかもしれません。

于 2009-09-13T21:22:10.707 に答える
2

残念ながら、これは最初の顧客との契約に署名する前に決定する必要がある種類のことです。契約に含まれていない場合は存在しません。

シュリンクラップの場合、気にする必要はありません。契約はありませんので、サポートを提供する義務はありません。良好な関係を維持したいという願望に関係なく。事実は、あなたはすでに過去の顧客からあなたのお金を得ています。彼らを永続的に支援することで、すでに受け取っている利益をすぐにゼロにすることができます。本当にサービスモデルに移行したいのであれば、ソフトウェアをシュリンクラップで販売することはできません。（ウイルス対策ソフトウェアについて考えてみてください。支払いをやめ、更新をやめます。）

過去のバージョンのサポートを停止し、それに固執する日付のリストをWebサイトに提供します。気に入らない場合は、新しいソフトウェアを探すことができます。あなたは将来の販売を保証されることはありませんでした。

コメントに応じて編集：それでは、私が言ったように、あなたの問題はあなたの契約です。彼らがあなたに「あなたはアップグレードしなければならない」または「私たちは最後の3つのマイナーリリース以上をサポートしない」と言う力を与えないなら、あなたの会社は失敗します。今後は、将来の契約にそのような言葉が含まれていることを確認する必要があります。継続的なサポートとは、契約の内容のみを意味します。

于 2009-09-04T05:53:43.363 に答える
1

私たちはお客様のために 1 つのリリースのみを作成し、毎日ビルドと単体テストを行います (両方ありますよね?)

この 2 つを使用すると、コードを好きなだけ頻繁にプッシュできるので、メンテナンス リリースや通常のリリースについて心配する必要はありません。使用する価値のあるコピーは 1 つだけで、それが最新のコピーです。

編集: 「OMG 私たちの機能は途中ですが、まだリリースする必要があります。はい、つまり今すぐ!」という状況になると、新しい機能にタグを付けるだけです (プリプロセッサ ディレクティブを使用して) 。ビルド中に、タグ内のすべてのコードが単にコメントアウトされていることを確認してください。

于 2009-09-04T05:36:42.400 に答える
1

顧客が最初に来ます。一部の顧客はアップグレードしないため、ソフトウェアの複数のバージョンをサポートすることに我慢する必要があります。それは人生の厄介な事実です。ソフトウェア開発の一部の領域 (例: webapps - gmail の元のバージョンを実行している人はいますか?) では多少軽減できますが、そのような種類のシン クライアント環境でも、人々はシン クライアントをアップグレードしません (IE6 の人はいますか?)。 .

あなたができる最善の方法は、おそらくデフォルトで更新を自動化することによって、クライアントにアップグレードを促すことです。クライアントが多くの UAT が必要であると感じている場合は、以前に、クライアントが依存しているものを壊す更新によってクライアントを混乱させ、修正に時間がかかっている可能性があります。その場合は、テストと QA プロセスの改善を検討してください。

悲しいことに、これを改善するために他にできることがたくさんあるかどうかはわかりません。

于 2009-09-04T05:42:02.997 に答える
0

次のワークフローが役立つ場合があります (ただし、YMMV)。

  1. バグ修正用のトピック ブランチを作成し、最も早い時点 (1.0 リリースなど) で分岐します。たとえば、'foo-bugfix' という名前を付けます。
  2. バージョン 1.0 などのメンテナンス リリース用の新しいブランチを作成します。まだ存在しない場合は、このバージョンにバグが存在する場合は、. 「メンテナンス-1.0」
  3. バグ修正ブランチをメンテナンス ブランチにマージし、競合があれば解決します。
  4. 必要に応じてバージョン番号を変更します。「1.0.1」など、新しいメンテナンス リリースにタグを付ける
  5. サポートする他のバージョンについては、2 ～ 4 を繰り返します。

通常、プロジェクトの最後のバージョンに対してのみ、メンテナンスリリース（「maint」または「maintenance」などの名前のブランチで）を行います。ただし、重大なバグ (重大なセキュリティ バグなど) を見つけた場合は、影響を受けるすべてのバージョンで修正することをお勧めします (おそらく、あまり古くないバージョンや、まだ広く使用されているバージョンに限定することをお勧めします)。

HTH

于 2009-09-04T15:10:42.790 に答える
0

私が提案するのは、少なくとも最新のポイント リリースを試すよう常に顧客に依頼することです。1.0 から 1.1 に移行して、問題が解決するかどうかを確認してください。最初の質問が行われました。

ここで役立つのは、ソフトウェアの大きな機能上の穴をカバーしない限り、ポイント リリースに新しい機能を追加しないようにすることです。バグの修正のみを目的としたポイント リリースを作成し、せいぜい貧弱な機能設計を削除します。顧客を製品の再購入に誘導するための新機能を保存してください :-)

ポイント リリースで新機能を導入しないと、新しいバグの導入に対する顧客の不安が軽減される可能性もあります。新しいバージョンのインストールに関して、通常は予約されている理由。

顧客が現在のポイント リリースでまだ問題を抱えていて、それが緊急の場合は、'ホットフィックス' を入手できます。現在のポイント リリースが 1.2 の場合、お客様に提供される 1.3 のプレリリースにホットフィックスが含まれている場合があります。緊急を要するこの顧客は現在、実際に不安定なポイント リリースのテストを支援しており、ポイント リリースのその他の変更点についてフィードバックを提供することもできます。顧客がテストを手伝ってくれたら、保留中のポイント リリースにマージする単一の修正小さなリリースを行うこともオプションです。

これは、Microsoft のサービス パック方式に匹敵します。ホットフィックスを頻繁にリリースし、それらをサービス パックにまとめます (-> ポイント リリース)。広くリリースされる前に、多くの場合、ホットフィックスがパッチで修正される問題に直面している顧客と一緒にテストされます。

絶対に避けたいのは、「1.0.1 の顧客 A」と「1.0.1 の顧客 B」という複雑さと保守地獄を招くことです。

通常、パッチをメインラインにマージする必要があります。顧客が最新バージョンのパッチの作成を支援している場合は、それを受け入れてください。

于 2009-09-13T21:00:46.453 に答える
0

保守リリースと通常リリースの両方があります。

5.5 リリースに取り組んでいて、以前のバージョンの問題が 5.4.0.1 にある可能性があることを顧客が発見したとします。5.4.1.0 で解決策を提供し、現在のリリース、つまり 5.5 で修正を行います。現在のリリースの以前の問題をクローズし、古いリリースで顧客に新しいキットを提供する

于 2009-09-04T06:31:18.153 に答える