テストとプロダクションへの変更を促進するSVN

Question

私はDot Netプロジェクトの開発を追跡するためにSVNリポジトリを実装しています。私は、次の構造に従って、リポジトリのディレクトリを定義しています

\project 
    \trunk 
    \branches 
     \systest 
     \production 
    \tags 
     \production_yyyymmdd 

主な開発プロジェクトのトランクにコミットされ、開発がクライアントからの変更要求（CRS）に基づいて行われます。現時点では、重複しているCR（CR以上に変更されたファイル）の問題を除外してうれしく思います。私の問題は、単一のCRに関連するファイル変更だけをトランクからsystestに、systestからproductionに移行するプロセスを管理する方法です。プロモーション・プロセスが、私は、現時点ではそれを持っているようである（例としてprodにSYSTESTから移行取る）：

1. は、現在の生産ブランチに基づいてタグ「production_yyyymmdd」を作成します（これは、特定の検索可能にするために使用されます地元の「移行」の場所への生産からあなたが好きならば「バージョン」）
2. 「更新」（例：C：\ \プロジェクト名をビルドする）
3. 地元の「移行」を「SYSTEST」から選択変化を「マージ」場所
4. "コミット"が変更に戻る

私が持っている問題は手順3です。どのファイルをどのファイルを移行場所にマージするように指示しますか？私はではないすべての変更をsystestからprodへマージしたい（そして、特定のリビジョンのすべての変更をsystestからprodにマージしたくないかもしれない）、特定のファイルの変更のみ。

編集：すべてのリポジトリへのアクセスがWindowsクライアントから行われていることを明確にする必要があります。私はSVNサーバー上でコマンドを実行していません。 （興味のために、SVNサーバーは、Linux上で実行されているが、それは、私は信じている問題空間に違いはありません）

乾杯
リチャード

Answer 1

うわー、これは実際にあなたがここに持っている素敵なまともな推進体制:)追跡物事の面では

は、私が持っている最も簡単な答えは、特定の開発者の規律を強化することであるように聞こえます1コミットにつき1 CR。

Tortoiseは、すべてのコミットコメントに少なくとも1つのCR番号が含まれていることを確認することでここにお役立ていただけます。おそらくそれを間違っている（ある修正が本当に複数のことをしない限り）。

これにより、あなたが望むCRだけでトランクからsystemtestにマージさせることができます。亀のマージを使用して、システムテストにマージされていないトランクのリビジョンを確認することもできます。もちろん、システムステージからプロダクションに至るまで同様の粒度で作業したいと思っています。これが質問の内容です。

私が見ている問題は、systemtestの1つのリビジョンが複数のトランクコミットで構成されている可能性があることです。

私は、systemtestからではなく、トランクからの生産に併合するのが最善でないかもしれないのだろうかと思います。理論的には同じコードでなければなりません。システムテストでのトランクリビジョンと生産中のものを追跡できます。

これで明らかになるように、トランクからsystemtestへのリビジョンをテストし、テストしてからOKになったら、リビジョンをプロダクションにプロモートします（クリーンプロダクションブランチをもう一度開始する必要があるかもしれません）。

mergeinfoを使用して、どのリビジョンがsystemtestにあるのかを確認するツールを書くことができるはずです。また、bugtraqプロパティを使用して、どのCRがどちらのブランチに完全にマージされているのか、まだリビジョンがあるのか​​を知ることができます。

テストとプロダクションに完全なトランクコミットよりも少ないコストでプロモートを開始したい場合は、特に同じファイルから変更を選ぶ場合には少し問題があります。個々のファイルを右クリックしてファイルレベルで直接マージすることもできます（手動で特定の変更を元に戻すこともできます）。しかし、ファイルや変更を選択することは非常に手作業であり、ツールから助けを得ることはありません。また、追跡スクリプトは非常に複雑なものになり始めます。

しかし、このようにすると、システムテストと生産の間でコードドリフトが発生する危険性が非常に高くなることに注意してください。私は定期的にブランチ間の差分を行い、すべての相違点を説明できるようにすることをお勧めします。 2つのブランチにトランクからマージされた同じリビジョンがあれば、それらは同一でなければなりません。テスト中のリビジョンがまだ生産されていないために違いがあります。もちろん、テスト中。

Answer 2

ここで私たちが使用するクールなライブラリ/ツールです：Savana。各チケットについて、開発者はSavanaを使用してブランチを作成し、準備ができたらこのユーザーブランチをトランクに戻します。同様の方法で、問題を解決することもできます。つまり、任意のタスクのブランチを作成し、時間が合ったときにメインのトランクパスにマージします。

Answer 3

「通常の」プロセス（つまり私のショップが従うプロセス）は、製品のリリースごとにリリースブランチとタグコピーを作成することです。プロダクションで発生する重大な問題は、プロダクションブランチで修正され、トランクに再度マージされ、製品が再リリースされ、新しいタグコピーが作成されます。

一方、重要でない問題はトランクに対して開発され、定期的なリリースにロールアップされます。クリティカルではない問題（あなたのケースではCR）の完了時に再リリースすることは、標準的な習慣ではありません。

特定のCRの完了時に再リリースしたい場合は、機能分岐のパターンに従うべきだと思います。プロダクションリリースが必要なCRを受け取ったら、プロダクションリリースブランチからフィーチャーブランチを作成します。変更が完了したら、機能ブランチを本番ブランチとトランクにマージし、本番ブランチからリリースします。

リリースサイクルを短縮することを検討することもできます。頻繁にリリースされると、リリースされたコードを変更する必要性が軽減されます。ビジネスは、6〜8週間ではなく、6〜8週間ではなく、変更が実施されるのを待つことができます。つまり、のみ含める -