3

私たちは展開されたシステムで開発しているので、分岐をより有効に活用しようとしています。最近まで、ほぼすべてがトランクにチェックインされ、テスト/ステージングに展開され、次に本番環境に展開されていました。これは、"テスト" 期間中は細心の注意を払う必要があることを意味します。ほとんどテストを行わないまま、不要な変更がサーバーに送信されることがあります。

私の考えでは、「マイナー」パッチはトランクに直行し、主要な機能は機能ブランチになり、完了時にトランクに再統合され、直前にマージできるサーバーの状態に常に一致する「プロダクション」ブランチになるというのが最善の方法です。展開中。

ここで提供される主な利点は、本番環境にロールアウトする変更を選択できることです。必要に応じて、単一のチェックインまたはブランチを取得して、他のすべてのブランチを関与させることなく本番環境に送信できます。

一方、ブランチをトランクと頻繁に統合するのが最善のようです-変更が蓄積されないようにプルアップして、厄介なマージを行います。

したがって、これらの 2 つのパターンは、重要な機能を持ち込むためにブランチを Production とマージしたいが、そのブランチは、出荷したくないトランクからの変更を既に "プル" しているというケースにつながる可能性があります。

SVNはこれを処理できますか? 数週間ごとにデプロイされるコードを開発しているグループに有効な、本当に優れたプラクティスはありますか?

4

1 に答える 1

2

あなたが説明したことはすべて、Subversion (の 1.7 または 1.8 のような現在のバージョン) で可能だと思います。実行する手順は次のとおりです。

  1. 分岐 (およびマージ) 戦略について説明してください。それらすべてを簡単に混在させることはできず、開発者がどの戦略がどこで使用されているかを知ることは困難であるため、ここでは文書化とコミュニケーションが重要です。次のリソースを参照してください。
  2. 以下を使用します。
    • 本番リリースのリリース ブランチ。パッチはそこで直接開発されます。パッチごとに、次のリリースでそのパッチを (同じ形式で) 利用可能にするかどうかを決定する必要があります。
    • メインの開発にはトランクを使用します。次のリリースに含まれると確信しているものはすべて、トランク上で開発する必要があります。トランクから (リリース) ブランチにマージしないでください。決して！
    • 機能が次のリリースに含まれるかどうかが不明な場合にのみ、機能ブランチを使用してください。機能ブランチは (Subversion では) Git などよりもはるかに難しいため、それらを使用する理由があるはずです。トランクから機能ブランチへのすべての変更を定期的にマージし、機能がトランクに統合されたときにのみ再統合します (次のリリースにするため)。
  3. 分岐とマージを行う適切な時点を見つけます。
    • 分岐: いつ安定リリース ブランチが必要になるか (次のリリースへの統合のため)、次のリリースの開発を開始できるのはいつですか (その後再びトランクで)。
    • マージ: 変更をマージするのに最適な時期はいつですか: 即時、変更が新鮮なとき。時々定期的に; （うまくいけばそうではありません）最後に一度だけ。

ブランチは、次のように時間の経過とともに開発されます。

  1. 最初のリリースであるリリース 1.0 のトランク (およびトランクのみ) から始めます。
  2. リリース 1.0 の統合テストを行いたい場合はトランクを分岐し、(トランク上で) リリース 1.1 の開発を開始します。
  3. リリース 1.0 を配信し、その後ブランチから直接パッチを提供します。
  4. リリース 1.1 の統合テストを行う場合はトランクを分岐し、トランクでリリース 1.2 (または 2.0) の開発を開始します。
  5. ... 等々 ...

Branching and Merging of the SVN Red Book では、技術的に必要なことはすべて説明されていますが、さまざまなビジネス コンテキストでそれを行う方法が明確ではありません (個人的な意見です)。すべてのオプションとその背後にあるドライバーを十分に詳細に説明しているリソースが見つかりません...

于 2013-09-07T09:30:18.733 に答える