并行开发分支,构建工件存储库和QA版本

Question

VCS中的并行开发/分支如何影响构建工件存储库设置和QA的发布？

在我们公司,我们分支我们的VCS进行并行开发工作,我们通常没有太多关于哪个分支将按哪种顺序发货的警告.

对于版本编号,我想放置一个分支标识符来显示QA构建来自哪个分支.来自主干的任何构建都将具有"正常"版本号,其中没有分支标识符:

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

最初我认为每个分支都有一个构建工件存储库,以及一个主干存储库.

但是如果我的版本编号包含分支,则产品的版本号将是错误的(如果我正在构建并从分支中释放).

围绕这个的方式只能从行李箱中释放出来吗？

另外,我应该从什么时候开始发货QA团队从主干构建而不是从分支构建？

我目前的想法是说服管理层将一个开发团队分配给一个发布订单(比如发布一周后)并将他们的分支合并到主干.然后QA开始获得主干版本而不是分支构建,并且其分支已经合并的开发团队直接修复了主干中的任何错误而不是分支.

*更新*

更具体地说,我正在使用SVN for VCS,以及Artifactory用于我的存储库.我正在使用Ivy进行依赖管理.

查看存储库布局(存储库布局)上的Artifactory帮助:

"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的分支功能来解决构建时依赖于repo中正确的分支文件夹的依赖关系吗？

*更新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"/>

这是切换我需要解决的回购的错误方法吗？

发布任务有一个"解析器"属性,以类似的方式对我很有效.

此外,在我的特定示例中,我可能有多个SVN分支对应于多个Artifactory快照存储库.我可以参数化我解决哪个回购的方式吗？或者更正确的方法是将所有分支的快照放入一个仓库,并使用常春藤分支功能？

如果您需要任何其他信息以帮助,请告诉我.

Answer 1

所以你有发布版本和功能或开发版本。您将从主干获取发布版本，并从 1.1.0-feature 分支获取功能版本。根本不要使用主干进行开发。当这些功能分支成熟并且您决定将它们作为发布的一部分合并到主干时，进行所有开发。此时，此代码出现在来自主干的 QA 版本中。当您准备发布时，您从主干分支，同时继续处理其他功能分支并将它们合并到主干。

因此，QA 从主干和稳定版本分支获取构建。您可以通过一次仅发布一个版本来进一步简化，并且始终仅在实际发布时从主干和分支或标记进行 QA。如果绝对没有开发进行到主干，而是全部进行到功能分支，那么这是可能的。

有时您需要能够将开发版本传递给质量检查。通常在将功能分支合并到主干之前，只是为了确保没有破坏任何东西。在这种情况下，您可以标记预合并，将功能分支合并到主干，并从主干进行 QA 构建，如果出现严重问题，您可以恢复到标记。当这种情况发生时，它将阻止从另一个功能分支的合并，但如果向下合并到主干的情况很少，那么这可能会起作用。

这样您就可以从主干进行 QA 的单一设置，并且您应该管理大部分需要做的事情。