製品のバージョン管理と長期プロジェクトの分岐を処理する最良の方法は何ですか？

一般的に、製品ライフサイクル中に複数のリリースがあり、以前の製品のサポートが必要な長期プロジェクトの場合、製品バージョンとコードベースの分岐を処理する最良の方法は何ですか？

より具体的な意味では、適切な分散バージョン管理（例：git）があり、チームの規模は小規模から大規模であり、開発者は一度に複数のプロジェクトに取り組んでいると想定します。直面している主要な問題は、その時点で存在していた古いバージョンをサポートする契約上の義務があることです。つまり、新しい開発では古いコードにパッチを適用できません（Microsoft Office製品がその例です。所有している機能年）。

その結果、各主要製品には複数の依存関係があり、それぞれのバージョンは年間リリース間で変更される可能性があるため、現在の製品のバージョン管理は複雑です。同様に、各製品には独自のリポジトリがありますが、ほとんどの作業はメインソーストランクではなく、その年の製品リリースのブランチで行われ、製品がサポートされるように製品がリリースされるときに新しいブランチが作成されます。これは、バージョン管理を使用するときに考えられるように、製品のコードベースを取得することは単純な問題ではないことを意味します。

必要な構造（および種類）は、何ができるようになるかに大きく依存します。なしでは生きていけないもの、持ちたいもの、気にしないものを見つけてください。

決定の良い例のセットは次のとおりです。

なしでは生きていけないもの：

• 過去のリリースをいつでも再構築できる
• 製品の複数のサポートされているメジャーバージョンをいつでも維持できる

欲しいもの：

• ブランチのマージを心配することなく、進行中の主要機能開発（次のメジャーリリース用）を実行できる
• 過去のリリースのメンテナンスアップデートを実行できる

なしで生活できるもの：

• 現在の作業から過去のリリースへの変更の自動バックポート
• 数日または1週間でも主要な機能の開発を中断しない

上記が目標であれば、次のようなプロセスを採用できます。

1. すべての開発作業をVCSのトランク（gitの「マスター」）で行います。
2. メジャーリリースに近づいたら、主要な機能の開発を停止し、1週間ほどシステムの安定性に集中します
3. トランクが安定しているように思えたら、このメジャーリリースのブランチを作成します
4. 主要な機能開発はトランクで進行できるようになりましたが、ブランチではバグ修正とリリース準備のみが許可されます
5. ただし、ブランチに対して行われるすべてのバグ修正は、最初にトランクでテストする必要があります。これにより、将来のすべてのリリースにも存在することが保証されます
6. リリースする準備ができたら、ブランチに（VCS）タグを作成します。このタグは、同じブランチでさらに作業を行った後でも、いつでもリリースを再作成するために使用できます
7. このメジャーリリース（マイナーリリース）のメンテナンスリリースをブランチで準備できるようになりました。それぞれがリリース前にタグ付けされます
8. それまでの間、次のメジャーリリースに向けた主要機能の開発はトランク上で継続できます。
9. そのリリースに近づいたら、上記の手順を繰り返して、そのリリースの新しいリリースブランチを作成します。これにより、それぞれが独自のブランチにある複数のメジャーリリースを同時にサポート状態にして、それぞれに対して個別のマイナーリリースをリリースすることができます。

このプロセスでは、すべての質問に答えることはできません。特に、リリースブランチに対して行うことができる修正を決定し、最初にリリースブランチでバグが修正されないようにするためのプロセスが必要になります。可能な場合は常にトランクでテストする必要があります）。しかし、それはあなたにそのような決定を下すための枠組みを与えるでしょう。

「長期」は、バージョン管理が必要であることを示す指標ですが、特定のバージョン管理および分岐戦略を意味するものではありません。さらに興味深い質問は、サポートする製品ラインまたはメジャーバージョンラインの数です（顧客との契約に依存します）。メンテナンス契約を結んでいる製品ライン/メジャーバージョンラインごとに、少なくとも1つのブランチが必要です。

一方、チームの規模によって異なります。大きな開発チームがあり、さまざまな人がさまざまな機能を並行して作業している場合、1人または2人のチームがある場合よりも明らかに多くの機能ブランチが必要になります。より大きなチームで作業している場合は、分散バージョン管理の使用を検討する必要があります。これにより、異なるブランチでの並列作業（およびトランクへの再統合）がより効率的になります。

Gitはバージョン管理ツールです-ファイルのバージョンを管理します。後は構成管理ツールです。これらは十分にありますが、ほとんどがIBMのようなものからの高い$$$です。

バージョン管理ツールは分岐とタグ付けを提供します。これにより、追加のツールサポートなしで無作法な構成管理が可能になるため、開発者は違いを理解できません。あなたのニーズはおそらくGITの目的を超えています。

私はGitのCMツール追加については知りませんが、存在することは確かです。

この質問は非常に似ているように思える別の質問私がいることを答えた最近。

要するに、これはバージョン管理/分岐の問題というよりも、製品の設計と配布の問題のように聞こえます。もちろん、私がそれを言うのは簡単ですし、あなたがすでに問題に深く関わっているなら、あなたが修正するのは難しいです。

特定の問題の詳細を詳しく知ることなく。ただし、一般的に、製品間で大量の共有コードを使用するコードベースに基づいて複数のバージョンの製品がある場合、可能であれば、よりモジュール化された方法で製品をリファクタリングすることを検討します。モジュール自体が追加のコード分岐を必要としないことを確認してください。また、多くのコードベースを統一したまま、顧客をサポートするより良い方法があるかどうかを確認するために、展開モデルも調べます。特定の顧客のカスタマイズが必要な場合は、システム内の重複コードの量を減らすために、モジュールのより高い粒度が必要になる場合があります。

簡単な作業ではありませんが、仕事をうまく管理し、すべてを一度に「アップグレード」する必要がないように作業をスケジュールできる場合、段階的に修正できます。