マルチリリース開発でのSVNの使用

Question

私のチームはSVNを使用してソース管理を管理しています。私はSVNを使う方法を改善するための方法があるかどうかを確認する作業を行っています。

私はSVNの本の多くを読んで、他の人がSVNをどのように使用しているかについて多くの研究をしました。

私はsvnの使い方の概要を説明します。うまくいけば、私にはいくつかの提案があります。

まず、1か月に2回のリリースがあります。したがって、現在はトランクをコードの実動コピーとして使用し、スケジューリングされたそれぞれの配送と各製品修正のリリースブランチを作成します。

通常、2回、時には3回の定期配送が同時に行われます。たとえば、私はリリース3をコーディングしているかもしれませんが、私または他の人がリリース2をテストしていて、リリース1の最終的なバグ修正を行っています。

今は、ブランチ（各リリース）を同期させるために多くのマージを行います。リリース3では、2と1のコードが必要ですが、リリース3の新しいコードをリリース1にすることは望ましくありません。したがって、リリース1からリリース2、およびリリース2からリリース3への一連のマージを行います。リリース3のコード作成者には定期的に繰り返す必要があり、2または1のバグ修正があります。

リリースまたは本番の修正が製品に組み込まれるたびに、コードをトランクに戻します。そして、それをトランク（または本番に移行したばかりのリリースブランチ）からすべてのアクティブなブランチにマージします。

あなたが気づいたように、私たちは多くの時間をマージします。

これは、ソースコントロールを制御する人のための多くの作業です。彼らは常にマージを行い、どのブランチがマージされているかを追跡しています。

私たちのソース管理管理システム（これは実際にはバージョン管理だけですが、ソース管理を管理するために使用しています）がSVNのように思えます。

たとえば、リリース2、リリース1、またはトランク上で何かが変更されたときに、リリース3で作業している開発者が知っていて、その開発者に自動的に通知して、彼の支店。しかし、代わりに誰かが手動ですべてのマージを行うことを知っている必要があります...人間があまりにも多くの仕事をしているように、マシンは十分に行っていないようです。

私たちがSVNの機能をより良く利用できるようにするためのアイデアを持っている人は誰ですか？私たちはこの頭痛の一部を救うことができるので、みんながいつもバージョンのコードで作業していることを確認してください！

ありがとうございます！

Answer 1

フォーラムでの質問と回答によって、現実的にこのような状況を解決できるかどうかわかりません。あなたの最善の選択肢は、私の雇用主であるCollabNetのような会社からプロフェッショナルサービスを見ることです。 Subversion Training Options

「トランク」のような名前を付けておきましょう。私はApache Subversionのコミッターの一人であり、Subversion自体のように開発を行うことをお勧めします。

1. 実質的にすべての開発は、私たちがトランクと呼ぶ単一の場所で行われますが、「開発」または「不安定」または任意の名前で呼ばれます。
2. 新しい機能に関するいくつかの作業は、トランクから作成された機能ブランチに対して行われます。これらは一般的に短命であり、開発者の裁量に委ねられます。私たちは私たちの体幹を常に安定させようとします（すべてのテストが合格します）。そのため、ブランチで最初に壊滅的な変更を試みることがあります。
3. ある時点で、私たちは、リリースを行う時点であると思っている機能をトランクが持っていると思うので、トランクをコピーしてリリースブランチを作成します。
4. リリースブランチでの開発は許可されていません。バグはトランク内で修正され、修正を含むリビジョンはバックポートと1つ以上のリリースにノミネートされます。承認された場合、承認されたリリースブランチにマージされます。
5. 時々、トランクは、修正が完全にマージされないリリースから十分に分岐しました。これが起こると、リリースブランチをコピーし、その修正をトランクからバックポートブランチにマージすることによって、バックポートブランチを作成します。これにより、開発者はブランチ上のマージ競合を適切に解決し、他の開発者は、バグをバックポートする必要があるかどうかを適切に検討し投票することができます。

このモデルは、変更が常に一方向にのみマージされるため、一部のリリースではすばやい修正を行ってから、同じ修正をトランクで行うことを忘れてしまうため、うまく機能します。したがって、このバグは次のリリースでは表示されません。

Subversionの開発はかなり線形であることを指摘します。我々は上記のように飛行中の3つのリリースはありません。一度に3つのリリースをサポートしていますが、バックポートされる修正の数は少ないです。私は、このプロセスはあなたのようにもっと流動的な環境ではうまくいくと思っていますが、サービスプロフェッショナルを雇って、それを解体しようとするほど、より密接に作業する方が良いと思います。