2

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

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

主な開発はプロジェクトのトランクにコミットされ、開発はクライアントからの変更要求（CR）に基づいて実行されます。今のところ、CRの重複（つまり、CRよりも多く変更されたファイル）の問題を除外できてうれしいです。私の問題は、単一のCRに関連するファイルの変更のみをトランクからsystestに、およびsystestから本番環境に移行するプロセスを管理する方法です。私が現在持っているプロモーションプロセスは次のとおりです（例としてsystestからprodへの移行を取り上げます）。

  1. 現在の本番ブランチに基づいてタグ「production_yyyymmdd」を作成します（これは、必要に応じて特定の「バージョン」を取得できるようにするために使用されます）
  2. 本番環境からローカルの「移行」場所（C：\ Build \ ProjectNameなど）への「更新」
  3. 選択した「マージ」が「systest」からローカルの「移行」の場所に変更されます
  4. 「コミット」が本番環境に戻る

私が抱えている問題はステップ3にあります。移行場所にマージするファイルをSVNに指示するにはどうすればよいですか。systestからprodへのすべての変更をマージしたくない（そして、systestからprodへの特定のリビジョンのすべての変更をマージしたくない場合もあります）。特定のファイルの変更のみをマージします。

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

乾杯
リチャード

4

3 に答える 3

2

これが私たちが使用するクールなライブラリ/ツールです：Savana。チケットごとに、開発者はSavanaを使用してブランチを作成し、準備ができたら、このユーザーブランチをトランクにプロモートします。同様のアプローチで、提示した問題を解決できます。特定のタスクのブランチを作成し、適切なタイミングでメイントランクパスにマージします。

于 2009-07-02T02:31:01.947 に答える
0

うわー、これは実際にはあなたがここに持っている素晴らしい正気のプロモーションシステムのように聞こえます:)

物事を追跡するという点で、私が持っている最も簡単な答えは、特定の開発者の規律を強制することです-つまり、コミットごとに1つのCRのみを含めます。

Tortoiseはbugtraqプロパティをサポートしており、すべてのコミットコメントに少なくとも1つのCR番号が含まれていることを確認することで、ここで役立ちます-コミットに1つを超える追跡番号が含まれている場合は、おそらくそれを間違ってやっている（1つの修正が実際に複数のことをしていない限り）。

したがって、これにより、必要なCRだけでトランクからシステムテストにマージできます。亀のマージUIを使用して、トランク内のどのリビジョンがまだsystemtestにマージされていないかを確認することもできます。しかしもちろん、今度は、システムテストから同様の粒度で本番環境に移行したいと思うでしょう。これが問題です。

私が見ている問題は、systemtestの1つのリビジョンが複数のトランクコミットで構成されている可能性があり、それらすべてをまだ本番環境に移行したくない場合があることです。

systemtestからではなく、トランクから本番環境にマージするのが最善ではないのではないかと思います。理論的には同じコードである必要があります。システムテストでどのトランクリビジョンがあり、本番環境で何が行われているかを追跡できます。

したがって、それを明確にするために、トランクからシステムテストへのリビジョンをプロモートし、テストしてから、問題がなければ、トランクから本番へのリビジョンをプロモートします（クリーンな本番ブランチを再度開始する必要がある場合があります）。

mergeinfoを使用して、どのリビジョンがsystemtestに含まれているか、どのリビジョンが本番環境に含まれていないかを確認するツールを作成できるはずです。また、bugtraqプロパティを使用すると、どのCRがいずれかのブランチに完全にマージされ、どのCRにまだリビジョンが残っているかを確認できるはずです。

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

ただし、これを行うと、システムテストと本番環境の間でコードがドリフトするという非常に現実的なリスクがあることに注意してください。ブランチ間で定期的に差分を取り、すべての違いを考慮できるようにすることをお勧めします。2つのブランチにトランクからマージされた同じリビジョンがある場合、それらは同一である必要があります。違いは、まだ本番環境にないテストのリビジョンによるものである必要があります。もちろん、本番環境にないリビジョンはありません。テスト中。

于 2009-07-02T07:52:37.153 に答える
0

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

一方、重要ではない問題がトランクに対して開発され、定期的なリリースにまとめられます。重要ではない各問題（あなたの場合はCR）の完了時に再リリースすることは標準的な方法ではありません。

特定のCRの完了時に再リリースしたい場合は、機能の分岐のパターンに従う必要があると思います。本番リリースを必要とするCRを受け取ったら、本番リリースブランチから機能ブランチを作成します。変更が完了したら、機能ブランチを本番ブランチとトランクにマージし、本番ブランチから解放します。

リリースサイクルを短縮することも検討してください。頻繁なリリースにより、リリースされたコードに変更を加える必要性が軽減されます。多くの場合、ビジネスは変更が実装されるまで6〜8週間待つことを許容できますが、6〜8か月は許容できません。

于 2009-07-02T03:20:09.400 に答える