6

VCS での並行開発/分岐は、ビルド アーティファクト リポジトリのセットアップと QA へのリリースにどのように影響しますか?

私たちの会社では、並行開発作業のために VCS を分岐していますが、どの分岐がどの順序で出荷されるかについての警告はほとんどありません。

バージョン番号付けのために、ビルドがどのブランチから来たかを QA に示すためにブランチ識別子を配置したいと思います。トランクからのビルドには、ブランチ識別子のない「通常の」バージョン番号があります。

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

当初は、ブランチごとに 1 つのビルド アーティファクト リポジトリと、トランク用のメイン リポジトリを 1 つ持つことを考えていました。

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

これを回避する方法は、トランクからのみ解放することですか?

また、ブランチからのビルドではなく、トランクからの QA チーム ビルドの出荷をどの時点から開始する必要がありますか?

私の現在の考えは、経営陣を説得して、開発チームをリリース順序 (リリースから 1 週間後など) に割り当ててもらい、ブランチをトランクにマージすることです。その後、QA はブランチ ビルドではなくトランク ビルドの取得を開始し、ブランチがマージされた開発チームは、ブランチではなくトランクのバグを直接修正します。

* アップデート *

より具体的には、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 と Ivy のデフォルト レイアウトは、これがより一般的であることを示唆しています。

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 を使用するための典型的なリポジトリ レイアウトですか? これには、Ivy のブランチ機能を使用して、ビルド時に依存関係をレポ内の正しいブランチ フォルダーに解決する必要があると思いますか?

* 更新 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. ビルド時に Ivy を特定のリポジトリに向けるにはどうすればよいですか? リリースの場合、リリース リポジトリからバイナリをプルするだけで済みます。スナップショット ビルドの場合、バイナリがスナップショット リポジトリに表示される場合はバイナリをプルできます。バイナリが見つからない場合は、リリース リポジトリからプルできます。リポジトリをチェーンする方法は理解していますが、リポジトリを切り替える方法がわかりません。

IvySettings.xml ファイルには次のものがあります。

<settings defaultResolver="defaultresolvechain"/>

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

<ivy:resolve transitive="false" resolveMode="snapshot-resolve" conf="compile,test"/>

これは、解決する必要があるリポジトリを切り替える間違った方法ですか?

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

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

他に役立つ情報が必要な場合はお知らせください。

4

1 に答える 1

1

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

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

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

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

于 2014-11-22T00:16:13.473 に答える