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帮助(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的分支功能来解决构建时依赖于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)
在我的IvySettings.xml文件中,我有:
<settings defaultResolver="defaultresolvechain"/>
..但我不想要默认。当我调用Ivy resolve命令时,我想指定要解析的解析器链。像这样:
<ivy:resolve transitive="false" resolveMode="snapshot-resolve" conf="compile,test"/>
这是否是错误的方式来切换我需要解决的回购?
发布任务有一个“解析器”属性,以类似的方式对我很有效。
此外,在我的特定示例中,我可能有多个SVN分支对应于多个Artifactory快照存储库。我可以参数化我解决哪个回购的方式吗?或者更正确的方法是将所有分支的快照放入一个仓库,并使用常春藤分支功能?
如果您需要任何其他信息可以提供帮助,请与我们联系。
答案 0 :(得分:1)
所以你有发布版本和功能或开发版本。您将从trunk获取发布版本,并从1.1.0-features分支构建功能。根本不要使用行李箱进行开发。对这些功能分支进行所有开发,当它们成熟并且您决定将它们作为发布的一部分包含在它们中时将它们合并到主干。此时此代码出现在来自主干的QA版本中。当您准备发布时,您将从主干分支,同时继续处理其他功能分支并将它们合并到主干。
因此QA从trunk和稳定版本分支获得构建。您可以通过一次只有一个版本进行进一步简化,并且只在实际发布时仅从主干和分支或标记执行QA。如果绝对没有开发进入主干,那么这将是可能的,但所有功能都可以用于功能分支。
有时您需要能够将开发构建传递给QA。通常在将功能分支合并到主干之前,只是为了确保您没有破坏任何东西。您可以标记预合并,将功能分支合并到主干,并在这种情况下从主干执行QA构建,如果存在严重问题,您可以恢复到标记。它会阻止来自另一个功能分支的合并,而这种情况正在发生,但如果合并到主干很少,这可能会有效。
通过这种方式,您可以从主干中进行单一QA设置,您应该管理大部分需要做的事情。