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

发布于 10-20 09:50 字数 761 浏览 4 评论 0原文

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

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

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

这样做的问题是持续集成。在我看来,我只能静态配置 teamcity 来构建我们中央存储库中的特定分支。也许这是我们所在的 teamcity 版本的限制。目前使用的是 5.0.3,但升级是一种选择(而且我们可能会这样做)。也许有一些棘手的方法可以让它从尖端构建,因此在触发构建的提交发生的分支的头部?如果开发人员正在为所有内容提交并推送不同的分支,并且这些分支直到一段时间后才会合并到默认分支中 - 足够晚,质量保证现在正在等待这些更改来构建,如果存在损坏的构建,则成本会更高- 没有一个特定的分支可供我们进行持续集成构建。

也许我让这变得过于复杂和/或忽略了一些简单的事情。感谢帮助。有没有一种方法可以完成这种选择性的发布集成,并且在开发人员进行推送时仍然可以进行持续集成?

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?

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.

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?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

我要还你自由2024-10-27 09:50:30

使用 Jenkins(以前称为 Hudson),开发人员可以轻松复制现有作业(例如:在“默认”分支中构建最新头的作业)并进行小更改(例如:在“jim”分支中构建最新头的作业) ' 分支)。 (尽管阅读上面我关于为什么命名分支可能不是您正在做的事情的正确选择的评论)。想必 teamcity 也有类似的东西。

另一种方法是按照您所说的那样进行,并且让构建者始终构建“提示”,无论分支如何。您可以通过输入“tip”作为分支名称来实现这一点。它不是分支说明符,但 teamcity 可能只是执行 'hg update -C -r BRANCHNAME' 和 'tip' 在那里工作得很好。

Using Jenkins (formerly Hudson) it's easy for developers to duplicate an existing job (ex: a job that builds the newest head in 'default' branch) and make a small change (ex: a job that builds the newest head in the 'jim' branch). (Though read my comment above about why named branches probably aren't the right choice for what you're doing). Presumably teamcity has something similar.

Another route is to do just as you said and just have the builder always build the 'tip' regardless of branch. You can probably acheive that by just putting in 'tip' as the branch name. It's not a branch specifier, but teamcity likely just does 'hg update -C -r BRANCHNAME' and 'tip' will work just fine there.

童话2024-10-27 09:50:30

我得出的结论是,我试图采取的方向是行不通的。将不得不以不同的方式做到这一点。

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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文