小さなチームにバージョン管理分岐ポリシーを導入する

私は最近会社で始めた請負業者です。

チームは3人の開発者であり、2人の下級から中級レベルの開発者で構成されており、同じレベルの別の開発者が間もなく開始され、私（6年xp）です。両方の既存の開発者にとって、それは大学/大学からの最初の仕事であり、彼らは以前に自分の仕事を監督する上級開発者を持ったことがありません。

明示的なバージョン管理ポリシーはありません。開発者はすべての開発をトランクで行い、開発マシンから直接本番環境に展開します。既存のチームは分岐に精通していません。

これをすべて変更し、CI、TDDテスト/ステージング/プロダクションサーバーなどを導入し、これを補完するバージョン管理ポリシーを導入します。

ソース管理システムはTFSであり、これまで使用したことはありません。1つの巨大なリポジトリとして構成されています。

私はそれらのいくつかの指針を書き留めましたが、チームの経験を念頭に置いて、追加/修正する必要がある他のものはありますか？

バージョン管理ポリシー

開発はトランクで行われます

変更に1週間以上かかると推定される場合は、ブランチで行う必要があります。トランクからブランチへの定期的なマージを行い、2つの同期がとれないようにします。

本番コード用に作成されたリリースブランチ。そのブランチには、安定したコードのみが含まれている必要があります。スプリントごとに1回、トランクから更新される1つのリリースブランチを作成するか、週ごとに個別のリリースブランチを作成することができます。

本番コードに影響する緊急のバグ修正を行う必要がある場合は、リリースブランチで行われ、トランクにマージされます。

1つのリリースブランチ戦略を採用する場合、トランクはスプリントの終わりに向かってスプリントごとに1回リリースブランチにマージされます。

リリース戦略ごとに個別のブランチを採用する場合、トランクはリリースブランチにマージされません。

一部のシナリオでは、分岐が多すぎる場合、異なる分岐でバグを2回修正する必要があります。短いスプリントをしている場合、これはあまり頻繁に起こるべきではありません。

3台のサーバーを使用する予定です。リポジトリ内の最新のコードを常に実行しているテスト環境。リリース候補コードおよびUATをステージング/テストするための最新のリリース候補を実行しているステージング環境、および運用環境。

私がこれを行うことを計画している理由は、これまでクライアントは内部ソフトウェアのみを実行していたためです。最新のプロジェクトは注目度の高いメディアクライアント向けであり、私は、チームが現在行っているものよりも専門的な開発モデルを採用する必要があると感じています。

たとえば、現時点では、ユーザーはバグレポートを使用してチームに電話をかけることができます。開発者はバグを見つけて修正し、自分のマシンで簡単な目玉テストを実行してから、実稼働環境に直接展開します。自動テストなどはありません。

後知恵では、機能ブランチはあまりにも遠いステップだと思うので、削除します。

したがって、本質的には、a）まったく分岐しない）b）リリースブランチとトランク、およびc）リリースとトランクごとのリリースブランチになります。

私は後者に傾いていました。私の最初の考えは、リリース候補と別々のサーバー（UAT / Production）で同時に稼働するリリースの両方を同時に持つことですが、事実上、トランクはいつでもリリース候補であるため、リリースは非常識に傾いています。私が考えたのは、利害関係者に開発コードを見せたくない場合は、別のリリース候補ブランチが必要になるかもしれないが、YAGNIとその他すべて.....

3〜4人の開発者からなるチームの場合、非常に多くのブランチを提案することになります。

作成するすべてのブランチは、追加のオーバーヘッドであり、コスト（マージに費やした時間、場所を追跡するなど）が伴います。ブランチを持つことで得られる利益がコストを上回ることを確認する必要があります。

ブランチの唯一の本当の利点はコードの分離であることに留意してください。つまり、コードを分離したい具体的な理由が必要です。

スプリントごとに個別のリリースブランチを用意するのは非常識です。次のコードから分離された1つのスプリントのコードが必要なのはなぜですか？各スプリントで引き継がれる単一の安定したリリースブランチがあるだけではどうですか？

