並列開発ブランチ、アーティファクトリポジトリの構築、QAリリース

Question

VCSの並列開発/分岐は、アーティファクトリポジトリの構築とQAへのリリースをどのように効果させますか？

当社では、VCSを並列開発に向けて枝分かれしており、どの支店がどのような順序で出荷されるかに関する警告はほとんどありません。

バージョン番号付けでは、ビルド元のブランチのQAを示すブランチIDを配置したいと思います。どれがそれでいないブランチ識別子と「通常の」バージョン番号を持っているでしょうトランクからのビルド：

trunk: 1.1.0 
branch: 1.1.0.MyBranch 
branch: 1.1.0.AnotherBranch 

もともと私は、分岐ごとにビルドアーティファクトリポジトリを持っていると考えられており、トランクのための1つのメインリポジトリ。

私のバージョン番号にブランチが含まれている場合、製品のバージョン番号が間違っています（ブランチからビルドおよびリリースする場合）。

これはトランクからのリリースだけですか？

また、ブランチからのビルドとは対照的に、いつQAチームビルドをトランクから出荷する必要がありますか？

私の現在のアイデアは、開発チームをリリース注文（リリースから1週間など）に割り当て、そのブランチをトランクにマージさせることです。その後、QAはブランチビルドの代わりにトランクビルドを開始し、ブランチがマージされた開発チームはブランチではなくトランクに直接バグを修正します。

* UPDATE *

具体的には、私は私のリポジトリのためにVCSのためのSVN、およびArtifactoryを使用しています。私は依存性管理のためにIvyを使用しています。

リポジトリレイアウト上のArtifactoryヘルプ（Repository Layouts）を見てみると：この

"a sequence of literals that identifies the base revision part of the artifact 
version, excluding any integration information" 
"'1.5.10', or in case of an integration revision '1.2-SNAPSHOT' the base revision 
    is '1.2'" 

とMavenとアイビーのデフォルトのレイアウトは、これはより一般的であるように私にはお勧め：

MyRepo 
MyLib 
    1.1.0 (this is the dll from trunk) 
    -MyLib.dll 
    1.1.0.MyBranch-SNAPSHOT (dev builds from the "MyBranch" branch) 
    -MyLib.dll 
    1.1.0.AnotherBranch-SNAPSHOT (dev builds from the "AnotherBranch" branch) 
    -MyLib.dll 

はこれですIvyを使うための典型的なレポのレイアウト？私はこれがアイビーのブランチ機能を使用して、ビルド時に依存関係をレポの正しいブランチフォルダに解決する必要があると思います。

* UPDATE 2 *

ここでは私の現在のArtifactory構造である：

MySnapshotRepo 
CompanyName 
    CompanyName.MyLib 
    1.0-SNAPSHOT 
    MyLib.dll (snapshot builds from the dev branch) 
MyReleaseRepo 
CompanyName 
    CompanyName.MyLib 
    1.0.0 
    MyLib.dll (release builds from the trunk) 
    1.0.1 
    MyLib.dll (release builds from the trunk) 
    1.0.2 
    MyLib.dll (release builds from the trunk) 

1. 私はビルド時に特定のレポでアイビーを指してはどうすればよいですか？リリースでは、リリース・リポジトリーからバイナリを引き出す必要があります。スナップショットのビルドについては、スナップショットリポジトリに表示されたバイナリをプルすることができます。見つからない場合は、リリースリポジトリから取得できます。私はリポジトリを連鎖させる方法を理解しています、私はちょうどそれらを切り替える方法を理解していません。

私のIvySettingsにあります。xmlファイル私は持っています：

<settings defaultResolver="defaultresolvechain"/> 

..しかし私はデフォルトしたくありません。 Ivy resolveコマンドを呼び出すときに解決するリゾルバのチェーンを指定したいと思います。次のようなもの：

これは私が解決する必要があるreposを切り替えるには間違った方法ですか？

パブリッシュタスクには、同様の方法で私にとって完璧に機能する「リゾルバ」属性があります。

また、私の特定の例では、複数のArtifactoryスナップショットreposに対応する複数のSVNブランチを持つことができます。どのリポジトリに解決するかをパラメータ化できますか？または、すべてのブランチのスナップショットを1つのリポジトリに配置し、Ivyブランチ機能を使用する方が正しい方法ですか？

他の情報が必要な場合はお知らせください。

Answer 1

リリースビルドと機能ビルドまたは開発ビルドがあります。あなたはリリースビルドをトランクから手に入れ、その機能は1.1.0の機能ブランチからビルドします。開発のためにトランクを使用しないでください。それらの機能ブランチのすべての開発を成熟させ、リリースの一部としてそれらを組み込んでトランクにマージするとします。その時点で、このコードはトランクから来たQAビルドに現れます。リリース準備が整うと、トランクから分岐し、他のフィーチャブランチで作業を続け、トランクにマージします。

QAはトランクと安定性リリースブランチからビルドを取得します。一度に1つのリリースだけを持つことで、さらに簡素化することができ、実際にリリースされた時点でトランク、支店またはタグからのQAを常に行います。これは、トランクになることは全くないが、すべてが機能ブランチになる場合に可能です。

QAに開発ビルドを渡す必要があることがあります。通常、機能ブランチをトランクにマージする前に、何も破壊していないことを確認してください。プリマージにタグを付け、機能ブランチをトランクにマージし、この場合はトランクからQAビルドを行い、重大な問題がある場合はタグに戻すことができます。これが進行している間、別の機能ブランチからのマージを防ぐことができますが、トランクへのマージが頻繁でない場合は、これが機能する可能性があります。

このようにして、トランクからのQAのセットアップを1回行うことができます。必要な作業のほとんどを管理する必要があります。