質問はあなたの製品を開発するためにプレリリース製品または技術（Community Technology Preview、BetaまたはRelease Candidateなど）を使用しましたか？市販製品の開発にプレリリースソフトウェアを使用していますか？
例えばもしそうなら、あなたは...
1..etc SQL Server 2008のRCに対してMicrosoftのASP.Net（昨日RTMを行ってきました）MVCまたは組み込みソフトウェアを使用して
1のウェブサイトを開発している場合がありますプレリリース製品が適切にリリースされたときに問題が発生するリスクを最小限に抑えるために、どのような手順（または遂行）を取ったのですか？
2.製品を使用する前に特定の期間（たとえば、製品がリリース候補になるまで）待っていますか？
3.プレリリーステクノロジの主な利点（対リスク）は何ですか？
実際に私が今までに成功したソフトウェアプロジェクトはすべて、かなりの量のベータ版を使用してリリースされました（erm、公開されたWebサイト）。
私たちは主にこれらのプロジェクト（主にオープンソースプロジェクト）のテストカバレッジと、愚かなことをしていないという過去の実績を評価します。
古いベータ版は、必要な機能を果たしている限り動作しますが、通常は大規模な書き換え後すぐにスナップショットを作成します。
最近ではテスト駆動ですので、のものが動作するかどうかはわかります。ライブラリにバグがある場合は、古いバージョンを使用するか、バグを修正します。また、アップデートが深刻なバグを持っているかどうかを直ちに評価することもできます。したがって、「未完成の」ソフトウェアを使用することは、これ以上重要なことではありません。最新の機能にアクセスすることは常に重要なことですが、時には重要な修正を加えるために行うこともあります。
本当に何かが必要な場合を除いて、私は仕事がそれらに取り組む前に、より広い市場でテストされるまで待つ傾向があります。私はそれのために新しいものを採用するだけではありません。それは私がそれを使う前に見たかった目の数になります。
私のためにシステムを設計/開発するにはインフラストラクチャーを踏み外すことなく十分な難題があります。
明らかに、クライアントが初期の技術リリースを採用している場合、私の手は強制されます。
私は、このような不安定なコンポーネントを本番ソフトウェアで使用しません。
質が必要な場合は、強固な基盤を構築する必要があります。
多くの大手ソフトウェア企業は、成熟するまでは新しいコンポーネントや技術を使用しないで、安全な側にとどまることを知っています。
すべては、受け入れる意思のあるリスクに依存します。
私はしません。
通常、私は商用目的で製品を使用する前に、サービスパック1まで待ちます。
私はこのルールを壊してしまった奇妙な状況で、問題を解決するための不必要なストレスと開発者の負担を大いに作り出していることがわかりました。
あなたはそのソフトウェアをどれだけ信じているかによって異なります。基本的には、現在のソフトウェアよりも効率的にユーザーの問題を解決することになります。 asp.net 2.0が最初にプレビューされたとき、私たちはすぐにそれを採用しました（asp.net 1.1以上の大きな改善だと思ったから）
asp.net mvcではそうではありません。今、私たちが以下のプレビューソフトウェアを採用することを決定した場合、あなたの3つの質問に対する私の答えは：
あなたの最初の点について - あなたがIDEで最近得た進歩の種類 - 最終版が関係している。これらの企業は、変化について事前に通知することについて非常に良い仕事をしています。その技術が大衆によって採用されるかどうかについては、お客様のクライアントがその余計な手を差し伸べることを望んでいるでしょうか。
あなたの2番目の点について - いいえ、私たちが新しいリリースについて強く感じたら、それが始まった瞬間、私たちはその余分なエッジを持つことを研究し始めます。
利点 - - ソフトウェアは、手頃なコストで問題解決がある場合 - その後、あなたはアーリーアダプターとして大当たりしているあなたの第三の点について
。あなたに明らかに少ない供給とより多くの需要があるだろうこれらのスキルのためのより多くを充電することができ
リスク - ソフトウェアが大衆に受け入れされていない場合 - あなたの時間とお金を投資行くドレイン;-)時には
ダウンバグの修正やパフォーマンスの改善が必要な場合に必要です。 FAE（フィールドアプリケーションエンジニア）が安定していると言えば、私はそれを試してみるつもりです。
私にとっては、製品をドアから出すまでの時間です。私はSilverlightなどで作業しています。 SL3で利用できる機能のいくつかは、次のバージョンのソフトウェアに必要です。 SL3がRTWになった後に本当にすばやくリリースしたい場合は、ベータ版を開発する必要があります。私たちはそれを待つことはできません。
状況によって異なります。以前の仕事では、ADO.NET Entity Frameworkをまだベータ版で使用していました。ベータ版を徹底的にテストし、自動化された単体テストとコードカバレッジ分析を使用して、徹底的に検証していました。ベータテストで合格しました。
これは良い動きであることが判明しました。これにより、最終リリースの3カ月間の待機時間が節約されました。ベータ版とリリース版の間の急激な変更を修正するのに数時間かかりました。
私が使用しないのは、リリース前のソフトウェアですが、リリースされるかどうかは分かりませんでした。私がそれを自分でサポートしない限り、それにはオープンソースソフトウェアが含まれる。
お客様の製品が出荷される場合、またはクライアントマシンにインストールされる場合は、非常に注意してください。
Webベースのシステム（Silverlightなどのコンポーネントを含む）の場合、可能です。 以前の私の会社は、正式にリリースされる前にASP.NETベータに基づいてシステムを導入しました。
これは、特定の場合（たとえば、必要な画期的な技術）の良い選択肢です。ただし、注意点が強いほど、コードが多くなればなるほど、変更する必要があります。ベータ製品には、期待される寿命、サポート、または従来の配慮がありません。したがって、ベータ製品に基づいてコードビルドを置き換える必要があります。
私にとって、絶対に必要な場合を除き、私はこれをほぼ確実に避けるでしょう。どうしてベータ版を使っているのですか？それが非常に良い答えであれば、リスクを考えてみてください。それ以外の場合は、あなたの車のために実行します。 ;）
場合によっては他に選択肢がありません。たとえば、新しいCTPバージョンのツールが既存の技術を吹き飛ばしただけの場合などです。例えば
：Windowsワークフロー財団がリリースされたとき
、いくつかの選択肢が存在していました。開発サイクルの時間枠（1年以上）を考慮し、CTpバージョンでリスクを取り、研究開発を開始することが有益であることを認識しました。そのプロジェクトに支払ったことが判明しました。
もう1つの例は、新しいSync Frameworkです。私たちはSQL EE/STDプロバイダを必要としましたが、SQL CEプロバイダだけが出てきました。 CEプロバイダのプロトタイプを作成し、新しいEEプロバイダがリリースされたときにアップグレードしました。
私たちの唯一の選択肢は、SQLサーバーのマージレプリケーションまたは類似のテクノロジを使用することでした。うん！
これは、プレビュー3のMVCを使用して作成されたと思います。単なる考えです。 – Kieron