具有选择性功能部署和持续集成的Mercurial工作流程

由12位开发人员组成的团队，您能帮我确定使用mercurial进行源代码管理和团队城市构建服务器的产品构建和部署产品的流程和工作流程吗？具有选择性功能部署和持续集成的Mercurial工作流程

我们有一个跟踪问题和改进请求的系统。其中大部分都是一些开发人员在一两天至一周的时间内完成的小bug和增强功能。我想要完成的是让业务人员和IT管理人员就开发人员工作的票证优先协商。完成后，这些更改将被提交并推送到中央存储库并在票务系统中标记为开发完成。那么qa和业务团队应该能够从被标记为开发完整的票据中进行选择，并且根据优先级，qa的必要数量和qa资源可用性，在我们的产品中包含下一个版本的票据。

我原本以为我可以通过让开发人员对每个票据的新命名分支提交更改来实现此目的。有了这个，每个选定票证的分支可以合并到默认值，并且可以执行构建和部署到qa（并最终生产）。

与此相关的问题是持续集成。在我看来，我只能静态配置teamcity来构建我们中央存储库中的特定分支。也许这是我们所在团队城市版本的限制。目前使用5.0.3，但升级是一个选项（和我们可能会做的任何事情）。也许有一些棘手的方法使它建立在提示之上，因此触发构建的提交的分支的头部发生了？如果开发人员正在为所有事情提交并推动不同的分支机构，并且这些分支机构在一段时间后才会合并到默认分支机构中 - 足够晚了，qa现在正在等待这些更改以进行构建，并且如果构建体损坏，则成本会更高 - 我们没有一个特定的分支来进行持续集成构建。或许我会让这个过于复杂和/或忽略一些简单的东西。帮助表示赞赏。有没有一种方法可以实现这种版本的选择性集成，并且在开发人员推动时仍然可以持续集成？

来源

2011-03-02 Dave Rael

命名分支并不适合短期努力，如错误和功能。他们更好地保留永久的概念，如“稳定”和“实验”，标签用于发布。阅读http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/ – 2011-03-02 06:20:51

我得出结论说，我试图采取的方向只是不会工作。将不得不以不同的方式做到这一点。

来源

2011-03-14 23:17:16

使用Jenkins（以前称为Hudson），开发人员很容易复制现有的作业（例如：在'默认'分支中构建最新头部的作业）并进行小改动（例如：构建最新头部的作业在'jim'分支）。（虽然阅读我的评论上面为什么命名分支可能不是你正在做的正确选择）。推测团队城市有类似的东西。

另一条路线就是像你说的那样做，只是让建造者总是建立'小费'，不管分支。您可以通过将“小费”作为分支名称来实现。这不是一个分支说明符，但是teamcity可能只是'hg update -C -r BRANCHNAME'和'tip'在那里工作得很好。

来源

2011-03-02 06:24:35

这是有效的，但只要注意两个开发人员的同时推送将使TeamCity跳过第一个时间很短。 – 2011-03-02 08:38:42

我也看到了Jenkins。单独的工作避免了这种情况，但总是易于提示。 – 2011-03-02 15:02:08

感谢您的信息。我将在构建配置中的小技巧中尝试一点。从来没有想到过那么简单的事情。我看到关于命名分支的观点。会考虑这个，并与我的团队交谈。将回到这里报告结果并接受答案。 – 2011-03-02 16:16:23

具有选择性功能部署和持续集成的Mercurial工作流程

回答

相关问题