如何使用Mercurial进行发布管理? [英] How to use mercurial for release management?

问题描述

这是我的前面的问题的表亲问题 如何用Mercurial管理并发开发"，其中涵盖了各个开发人员的工作流程.这个问题的答案实际上将影响开发人员工作流程的选择.

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.

这不是一般的发布管理最佳实践"或CI问题，因为它已经许多 时间，给出了很好的答案，并且有大量文献可以用来消磨时间.

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.

我只要求在发布管理的上下文中使用具体方法来使用Mercury.

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.

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

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.

Hg设置实际上体现了稳定/默认的变体或扩展版本:分支克隆.我在答案中描述了该过程分支与多个存储库(来自@的另一个最佳答案马丁·盖斯勒(Martin Geisler).我在答案中忘记提及的是分支克隆如何适用于开发人员工作流程:如果您需要修复分支的错误，则可以hg clone <main repo>#<branch>而不是 分支克隆，因为您的更改集将仍然返回主仓库，并自动推出分支克隆.当然，您可以选择不克隆，而仅在主克隆中选择hg update <branch>，但是大多数使用单独克隆(尤其是独立版本)的参数都适用于此.

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.

现在回到问题所在:还有其他适合不同实际情况的方法吗?例如，传统的主要/次要/补丁发布周期之间，发布之间的间隔很长，可能需要相当长的时间.与快节奏的随行发行Web应用程序不同的工作流程.如果您愿意，还请评论稳定/默认和分支克隆方法.

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.

感谢您的所有投入！

推荐答案

我正在重新设计要发布的工作流程.所以我找到了这个问题.我决定写我的经历.为了它的价值...

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 ...

对于开发而言，我们使用的似乎是您所说的 stable/default 工作流程的变体(当然，所有内容都通过强制执行工作流程的命令进行处理，此后我将其称为myw ):

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) :

• 我们有一个中央服务器，可以存放我们所有的存储库
• 我们在此服务器上的每个项目都有一个中央 stable 克隆
• 每个项目都有一个中央 dev 克隆，这是此服务器上 stable 的克隆
• 最初，可以myw create theproject为服务器上的项目以及本地(在开发人员计算机上)的项目创建 stable/dev 克隆.
• 当某人必须开发新功能时，他可以myw clone theproject dev mygreatfeature:
  • 在服务器上将项目 dev 存储库克隆为 mygreatfeature
  • 在本地克隆克隆的存储库 mygreatfeature
  • 做了很多有用的事情，例如更新hgserver/hudson ci ...
  • 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 ...

    所有这些都很好用，并且非常流畅.我们更喜欢克隆而不是命名分支，因为真正关闭特征分支很简单，而当时的命名分支"部分似乎就像进行中的工作".

    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 :

    • 发行版主"从中央的 dev 克隆中获取到其本地的 dev 克隆.
    • 他从中央 stable 克隆中获取了本地的 stable 克隆.
    • 他从本地 stable 克隆中获取其本地 dev 克隆中的更改.
    • 他检查了所有内容，如果可以，请执行myw release 1.2.3_RC2:
      • 带有1.2.3_RC2的标签
      • 推送到集中式项目稳定克隆.
      • 这实际上是一个 release候选版本，将由我们的CI服务器和核心测试人员进行一段时间的测试.
      • 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.

        即使我们需要改进一些命令来简化过程，效果也很好.主要缺点之一是克隆很多:)

        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 :)

        对于旧版本的管理，我们目前已为每个主要版本完成了 stable 的克隆.由于不需要大量移植许多功能，因此我们只需要使用hg transplant(顺便说一句，很好的扩展)挑选一些非常糟糕的错误.

        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 :)

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

        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.

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

        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

        这篇关于如何使用Mercurial进行发布管理?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！