変更に1週間以上かかると推定される場合は、ブランチで行う必要があります。トランクからブランチへの定期的なマージを行い、2つの同期がとれないようにします。

開発、開発者テスト、毎日の中断などのアクティビティを考慮した後、ほとんどの重要な新機能は、リアルタイムで少なくとも1週間かかります。

また、「通常のマージ」とは何ですか？毎日？毎週？マージするたびに時間がかかります。変更後にターゲットマージブランチがビルドおよび実行されることを確認する必要があります。小規模なチームでは、頻繁にマージするとオーバーヘッドが大きくなります。

4人の開発者からなるチームが100万を超えるラインコードベースで作業しており、これが当社の運営方法です。

• すべての開発が行われるメインブランチ
• メジャーリリースごとに1つのブランチ（1年に1回程度）

主要なルールの1つは、ビルドしないコードをチェックインしないことです。

それでおしまい。シンプルで理解しやすいため、必要な分離が得られます（いつでも、どのバージョンのリリースビルドでも作成できます）。

1つのブランチですべての開発作業を行う利点：

1. 開発者は常に互いに同期しています。2人の開発者が、互換性のない変更を作成するために何週間も自分のブランチを離れていたため、痛みを伴うマージはありません。
2. 壊れたビルドは同じ日に見つかります。mainで最新のコードを実行するナイトリービルドがあります。何らかの理由でビルドされないコードを誰かがチェックインしても、すぐにわかります。
3. 誰もが常に同じコードで作業しているので、バグがすぐに発見される可能性が高くなります。
4. ブランチをリリースするためのターゲット修正以外のマージオーバーヘッドはありません。小さなチームでは、これが大きなチームです。

あなたはそれらのポインタをいくつか書き留めましたが、なぜ彼らがすでに使用しているアプローチよりもあなたのアプローチが優れているのかを説明していません。これには問題があるかもしれません。「私は6年間の専門的な経験があるので、自分のやり方でやる」という精神を持っているなら（そしてあなたの質問を読むと、まさにこのように見える）、嫌われる準備ができているあなたのコンセプトを適用するためにできないことは何でもしようとするあなたのチームメンバー。

解決する必要がある問題がありますか？彼らが実際に問題を抱えており、あなたの提案を歓迎するか、または彼らが現在のように完全にうまく働いているので、あなたが彼らのあなたの働き方を押しているので、最初にこの質問に答えることが重要ですこのように動作します。

最終的に、ブランチを強制的に使用すると、非常にマイナスの影響を与える可能性があります。特にアジャイル環境では、トランクの操作は簡単です。開発者はトランクに変更をコミットし、最終的に小さな競合を処理します。これらの変更は、継続的インテグレーションプラットフォームによって直ちに使用されます。分岐あり：

• 開発者は、変更がどこにあるべきかを考えなければなりません。

• 誰かがブランチを管理し、ブランチからトランクにマージする必要があります。

• ブランチ間のマージはコミットよりも少ない頻度で行われます。つまり、誰かが2つのコミット間の競合よりも大きく、処理が難しい競合に対処する必要があります。

• すべてのコミットが必ずしも継続的インテグレーションに到達するとは限らないため、開発者がコミットの影響（特にリグレッション）について取得する情報が遅れます。

事実：

既存のチームは分岐に精通していない

事態はさらに悪化します。私は経験の浅いプログラマーのチームで働いていましたが、そこでは経験の浅いマネージャーがブランチで遊ぶことにしました。これは多くの（多くの）無駄な時間をもたらし、まさに期限のあるプロジェクトでは避けたいものです。

Mainmaが言うように、分岐には注意してください。数週間ごとに分岐するということですが、本当に多くの分岐が必要ですか？

または、プッシュモデルの代わりに「プル」モデルを使用することもできます。GitまたはMercurialを使用している場合、統合サーバーに変更を検証させてから、中央サーバーにプッシュすることができます。TFSでは、ゲートチェックインを使用して同様のことができます。これにより、検証を行い、ブランチの複雑さを回避できます。