web-dev-qa-db-ja.com

RCビルドを小売に変換するための戦略は何ですか？

ビルドをRCからリリース済みのリテールコードに移行する方法の戦略を実装しようとしています。

ビルドにリリース候補のラベルを付ける場合、QAに送信して回帰を求めます。彼らがそれを承認した場合、そのRCはリリースされたリテールコードになります。

バージョンの「明白な」ラベル付けのアイデアが気に入ったので、ユーザーがベータ版かRCコードか小売りコードかを知ることができます。小売り以外のコードに明らかな透かしがある場合（RCまたは非純正は右下に透かしを作成します）。

...しかし、回帰を通過した後、プロジェクトを操作する（透かしを削除する）のは奇妙に思えました。 QA認定バージョンa.b.c.dの場合、小売コードはa.b.c.d + 1ではなく、同じバージョンである必要があります。

ビルドをインクリメントせずにリリースされていないソフトウェアバージョンに明確にラベルを付けて、小売りコードの透かしを無効にするためにどのような戦略を採用しましたか？私が検討したアイデアの1つは、インストーラーアーカイブで署名されたファイルを探すようにビルドを作成することです。非リリースコードにはこのファイルが含まれないため、アプリは透かしを表示します。

しかし、これでもQAは非リリースコードを処理しているようです。
アイデア？

編集： QA自身が「RC」インジケータを削除するために実行できるプロセスについてはどうですか？それはそれを処理する興味深い方法かもしれません。

development-processversioningqareleaserelease-management
6
Matthew

本能に従ってください。リリース候補をリリース前とリリース後のどちらの方向にも見せることができればいいのですが、そうです。リリースされたバージョンがQAによって承認されたものとまったく同じであることが重要です。私の経験では、通常のMOは次のとおりです。

  • 明確にマークされたテスト（アルファ、ベータ）バージョンを作成します。テストのためにQAに送信します。

  • リリースに近づいたら、再び明確にマークされたリリース候補バージョンを作成します。テストのためにQAに送信します。

  • リリース候補が承認の印を取得したら、最終的な「ゴールデンマスター」ビルドを作成します。これは、出荷する予定の正確にです。 「ゴールデンマスター」または「リリース候補」のマーキングはありません。それをもう一度QAに送信します。

  • QAがゴールデンマスターを承認したら、出荷します。または、themを出荷して、彼らが承認したバージョンが出荷バージョンであることを確認します。

「テスト」マークをオンまたはオフにするためのいくつかの技術的手段を考え出すことは依然として良い考えです。これにより、最終候補者の承認から出荷バージョンまでの間に実行する必要がある手順を最小限に抑えることができます。ここでの私のポイントは、製品をQAで確認する必要があるということです後あなたはそれらが何であれ、それらのステップを実行しました。

8
Caleb

これをオブジェクト指向の方法で見てみましょう。プロジェクトはバージョンを持っているだけです-コードの変更により、以前のバージョンとは異なるという意味です。したがって、バージョンはプロジェクトのプロパティである必要があります。

一方、プロジェクトは（ほとんどの場合）、それ自体をテストしたり認証したりしません。その決定は、テスト/ QAチームによって行われます。したがって、プロジェクトに「Alpha」、「Beta」、「RC」、「Gold」、「Platinum」、「Retail」などのラベルを付けることができますが、このラベルはビルドのプロパティではなく、認識のプロパティですそのビルドの。

この情報をプロジェクト自体（おそらくAssemblyInfo.csにさえも）に保存するのは魅力的ですが、質問とCalebの回答が示すように、各段階の後でプロジェクトを再構築する必要があります（透かしを編集/削除するため）。

したがって、これが解決策です-別のシステムを使用して実行時に透かしを生成します（プロジェクトでクエリ可能なWebオブジェクト、単純なファイル、データベースエントリなど、ユーザーが決定するだけで簡単にできます）。重要なのは、このシステムをプロジェクトの範囲外に保ち、テスト機関にのみビルド「透かし」を更新させることです。

このシステムは次のようになります（タイムラインを含む）。

  Version  |   Status |    Comment
------------------------------------------------------------------------------------------------------------
    1.0    |   Alpha  |  First dev. build released
    1.0    |   Beta   |  Dev. team tests and decides to release it as beta without any code change/rebuild
    1.0.1  |   Beta   |  QA team identifies a bug, dev. fixes, rebuilds, updates the version, sends it for more testing.
    1.0.2  |   Beta   |  QA team identifies a bug, dev. fixes, rebuilds, updates the version, sends it for more testing.
    1.1    |   Beta   |  QA team identifies a bug, dev. fixes, rebuilds, updates the version, sends it for more testing.
    1.1    |   RC     |  QA team promotes it to RC build. You send the exact same build for user testing/preview.
    1.1    |   Retail |  Users do not report bugs, QA team also does not. You decide this build (without any change) can be shipped to retail.

このシステムの追加の利点は、ビルドタグを制御し、新しいタグ（たとえば、期限切れ、リコール）を簡単に作成し、アプリケーションの再インストールやロールアウトなしでプッシュできることです。フェイルセーフとして、透かしは、システムへの接続を確立できない場合に備えて、デフォルト値または最後に照会された値を表示する必要があります。

編集：外部システムのファンではない場合は、プロジェクト自体に単純なファイルを保持しますが、メインのアセンブリ/ jar/etcには埋め込まれません。このファイルは、ビルド透かしを追跡できます。重要なのはnot変更するためにコンパイルする必要があるユニットに透かしを埋め込むことです。

2
Apoorv Khurasia

Visual Studioの構成マネージャー を探索する必要があります。それはあなたがやりたいことをすることができます。ビルドごとに必要なのは、ビルドしたいインストーラプロジェクトでコンパイルを実行するだけで済むように、それぞれの構成を異なるインストーラプロジェクトで実装しました。その中にDev/Test/prod透かしスキームを組み込んだ。

1
SoylentGray