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

Question

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

私が直面していることを説明させてください。私は特定のアプリケーションの主要開発者（所有者）です。私たちの会社は最近、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についての言及では、分岐/マージを実行すべきではありません。

Wyatt Barnett · Answer

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

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

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

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

お役に立てれば。

Jan Hudec · Answer

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

誰もが自分の心の中に仕事の枝を作成することができます。開発者は、進行中の現在の作業を保存することに意味があるとわかったときに、機能ブランチを作成できる必要があります。彼らは一日の終わりにそれを望んでいる/すべきであるので、それを別のチームメンバーと共有したいので、メインまたは何かの変更から保護する必要があります。
誰でも開発ブランチに対して絶対に何でもできます。開発者は、必要なものがmainに統合されたことを別の開発者が告げるとすぐにmainからマージできる必要があります。
メインへのマージ（統合）には、3つのオプションがあります。
- 開発者は自分でこれを行います。彼らは主な開発者とリスクについて話し合い、機能を適切にテストするだけです。これは、誰もが権限を持っていることを意味します。誰かがルールを破った場合、彼らはただ叱られ、間違った変更は元に戻されます。
- 別の開発者が変更を確認した後でそれを行います。それでも、誰もがそれを実行する権限を持っている必要があります。ルールは依然としてリード開発者によって実施されています。
- レビューしてメインにマージする指定インテグレーターがいます。ただし、インテグレーターはチームの一部であり、コードを理解する必要があります。小さなチームでは建築家と同じ人物で、大きなチームでは別々になりますが、緊密に協力する必要があります。
機能を準備する人は誰でもビルドスクリプトを適応させる必要があります。しかし、それがTFSでどのように機能するかはわかりません。私が使用したシステムでは、ビルドスクリプトは常にバージョン管理されたファイルでした。そのため、開発者は他のファイルと同じように編集し、他のすべてと統合しました。
指定されたインテグレーターがいる場合は、通常、（実行するスクリプト）の定義とビルドの開始を担当します。それ以外の場合は、チームリーダーがそれを行うか、指定されたチームメンバーがそれを行うか、誰かが権限を持ち、チームリーダーが特定のビルドのセットアップと開始をケースバイケースで委任します。
上記の操作でチーム外のオペレーターが必要になることはありません。オペレーターは、権限の設定、レプリカの作成などにのみ必要です。

Murph · Answer

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

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

ベストプラクティスドキュメントを振り回すことは（しかしmightのみ）、それらを説得しようとする試みの助けになるかもしれませんが、開発チームのメンバーが自分の手に座っている必要があるという概念ははるかに優れていますプロセスが改善/合理化されていない限り、別のタイムゾーンの誰かが行動するのを待つ。

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