-1

現在、次のようなプロジェクトの簡単なリリース計画に従っています。

  1. 開発者は、subversion リポジトリに変更をコミットしました。
  2. QA サーバーへの変更をビルドします。
  3. 本番サーバーへの変更をビルドします。

問題は、これらすべてのステップで SVN トランクに設定された 1 つのソース コードを使用することです。

したがって、QA サーバーのリリースを制御することはできません (例: いくつかの要件を回避する)。

QA サーバーに 5 ～ 6 回リリースしなければならない日もあるため、非常に複雑なリリースの発生があります。

Subversion ブランチを使用すると、この問題を克服できると思います。QA/ライブ サーバー リリース用に別のブランチを作成し、必要な変更をヘッド/トランクからマージできることを願っています。

それとも、これは逆ですか？QA/ライブ サーバー リリース用にヘッド/トランク バージョンを保持し、開発コミット用のブランチを作成します。

正しい方法は何ですか？

この状況を処理するためのより良い方法/ツールがあるかどうか教えてください。

ありがとう。

4

2 に答える 2

1

SVN のブランチに対する非常に一般的なアプローチがあります。ここで説明されています：http://svnbook.red-bean.com/en/1.7/svn.branchmerge.commonpatterns.html

私のプロジェクト (個別のリリース サイクルを持つ 1 人プロジェクト) では、リリース ブランチと機能ブランチの両方を使用していますが、問題はありません。

正確なブランチ ポリシーは異なる場合があります。

  • トランク (1 つだけ): すべての自動テストに合格し、完成した機能とバグ修正のみが含まれます
  • 機能ブランチ (通常は複数): 単一の機能またはバグ修正専用で、通常はビルドされ、自動テストは通常​​パスし、完了後にトランクに再統合されて削除されます
  • 安定化ブランチ (複数の場合もありますが、通常は 1 つ): 計画されたリリース専用、自動テスト パス、QA に送信するビルドの生成に使用、そこから内部/外部リリース タグが作成され、いくつかの修正または機能がマージされる場合もありますこちらトランクから
于 2013-02-12T20:24:58.640 に答える
-1

正しい方法は何ですか？

意見ですが、トランクを3本作成。1 つは開発用、1 つは QA 用、もう 1 つは生産用です。

開発ブランチは、プロジェクトをフォークする場合にのみ必要です。

QA トランクは、統合テスト用のトランクを維持しながら、単体テスト用に分岐できます。

本番トランクは分岐することはありませんが、本番リリースごとにタグ付けされます。誰かが問題を修正する必要がある場合、コードはチェックアウトではなくエクスポートされます。変更は開発トランクに適用されます。

  • 開発コードを確認する
  • 実動修正の変更を適用する
  • 開発コードをコミットします。

開発トランクから QA トランクにコードを移動する人員とプロセス、および QA トランクから実稼働トランクにコードを移動する人員とプロセスが必要です。

于 2013-02-12T19:34:02.257 に答える