偶発的にリリースされたコード-to-live-how-to-prevent-happening-againでの私の質問にさらに。クライアントの UAT の後、多くの場合、クライアントは機能のサブセットがリリースされることに満足しているが、他の機能は将来のリリースで欲しいと言っています。
私の質問は、「機能の 3 分の 2 (3 つのうちの 2 つ) をどのようにリリースしますか?」です。Microsoft などの大企業が次のような状況にどのように対処するかに興味があります.. "。
次のリリースでリリースされていないこれらの 5 つの機能が開始されたと仮定すると、リリースのビルドと展開でそれらをどのように無視できますか?
開発した機能の 2/3 をどのようにリリースしますか?
成果物のサブセットをリリースする方法は?
-- リー
これについて事前に考えていなければ、それはかなり難しいことです。
しかし、将来的には、これを行うために自分自身を設定する方法は次のとおりです。
分岐とマージの両方を非常によくサポートする、実際のバージョン管理システムを入手してください。歴史的に、これはgitやMercurialのようなものを意味していました。これは、Subversionのマージサポートが非常に弱いためです。（ただし、Subversionチームは最近、マージサポートの改善に取り組んでいます。）Windows側では、このようなツールに最適なVCツールがわかりません。
個々の機能の作業を整理する方法を決定します。1つのアプローチは、各機能を独自のブランチに保持し、新しい機能の準備ができたときにのみメインブランチにマージすることです。ここでの目標は、メインブランチを常にほぼ出荷可能に保つことです。これは、機能のブランチがほこりを集めない場合に最も簡単です。おそらく、各プログラマーは一度に1つまたは2つの機能のみを処理し、準備ができたらすぐにそれらをマージできますか？
または、バージョン管理履歴から個々のパッチを選択することもできます。これは面倒でエラーが発生しやすいですが、正確に1つの完全な変更を行う非常にクリーンなパッチを作成する特定の非常に統制のとれた開発グループでは可能かもしれません。このタイプのパッチは、Linuxカーネルコミュニティにあります。Linux 2.6 gitwebのいくつかのパッチを見て、このスタイルの開発がどのように見えるかを確認してください。
トランクを常に「ほぼ出荷可能」に保つのに問題がある場合は、ExtremeProgrammingExplainedなどのアジャイルプログラミングに関する本を読むことをお勧めします。新しいコードが非常にバグが多く、基本的な論理エラーを見つけるために長期間のテストが必要な場合、世界中のすべての分岐とマージは役に立ちません。
更新
機能ブランチは継続的インテグレーションでどのように機能しますか？一般的に、私はメインブランチと同じように、チェックインのたびに機能ブランチを構築する傾向があり、開発者は多かれ少なかれ毎日コミットすることを期待しています。しかし、もっと重要なことは、機能ブランチをメインブランチに非常に積極的にマージしようとしています。2週間前の機能ブランチは、誰かが自分の小さな世界で暮らしていることを意味するため、非常に緊張します。
クライアントがすでに機能している機能の一部のみを必要としている場合はどうなりますか？これは私に少し心配するでしょう、そして私はクライアントがなぜいくつかの機能だけを望んでいるのか彼らに尋ねたいと思います。彼らはコードの品質に神経質になっていますか？適切な機能を構築していますか？クライアントが本当に望んでいる機能に取り組んでいて、メインブランチが常にしっかりしている場合、クライアントは実装したすべてのものを熱心に入手する必要があります。したがって、この場合、私は最初にプロセスの根本的な問題を探し、それらを修正しようとします。
ただし、このリクエストに特別なブルームーンに一度の理由がある場合は、基本的に新しいトランクを作成し、いくつかのブランチを再マージし、他のパッチをチェリーピックします。または、他の投稿者が示唆しているように、一部のUIを無効にします。しかし、私はそれを習慣にしません。
これは、私がプログラム マネージャーの職に応募していたときにボーランドで尋ねられたインタビューの質問の多くを思い出させます。そこでは、質問の言い回しが異なっていました — 1 つの機能に、固定リリース日までに修正できない大きなバグがあります — しかし、同じアプローチがうまくいくと思います: 将来のリリースの機能の UI 要素を削除します.
もちろん、これは、出荷したい残りの機能で除外したい機能の影響がないことを前提としています...しかし、その場合は、UIを変更するだけで、より大幅な変更を試みるよりも簡単です.
実際には、リリースのためにコードを分岐し、その分岐で UI を削除することになると思います。
それは簡単です。
これは通常、バージョン管理の機能ですが、そのようなことを行うことは、プロジェクトのサイズと、必要または不必要に分類する必要がある変更セット/リビジョンの数によっては、非常に複雑になる可能性があります。
私が過去に採用した別の、しかしかなり成功した戦略は、機能自体を構成可能にし、未完成の機能または特定の機能をまだ使用したくないクライアントのために無効にして展開することです.
このアプローチには、マージされた機能/修正とマージされていない機能/修正を調整する必要がないという点で、いくつかの利点があります。また、構成の実装方法と、展開時に機能が終了しているかどうかによって、クライアントは次のことができます。追加機能を利用するために新しいリリースまで待つ必要はありません。