如何使用mercurial进行发布管理？

发布于 2024-09-25 04:34:05 字数 2046 浏览 5 评论 0原文

这是与我的之前的问题“如何管理Mercurial 的并发开发”，涵盖了个人开发人员工作流程。这个问题的答案实际上会影响开发人员工作流程的选择。

这不是一般的“发布管理最佳实践”或 CI 问题，因为它是询问很多时间有很好的答案，并且有大量文献可以用来消磨时间。

我只是要求在发布管理的背景下使用 Mercurial 的具体方法。

最明显和最主要的答案应该是stable/default，它被@Steve Losh 的美丽博客，更简洁的内容在他的回答。它简单而有效。

这种设置的一个突出例子是 hg 本身。 hg 使用更多存储库进行主动开发，但出于发布管理目的，一切似乎都包含在主存储库的稳定/默认分支中。

hg 设置实际上体现了稳定/默认的变体，或者更确切地说是扩展版本：分支克隆。我在对named问题的回答中描述了该过程分支与多个存储库（还有来自@的另一个很好的答案马丁·盖斯勒）。我在回答中忘记提及的是分支克隆如何适用于开发人员工作流程：如果您需要修复分支的错误，您可以 hg clone

# 但是不是分支克隆，因为您的变更集仍然会返回到主存储库并自动推送到分支克隆。当然，您可以选择不克隆，而仅在主克隆中进行 hg update ，但使用单独克隆（尤其是独立构建）的大多数论点都适用于此处。

现在回到问题：是否有其他方法可以适应不同的现实场景？例如，传统的主要/次要/补丁发布周期（版本之间的间隔很长）可能需要与传统的主要/次要/补丁发布周期完全不同的工作流程快节奏、即用即发布的 Web 应用程序。如果您愿意，还请对稳定/默认和分支克隆方法发表评论。

由于这几乎是一个调查问题，我只能尝试主观地接受“最佳”答案。如果我能得到比我的开发人员工作流程问题更多的答案，那就是。

感谢您的所有投入！

原文

This is a cousin question with my earlier question of "How to manage concurrent development with mercurial", which covers individual developer workflow. The answer to this question will actually influence the choice for developer workflow.

This is NOT a general "release management best practice" or CI question, as it has been asked many times with good answers, and there's a huge body of literature available to kill time.

I'm only asking for specific ways to use mercurial within the context of release management.

The most obvious and predominant answer would supposedly be stable/default, which is thoroughly covered by the beautiful blog of @Steve Losh, and more concisely in an answer from him. It's simple and effective.

A prominent example of this setup is hg itself. hg uses a few more repositories for active development, but for release management purposes everything seems to be contained in the stable/default branches of the main repo.

The hg setup actually manifests a variation, or rather an extended version, of stable/default: branch clone. I described the process in an answer to a question on named branch vs. multiple repos (with another great answer from @Martin Geisler). What I forgot to mention in my answer is how branch clone works for developer workflow: if you need to fix a bug for a branch, you would hg clone <main repo>#<branch> but not the branch clone, because your changeset will still go back to the main repo and pushed out to branch clone automatically. Of course you can choose not to clone and just hg update <branch> in your main clone, but most arguments for using separate clones (especially the independent build) apply here.

Now back to the question: Are there any other ways that fit different real-world scenarios? For example, a traditional major/minor/patch release cycle with long lapse between releases probably require quite a different workflow than a fast-paced, release-as-you-go web application. Please also comment on the stable/default and branch clone approaches if you feel like.

Since this is almost a survey question, I can only try to accept the "best" answer subjectively. If I can get a few more answers than my developer workflow question, that is.

Thank you for all your inputs!

分享到QQ

分享到微博

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

发布评论

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

想挽留 2024-10-02 04:34:05

我正在重新设计我们的发布工作流程。所以我发现了这个问题。我决定写下我的经历。对于它的价值...

对于开发，我们使用的东西似乎是您所谓的“稳定/默认”工作流程的变体（当然，一切都通过强制工作流程的命令，我称之为myw 此后）：

我们有一个中央服务器，其中保存了我们所有的存储库，
我们在该服务器上的每个项目都有一个中央稳定克隆
，我们有一个中央开发每个项目的克隆，最初是该服务器上稳定的克隆
，可以myw create theproject来创建stable/dev克隆服务器上的项目和本地（开发人员计算机上）的项目，
当有人必须开发新功能时，他可以 myw 克隆 theproject dev mygreatfeature ：
- 将服务器上的项目 dev 存储库克隆为 mygreatfeature
- 在本地克隆克隆的存储库mygreatfeature
- 做了很多有用的事情，比如更新 hgserver / hudson ci ...
他可以随时 myw fetch dev 和 myw fetch stable
当功能完成后，他将其合并回本地开发克隆，将合并结果推送到中央dev克隆并关闭已存档一段时间的中央克隆：myw close theproject mygreatfeature

