具有选择性功能部署和持续集成的Mercurial工作流程 [英] Mercurial workflow with selective feature deployment and continuous integration

问题描述

对于由12名开发人员组成的团队，您能帮助我确定使用Mercury进行源代码控制并使用Team City进行构建服务器来构建和部署产品的过程和工作流程吗?

for a team of 12 developers, can you help me determine a process and workflow for building and deploying a product using mercurial for source control and team city for build server?

我们有一个跟踪问题和增强要求的系统.其中大多数都是很小的错误，并且由一个开发人员在一天或两天到一周的时间内进行了改进.我要实现的是让业务人员和IT管理人员为开发人员工作的票证协商优先级.完成后，这些更改将提交并推送到中央存储库，并在票证系统中标记为已完成开发.然后，质量保证和业务团队应能够根据优先级，必要的质量保证数量和质量保证资源可用性，从标记为开发人员已完成的故障单中进行选择，并将这些故障单包含在我们的产品中以用于下一个版本.

we have a system that tracks issues and enhancement requests. most of these are pretty small bugs and enhancement worked on by one developer in a timeframe of a day or two up to a week. what i want to accomplish is to have business persons and IT management negotiate priorities for tickets on which developers work. when completed, these changes are committed and pushed to the central repository and marked as dev complete in the ticketing system. the qa and business teams should then be able to select from the tickets that are marked as dev complete and have those included in our product for the next release based on priorities, the amount of qa necessary, and qa resource avaialbility.

我本来以为我可以通过让开发人员在每个票证的新命名分支上提交更改来实现此目的.这样，每个选定票证的分支都可以合并到默认票证上，并可以执行构建和部署到质量检查(最终是生产)的过程.

i was originally thinking i could get this implemented by having developers commit changes on a new named branch for each ticket. with this, the branch for each selected ticket can be merged onto default and the build and deploy to qa (and ultimately production) can be executed.

问题是持续集成.在我看来，我只能静态配置teamcity以建立我们中央存储库中的特定分支.也许这是对我们所在的Teamcity版本的限制.当前使用5.0.3，但可以选择升级(无论如何，我们可能会做一些事情).也许有一些棘手的方法可以使它从尖端开始构建，因此发生了触发构建的提交的分支的头部?如果开发人员正在为所有内容提交并推动不同的分支，并且这些分支直到一段时间之后才被合并为默认分支-足够晚的时间，qa现在正在等待这些更改生成，并且如果构建失败，则成本会更高-没有特定的分支供我们进行持续集成构建.

the problem with this is continuous integration. it appears to me i can only configure teamcity statically to build off a particular branch in our central repository. maybe this is a limitation of the version of teamcity we are on. currently using 5.0.3, but upgrading is an option (and something we'll probably do anyway). maybe there's some tricky way to make it build off the tip and therefore the head of the branch on which the commit triggering the build occurred? if developers are committing and pushing on different branches for everything and these branches don't get merged into default until some time later - enough later that qa is now waiting for these changes to build and if there is a broken build, the cost is higher - there isn't a specific branch on which for us to do a continuous integration build.

也许我使这个过于复杂和/或忽略了一些简单的事情.感谢您的帮助.我有什么办法可以完成针对发行版的选择性集成，而在开发人员进行推送时仍可以持续集成?

perhaps i am making this overly complicated and/or overlooking something simple. help is appreciated. is there a way i can accomplish this selective integration for releases and still have continuous integration at the time developers are doing pushes?

推荐答案

我得出的结论是，我试图采取的方向是行不通的.将不得不以其他方式做到这一点.

i have concluded that the direction i was trying to take is just not going to work. will have to do this a different way.

这篇关于具有选择性功能部署和持续集成的Mercurial工作流程的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！