開発ビルドと本番ビルドの間で分岐するソース管理の確立または定義されたベストプラクティスはありますか？
私は質問の言い回しに苦労したので、自分が何を求めているかをより明確にすることを期待して、例を挙げましょう。
私は現在、Webアプリケーションの機能の保守と追加を担当する開発チームで働いています。開発サーバーがあり、ソース管理（TFS）を使用しています。毎日全員がコードをチェックインし、（開発サーバーで実行されている）コードがQA/QCプログラムに合格すると、本番環境に移行します。
しかし、最近、プロダクションにバグがあり、すぐにプロダクション修正が必要でした。 問題は、開発者の何人かが本番環境の準備ができていないコードをチェックインしたため、コードをすばやく完了してQAするか、すべてをロールバックするか、保留中の変更を取り消す必要がありました。言葉、それは混乱でした。
これは私に不思議に思いました：防止するこのタイプのシナリオである確立された設計パターンはありますか？これに対する「教科書」の答えがあるに違いないようですが、それがどうなるかわかりません。おそらく、コードの開発ブランチと、コードの「リリース準備」または本番ブランチですか？
私の組織では、リポジトリ内の各本番デプロイメントに常にタグを付けています。私たちはSVNを使用しているため、このタグは、変更をコミットするだけで、必要に応じてブランチになります。即時修正が必要な本番環境にバグがある場合、それはまさに私たちが行うことです。そのような状況では、特定のリビジョン（製品バージョン）のクリーンコピーを開発者のワークステーションの1つにチェックアウトし、修正を行い、すべてのテストを実行し、問題がなければアプリケーションをデプロイします。次に、変更をリポジトリにコミットして、本番タグをブランチに変換します。そのコミットが最新のプロダクションタグになります。
緊急事態が解決したら、修正をメインラインにマージし、その運用ブランチを強制終了します。生産ブランチは再び通常の生産タグになります。このような緊急事態が再び発生した場合にのみ、ブランチになることができます。
TFSを使用して同じように簡単にできるかどうかはわかりませんが、ここで重要な教訓は、運用環境に展開するには安定したリビジョンが必要であることです。現在の製品リビジョンは本質的に安定しているため、緊急事態が発生したときに作業できるようにタグを付けるだけで済みます。また、ソースリポジトリのすべてのリビジョンからクリーンな作業コピーを簡単にセットアップできることも重要です。
強調すべき重要なことは、本番用の準備ができていないコードをデプロイしてはならないということです。あなたが説明したケースでは、緊急事態を引き起こした特定の問題のみを修正するために、現在本稼働中のバージョンを回避する必要があります。開発者の現在の作業コピーにあるコードは使用しないでください。
最後に、あなたの質問に答えるために、あなたが従うべきであると私が考えるべき主なソフトウェア構成パターンは、上記で説明した方法のベースですRelease Lineと呼ばれ、Stephen Berczukの素晴らしい本ソフトウェア構成管理パターン。
編集：私が今まで読んでいないコメントで同様のアプローチを述べたマルジャンヴェネマにも適切なクレジットを与える必要があります。