ソース管理：役割と責任-ベストプラクティス

私は、役割と責任、特に開発ブランチからトランク（またはメイン）へのマージの責任者に関する「ベストプラクティス」を探しています。基本的に私は自分の大義を助けるための弾薬を探しています。

私が直面していることを説明させてください。私は特定のアプリケーションのリード開発者（所有者）です。私たちの会社は最近、VSS（私のアプリケーションが保存されているVSSデータベースの管理者でした）からTFS（私たちの「運用」チームによって作成された開発ブランチに対する権限しか持っていません）に移行しました。以前の仕事ではTFS管理者でしたので、TFSとMSBuildの使い方を知っています。

使用されている分岐およびマージ戦略に問題はありません（メインブランチ、必要に応じてバグ/プロジェクト開発ブランチが作成され、メインにマージされてからリリースブランチに昇格されます）。私が抱えている問題は次のとおりです。

1. 自分でブランチを作成することはできません。「オペレーション」チームメンバーにブランチを作成させるには、TFSタスクを作成する必要があります。

2. Mainから開発ブランチにマージできません。「オペレーション」チームメンバーがマージを実行するようにTFSタスクを作成する必要があります。「運用担当者」は開発者である場合とそうでない場合があるため、チームが変更を「踏まない」ことを期待しています。彼がマージしているコードに関する知識はほとんどありません。

3. 開発からMainにマージできません。繰り返しますが、 "ops guy"にマージを実行させるには、彼が正しく実行することを期待して、TFSタスクを作成する必要があります。次に、別のTFSタスクを作成してブランチにマージし、開発者以外がMainにマージすることで発生した問題を解決できるようにします。

4. MSBuildスクリプトを作成または編集できません。ここでも、MSBuildの新機能である「ops」チームと協力して、最も基本的なビルドタスクのみを実行できるようにする必要があります。（複雑なことは何も忘れてください、またはカスタムタスクを天国で禁止してください）。

5. MSBuildスクリプトを実行できません。繰り返しますが、「ops」チームだけがこれを行うことができます。

6. このすべてをオフにするには、通常、要求されたタスクを実行する「オフショア」リソースであるため、早朝に（ブランチ/マージ/ビルド）へのタスクを作成しても、完了しない可能性があります。その夜まで。

これで、リリースブランチを維持する「運用」チームに問題はありません。彼らがしていることはすべて、（基本的に）Mainから最新バージョンを取得し、それをリリースブランチにプロモートすることです。"Main"が安定していて準備ができている限り、リリースブランチは適切です。

私の意見では、テクニカルリード（Iなど）は、トランク（「メイン」）の保守と、開発ブランチとの間のマージを担当する必要があります。チームリーダーには、MSビルドスクリプトを生成して、統合テスト環境にビルドおよびデプロイする機能も必要です。

私のケースを証明するのに役立つベストプラクティスドキュメントを誰かに教えてもらえますか？私が行ったすべての検索で、分岐とマージの手法に関するベストプラクティスのみが判明しました。WHOについての言及では、分岐/マージを実行すべきではありません。

ベストプラクティスについての私の一般的な見方は、開発チームのメンバーはツリーで任意のアクションを実行できるはずであり、それらのアクションは本番環境のデプロイメントを開始するようなものではないと想定しています。特定のブランチ/タグ/リポジトリが、自動デプロイメントのソースとして機能し、合理的な変更管理やエントリへの障壁を設けることが理にかなっている場合、管理ミスのような見方よりも、間違いを犯すという見方よりも、間違いを犯すだけの方が重要です。開発者にブランチを作成してビルドスクリプトを改善することをお勧めします。必要に応じて、開発者が本番環境にアクセスできるようにする方法を見つけます。ソース管理の要点の1つは、それが間違いの効果的な魔法の消しゴムであることです。あなたがする必要がある最悪のことは、1つまたは2つの回転をロールバックし、それから分岐することです。

残念ながら、これは彼らがここで取ったアプローチのようには聞こえません。これを克服するには、いくつかの角度をカバーする必要があると思います。

a）これらのポリシーが開発に有害であることを証明します。何かに取り掛かるためにオペレーションを待つのに費やしたすべての時間を記録します。これだけでは、なぜこれが悪い政策なのかについての合理的な管理を売り込むはずです。

b）Opsで友達を作る-このポリシーには理由があるかもしれません。おそらく、その推論はより効果的な方法で対処できるでしょう。

お役に立てれば。

私が見た習慣は次のとおりです。

1. 誰もが自分の心に合わせて作業ブランチを作成できます。開発者は、進行中の現在の作業を保存することに意味があるとわかったときに、すぐに機能ブランチを作成できなければなりません。彼らは一日の終わりにそれを望んでいる/すべきであるので、それを別のチームメンバーと共有したいので、メインまたはその他の変更から保護する必要があります。

2. 誰もが開発ブランチに対して絶対に何でもできる。開発者は、必要なものがmainに統合されたことを別の開発者が告げるとすぐにmainからマージできる必要があります。

3. メインへのマージ（統合）には、3つのオプションがあります。

   • 開発者は自分でこれを行います。彼らは主な開発者とリスクについて話し合い、機能を適切にテストするだけです。これは、誰もが権限を持っていることを意味します。誰かがルールを破った場合、彼らはただ叱られ、間違った変更は元に戻されます。
   • 別の開発者が変更を確認した後でそれを行います。それでも、誰もがそれを行うための権限を持っている必要があります。ルールは依然として主要開発者によって実施されています。
   • レビューしてメインにマージする指定インテグレーターがいます。ただし、インテグレーターはチームの一部であり、コードを理解する必要があります。小さなチームでは建築家と同じ人物で、大きなチームでは別々になりますが、緊密に協力する必要があります。

4. 機能を準備する人は誰でもビルドスクリプトを調整する必要があります。しかし、TFSでどのように機能するかはわかりません。私が使用したシステムでは、ビルドスクリプトは常にバージョン管理されたファイルだったので、開発者は他のファイルと同じように編集し、他のすべてと統合しました。

5. 指定されたインテグレーターがいる場合は、通常、（実行するスクリプト）の定義とビルドの開始を担当します。それ以外の場合は、チームリーダーがそれを行うか、指定されたチームメンバーがそれを行うか、誰かが権限を持ち、チームリーダーが特定のビルドのセットアップと開始をケースバイケースで委任します。

6. 上記の操作でチーム外のオペレーターが必要になることはありません。オペレーターは、権限の設定、レプリカの作成などにのみ必要です。

「ベストプラクティス」を気にしないでください（私と一緒に考えてください）。これは管理上の問題です。基本的に、あなたに課せられた制約のために、適切に仕事をすることができません。

実際には「ベストプラクティス」が何であるかは問題ではありません。これは、あなたとあなたのチームの生産性に影響を与える単純で実証可能な問題であり、それに基づいてライン管理でそれを取り上げる必要があります。

ベストプラクティスドキュメントを振り回すことは、それらを説得しようとする試みの助けになるかもしれませんが、異なるタイムゾーンで誰かを待っている間、開発チームのメンバーが彼らの手に座らなければならないという概念ははるかに良いことがわかりますプロセスが改善/合理化されない限り、彼らの行動を一緒にするため。

そして、あまりにも対立しないでください-制限が設定されている理由を知りたいのと同じくらい、正当化は...