0

我的团队使用 HG 开发了三种不同的环境（每个都是自己的分支）：

  • 发布（正在运行的内容）
  • QA（我们正在测试的内容）
  • 开发（我们正在开发的）

当 QA 完成一批更改后，我们将 QA 合并到 Release 中。然后我们将 Dev 合并到 QA 中。有时，Release 中需要一个修补程序，该修补程序直接提交到 Release 中。然后将 Release 合并到 QA，将 QA 合并到 Dev。

除了一个细节之外，这个工作流程运行得非常好。我们的构建系统在每个分支上引用了不同的 Maven 依赖项。因此，例如，在 QA 中，我们的构建文件可能如下所示：

// build.gradle
apply plugin: 'java'

dependencies {
    // This dependency shouldn't ever change during a merge.
    compile 'internal.lib:lib-qa:1.0'
}

在发布时它可能看起来像这样：

// build.gradle
apply plugin: 'java'

dependencies {
    // This dependency shouldn't ever change during a merge.
    compile 'internal.lib:lib-release:1.0'
}

当我进行任何类型的合并（修补程序或正常）时，mercurial 会更改如下所示的行：

    compile 'internal.lib:lib-release:1.0'

我可以在提交合并之前手动还原此更改，但我想避免此步骤，因为我最终会忘记并破坏 Release。是否有一些练习或技巧可以使这一步变得不必要？

到目前为止，我想出的最好的方法是让我的构建检查分支，然后动态确定要使用的依赖项，但这并不令人满意，因为它使我的构建依赖于 HG（而且我在使用 Gradle Eclipse 时遇到了问题当 Gradle 需要 HG 时，插件无法正常工作）。

4

1 回答 1

1

我不太明白 Gradle Eclipse 的问题是什么，并根据查询版本控制动态选择依赖项，但我认为它应该是可以解决的。其他一些方法：

  • 编写一个仅在特定时间运行（并查询版本控制）的验证任务，例如在发布开始或完成合并之后。
  • 在构建脚本中编码分支类型（例如作为版本号的一部分）；那么您只需要在合并中正确获取一行（并且始终是同一行）。
  • 从外部注入分支类型（默认为 dev），并相应地配置 CI 构建。
于 2013-10-02T20:51:00.147 回答