6

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

在我们公司，我们对 VCS 进行分支以进行并行开发工作，而且我们通常没有太多关于哪个分支将以哪个顺序发布的警告。

对于版本编号，我想放置一个分支标识符以向 QA 显示构建来自哪个分支。来自主干的任何构建都将具有“正常”版本号，其中没有分支标识符：

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

最初我认为每个分支有一个构建工件存储库，主干有一个主存储库。

但是如果我的版本号包括分支，那么产品的版本号将是错误的（如果我正在构建并从分支发布）。

解决这个问题的方法是只从后备箱释放吗？

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

我目前的想法是说服管理层将开发团队分配到发布订单（比如发布后一周）并将他们的分支合并到主干。然后 QA 开始获取主干构建而不是分支构建，并且分支已合并的开发团队直接在主干而不是分支中修复任何错误。

* 更新 *

更具体地说，我将 SVN 用于 VCS，并将 Artifactory 用于我的存储库。我正在使用 Ivy 进行依赖管理。

查看关于 Repository Layouts ( Repository Layouts ) 的 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 的典型回购布局吗？我假设这需要使用 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 解析命令时，我想指定要解析的解析器链。像这样的东西：

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

这是切换我需要解决的存储库的错误方法吗？

发布任务有一个“解析器”属性，它以类似的方式完美地为我工作。

此外，在我的特定示例中，我可能有多个 SVN 分支对应于多个 Artifactory 快照存储库。我可以参数化我解析到哪个 repos 的方式吗？还是将所有分支的快照放入一个存储库并使用常春藤分支功能的更正确方法？

如果您需要任何其他信息来提供帮助，请告诉我。

4

1 回答 1

1

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

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

有时您需要能够将开发版本传递给 QA。通常在将功能分支合并到主干之前，只是为了确保你没有破坏任何东西。在这种情况下，您可以标记 pre-merge，将功能分支合并到主干并从主干进行 QA 构建，如果出现严重问题，您可以恢复到标记。在此过程中，它将阻止从另一个功能分支合并，但如果不经常合并到主干，这可能会起作用。

This way you can have single setup for QA from trunk and you should manage most of what you need to do.

于 2014-11-22T00:16:13.473 回答