所有这些都工作得很好并且非常顺利。我们更喜欢克隆而不是命名分支，因为真正关闭功能分支很简单，而且当时善变的“命名分支”部分看起来像是“正在进行中的工作”。

工作流程的发布部分目前基本上是这样完成的：

“发布主”从中央dev克隆获取到他的本地dev克隆。
他从中央稳定克隆获取到本地稳定克隆。
他从本地稳定克隆中获取本地开发克隆中的更改。
他检查了一切，如果没问题，就执行 myw release 1.2.3_RC2 ：
- 带有 1.2.3_RC2 的标签
- 推送到集中项目稳定克隆。
- 这实际上是一个候选版本，我们的 CI 服务器和核心测试人员将对其进行一段时间的测试。
这些测试发现的错误修复已修复在本地稳定克隆上，并推送到集中稳定克隆上。
当一切正常时，“发布大师”会进行正式发布：myw release 1.2.3

即使我们需要改进一些命令以使过程顺利进行，它也运行得很好。主要缺点之一是有很多克隆:)

为了管理旧版本，我们目前为每个主要版本都做了一个稳定的克隆。由于不需要向后移植许多功能，我们只需使用 hg port 挑选一些非常糟糕的错误（顺便说一句，这是一个很棒的扩展）。

我们已经使用它大约一年了，我们当然需要改进我们的自制命令，特别是对于发布部分:)

主要缺点是您必须为您/您的团队提供一些工具来处理它，因为如果没有它们，它可能会难以管理，因此我们使用 myw 自制命令集。像往常一样，功能分支不应持续太长时间，否则合并可能很难进行。诸如重构/重命名之类的事情必须在选定的点完成，否则会给您的团队带来大量的合并工作。

由于我们将有越来越多的版本需要维护，我正在尝试改进“旧版本但必须支持”管理部分。阅读 Bert F 评论，我读了这篇精彩的文章。有很好的想法，并且用一个非常好的方案很好地解释了！似乎有人已经将他的工具 git-flow 的 hg 版本实现为 hg-flow。需要考虑的事情。我喜欢发布和修补程序分支。我认为使用工具强制执行这样的工作流程是非常强制性的！

我的2c

I'm in the process of re-designing our workflow for release. So I've found this question. I've decided to wrote my experience. For what it's worth ...

For development, we are using something that seems to be variation of what you call the stable/default workflow (of course everything goes through commands that enforce the workflow, I call them myw thereafter) :

we have a central server which holds all of our repositories
we have a central stable clone per project on this server
we have a central dev clone per project which is a clone of stable on this server
initially, one can myw create theproject which create the stable/dev clones for theproject on the server and that locally (on the developer computer)
when someone has to develop a new feature he can myw clone theproject dev mygreatfeature that :
- clones the project dev repo on the server as mygreatfeature
- clones locally the cloned repo mygreatfeature
- makes lot of useful things like updating hgserver / hudson ci ...
he can myw fetch dev and myw fetch stable anytime
when the feature is done he merges it back to his local dev clone, push the merged result on the central dev clone and close the central clone which is archived for a while : myw close theproject mygreatfeature

All of that works great and is pretty smooth. We have preferred clones to named branches as it was simple to really close a feature branch, and at the time the mercurial "named branch" part seemed like "work in progress".

The release part of the workflow is presently done basically like that :

the "release master" fetches from the central dev clone to his local dev clone.
he fetches from the central stable clone to his local stable clone.
he fetch from his local stable clone the changes that are in his local dev clone.
he checks everything, if it is ok, do myw release 1.2.3_RC2 that :
- tag with 1.2.3_RC2
- push to the centralized project stable clone.
- this is in fact a release candidate, that will be tested for a while by our CI server and by our hardcore testers.
Bug fixes discovered by those tests are fixed on the local stable clone and pushed on the centralized stable clone.
when its ok, the "release master" do a formal release : myw release 1.2.3

That works pretty well, even if we needs to improve some commands to smooth the process. One of the main drawback it's that's a lot of clones :)

For the management of old releases, we have currently a clone of stable done for each major release. As there is no big need to backport many features, we just have to cherry-pick some really bad bugs with hg transplant (great extension by the way).

We have used that for about a year, and we certainly need to improve our homemade commands, especially for the release part :)

The main drawback is that you have to give you/your team some tools to handle it because without them it could be unmanageable, hence our myw homemade set of commands. As usual, the feature branch should not last for too long, or merging can be hard to do. Things like refactoring/renaming has to be done at chosen points, or it will give your team a lot of merging work.

As we are going to have more and more versions to maintain, I'm trying to improve the 'old release but have to support' management part. Reading Bert F comment, I've read this great article. There is good ideas and it is well explained with a really good scheme ! It seems someone has implemented the hg version of his tool git-flow as hg-flow. Something to consider. I like the release and hotfixes branches. And I think that enforcing such workflow with a tool is pretty well mandatory !

my2c

回复收藏 0 原文

~没有更多了~