ソース管理：役割と責任-ベストプラクティス
私は、役割と責任、特に開発ブランチからトランク（またはメイン）へのマージの責任者に関する「ベストプラクティス」を探しています。基本的に私は自分の大義を助けるための弾薬を探しています。 私が直面していることを説明させてください。私は特定のアプリケーションのリード開発者（所有者）です。私たちの会社は最近、VSS（私のアプリケーションが保存されているVSSデータベースの管理者でした）からTFS（私たちの「運用」チームによって作成された開発ブランチに対する権限しか持っていません）に移行しました。以前の仕事ではTFS管理者でしたので、TFSとMSBuildの使い方を知っています。 使用されている分岐およびマージ戦略に問題はありません（メインブランチ、必要に応じてバグ/プロジェクト開発ブランチが作成され、メインにマージされてからリリースブランチに昇格されます）。私が抱えている問題は次のとおりです。 自分でブランチを作成することはできません。「オペレーション」チームメンバーにブランチを作成させるには、TFSタスクを作成する必要があります。 Mainから開発ブランチにマージできません。「オペレーション」チームメンバーがマージを実行するようにTFSタスクを作成する必要があります。「運用担当者」は開発者である場合とそうでない場合があるため、チームが変更を「踏まない」ことを期待しています。彼がマージしているコードに関する知識はほとんどありません。 開発からMainにマージできません。繰り返しますが、 "ops guy"にマージを実行させるには、彼が正しく実行することを期待して、TFSタスクを作成する必要があります。次に、別のTFSタスクを作成してブランチにマージし、開発者以外がMainにマージすることで発生した問題を解決できるようにします。 MSBuildスクリプトを作成または編集できません。ここでも、MSBuildの新機能である「ops」チームと協力して、最も基本的なビルドタスクのみを実行できるようにする必要があります。（複雑なことは何も忘れてください、またはカスタムタスクを天国で禁止してください）。 MSBuildスクリプトを実行できません。繰り返しますが、「ops」チームだけがこれを行うことができます。 このすべてをオフにするには、通常、要求されたタスクを実行する「オフショア」リソースであるため、早朝に（ブランチ/マージ/ビルド）へのタスクを作成しても、完了しない可能性があります。その夜まで。 これで、リリースブランチを維持する「運用」チームに問題はありません。彼らがしていることはすべて、（基本的に）Mainから最新バージョンを取得し、それをリリースブランチにプロモートすることです。"Main"が安定していて準備ができている限り、リリースブランチは適切です。 私の意見では、テクニカルリード（Iなど）は、トランク（「メイン」）の保守と、開発ブランチとの間のマージを担当する必要があります。チームリーダーには、MSビルドスクリプトを生成して、統合テスト環境にビルドおよびデプロイする機能も必要です。 私のケースを証明するのに役立つベストプラクティスドキュメントを誰かに教えてもらえますか？私が行ったすべての検索で、分岐とマージの手法に関するベストプラクティスのみが判明しました。WHOについての言及では、分岐/マージを実行すべきではありません。