5

VCS中的并行开发/分支如何影响构建工件库设置并发布到QA?并行开发分支,构建Artifact存储库和QA版本

在我们公司,我们分支我们的VCS进行并行开发,并且我们通常没有太多警告哪个分支将以何种顺序发货。

对于版本编号,我想放置一个分支标识符来显示QA构建来自哪个分支。任何从树干建立将有它无分支标识符的“正常”的版本号:

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

原本我以为有每个分支一个生成神器库,并为主干一个主存储库。

但是,如果我的版本编号包含分支,那么产品的版本号将是错误的(如果我正在从分支构建和释放)。

解决此问题的方法是仅从主干中释放?

此外,我应该在什么时间开始发货,而不是从分行建立QA团队?

我目前的想法是说服管理层将一个开发团队分配到一个发布命令(比如发布一周的时间)并将他们的分支合并到主干。然后QA开始获取主干构建而不是分支构建,并且已合并分支的开发团队将任何错误直接固定在主干中,而不是分支中。

* UPDATE *

更具体地说,我使用SVN的VCS和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的分支功能来解决构建时的依赖关系到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. 我怎么一点在常春藤在构建时特定回购?对于发行版,我只需要从发行版回购中提取二进制文件。对于快照构建,如果它们出现在快照回购中,我可以将二进制文件拉出来,如果它们丢失了,我可以将它们从发布回购中提取出来。我知道如何链接库,我只是不明白如何切换它们。

在我的IvySettings。xml文件我有:

<settings defaultResolver="defaultresolvechain"/> 

..但我不想缺省。我想指定当我调用Ivy解析命令时解析器的哪个链。这样的事情:

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

这是错误的方式来切换我需要解决的回购协议?

发布任务有一个“解析器”属性,它以类似的方式完美地适用于我。

此外,在我的具体示例中,我可能有多个SVN分支对应多个Artifactory快照回购。我可以参数化我解决哪种回购方式的方式吗?或者是将所有分支的快照放到一个回购中并使用常春藤分支功能的更正确方法?

请让我知道,如果你需要任何其他信息来协助。

回答

0

所以你有发布构建和功能或开发构建。您将从中继获得您的发布版本,并从1.1.0功能分支构建功能。根本不要使用干线进行开发。对这些功能分支进行所有的开发,当它们成熟时,你决定将它们包含在发行版中,将它们合并到主干中。此时此代码出现在来自主干的QA构建中。当你准备发布时,你从树干分支,而你继续在其他功能分支上工作并将它们合并到树干。

所以QA从中继和稳定版本分支获取构建。通过一次只有一个版本,您可以进一步简化,并且只在实际版本发布时从总部和分支或标签始终进行QA。如果绝对没有发展到干线,这将是可能的,但所有的功能分支。

有时您需要能够将开发版本传递给QA。通常在将特性分支合并到主干之前,只要确保你没有破坏任何东西。您可以标记预先合并,合并功能分支到主干,并在此情况下从主干执行QA构建,如果存在严重问题,则可以恢复到标记。它会阻止另一个功能分支的合并,但是如果合并到主干不经常发生,这可能会起作用。

通过这种方式,您可以从中继进行QA的单一设置,并且您应该管理大部分需要执行的操作。

相关问题