我想使用 Mercurial/Jenkins 为持续集成场景实现以下工作流程

发布于 2024-10-24 23:03:39 字数 361 浏览 1 评论 0原文

主存储库是所有开发人员签入的地方，可以说它位于 http://hg.main.com:8000/project

现在，我们还有http://hg.qa.com:8000/project 其中所有最新代码都需要同步，另外，测试和其他工件都在这个存储库中。仅当 85% 的测试通过时，才会将其“推送”到中央存储库。

有没有更好的方法来实现这个？
我需要什么 hg 命令来确保我不会覆盖最新的提交

原文

分享到QQ

分享到微博

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

发布评论

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

绿光 2024-10-31 23:03:39

从类似的事情开始：
审批管理：审核和质量保证

为谁？

如果您需要使用开发人员团队和独立的 QA 团队明确批准的具有完整跟踪记录的代码历史记录，那么此工作流程可能适合您。

要求

您只需要 Mercurial（命令行）、用于交换数据的共享存储库（一个简单的 SSH 服务器就足够了，单个私有 bitbucket 存储库也足够）和 GpgExtension。

流程

此工作流使用默认分支进行开发，以及 QA 命名分支和发布分支。

优点是，将默认值合并到 QA 需要显式合并，随后可由负责它的开发人员进行 GPG 签名。

当 QA 完成应用更改时，他们首先合并回默认版本（以便开发人员处理 QA 版本），然后合并到发布版本，GPG 签署合并提交。

开发人员

hg pull # get the latest changes
hg update
hg commit -m ""
hg update -C QA
hg merge default
hg commit -m "merged default branch for QA"
hg sign
hg push

质量检查

hg pull
hg update QA
hg commit -m "QA fixes"
hg update -C default
hg merge QA
hg ci -m "merged QA fixes back into the development branch"
hg update -C release
hg merge QA
hg commit -m "merged finished QA into release"
hg sign

修改

如果您需要的层不仅仅是开发人员和 QA，只需添加其他命名分支，例如发布之前的 staging-release。

为了确保代码确实经过了所有人的检查，您可以要求所有头都必须经过 GnuPG 签名才能进入更高的存储库。

start with something ilke:
Approval Management: Auditing and QA

For whom?

If you need explicitely approved code history with a full track record using a team of developers and a seperate QA team, this workflow might be right for you.

Requirements

You need just Mercurial (command line), a shared repository for exchanging data (a simple SSH-server suffices, as does a single private bitbucket repository) and the GpgExtension.

Flow

This workflow uses the default branch for development, as well as a QA named branch and a release branch.

The advantage is that merging default into QA requires an explicit merge which can subsequently be GPG signed by the developer responsible for it.

When QA finishes applying their changes, they first of all merge back into default (so that developers work on the QA version) and then merge into release, GPG signing the merge commit.

Developer

hg pull # get the latest changes
hg update
hg commit -m ""
hg update -C QA
hg merge default
hg commit -m "merged default branch for QA"
hg sign
hg push

QA

hg pull
hg update QA
hg commit -m "QA fixes"
hg update -C default
hg merge QA
hg ci -m "merged QA fixes back into the development branch"
hg update -C release
hg merge QA
hg commit -m "merged finished QA into release"
hg sign

Modifications

If you need more layers than just developers and QA, just add additional named branches, for example staging-release before release.

To make sure that the code has really been checked by all, you can require that all heads must be GnuPG signed in order to enter a higher-up repository.

回复收藏 0 原文

~没有更多了~