如何管理源代码存储库以进行计划发布,开发和研究

时间:2015-04-16 19:13:18

标签: mercurial release-management

我们有Mercurial版本控制系统,我们在管理强制功能,可选功能和研究的发布方面遇到了困难。我们有两个独立的存储库,一个用于发布,一个用于开发。

我们每个季度都安排了部署。因此,我们开发了三个月的功能(强制和可选),测试人员测试Dev站点上的功能(持续构建)。

在发布周期结束时,我们必须从开发回购中获取强制和可选功能(仅限QA)并手动将它们复制到发行版回购中。我们无法将开发存储库合并到发行版中,并且必须手动复制文件,因为在发布时,开发存储库中可能存在未经测试/未开发的功能/代码。然后,我们从发布存储库构建测试站点,让测试人员在那里进行全面测试。如果发现任何问题,则首先在发布回购中修复这些问题,然后将发布回购合并到开发回购中。

但是,由于手动合并,有可能将不需要的更改/文件复制到发布回购中并导致问题。

有人可以建议如何使用Mercurial摆脱这个手动复制粘贴?我确信这是开发公司的标准流程,应该有一个更好的流程来处理这个问题。

谢谢。

1 个答案:

答案 0 :(得分:0)

您必须从发布点进行功能开发。从不在tip或从随机点:

v1 ----- v2 -- v3 --> v?
|\      //    /
|\f1 ---/    /
|\f2 ---    /
| f3 -------
f4 ------------------>

f...是功能开发。 v...是成功合并/测试功能集之后的分数(严格来说它是一个标记,但是为了维护发布修复,您可以使用命名分支)。

在示例中,我通过合并/测试/修复f1分支或f2分支标记为v2来为v2版本选择功能defaultv2 1}}更改f1f2分支中的内容。如果我在f1中发现错误,我会在f1中修复该错误,然后合并到v2'v3'

f3功能仅在v3版本中准备好发货。虽然我们仍然认为f4不适合发货。

基本部分 - 正确选择启动工具功能的点。如果您选择过早v点 - 源代码树中可能会遗漏某些功能,如果您选择太晚并且要求在早期版本v0中提供功能 - 则必须在没有支持的情况下向后移植功能来自DVCS工具。

您无法在其他功能的基础上开发功能,只能在功能关节点之上。

这与补丁管理类似,但我们尝试保留合并历史记录,因此我们有清晰的方向特征关系图,因此进一步合并会很容易。

另外,你要求避免挑选"功能"。该术语通常与错误挑选有关,可以通过bisect找到引入错误的第一个变更集来修复错误,修复该变更集之上的错误并合并到所有必需的修复分支。

或者像现在一样采取樱桃挑选,因为很容易采用这种有线的开发/发布模式。 SVN分支模型(特定于实现)与您使用Mercurial非常接近。

相关问题