简体繁体 English

如何使用Cruise Control和Mercurial进行回滚和构建

[英]How to roll back and build with Cruise Control and Mercurial

原文 2013-02-11 21:00:34 0 1 continuous-integration/ cruisecontrol.net/ kiln

I have a Kiln/Mercurial code repository for a web app that uses Cruise Control.NET for continuous integration. 我有一个Web应用程序的Kiln / Mercurial代码存储库，该存储库使用Cruise Control.NET进行持续集成。 Normally, we commit our code locally and when we're ready to test, we push to our central Kiln server. 通常，我们在本地提交代码，当我们准备测试时，我们将推送到中央Kiln服务器。 Cruise Control regularly checks the repository on that server for a new revision and when it finds it, it builds it and copies the resulting files out to the appropriate web server. Cruise Control会定期检查该服务器上的存储库中是否有新修订版，当它找到它时，它将对其进行构建，并将生成的文件复制到相应的Web服务器上。 If it tests out, we then manually force a build to our main production server and all is good. 如果测试成功，则我们手动将构建强制到主生产服务器，一切都很好。

Recently however, we had a small hiccup. 但是最近，我们遇到了小小的麻烦。 We found a bug in a version that was pushed out to production last month and it needs to be fixed. 我们在上个月发布的某个版本中发现了一个错误，需要对其进行修复。 There have been 50 or so commits since then and the code introduced in those 50 commits is nowhere near ready for production. 从那以后，已经有大约50次提交，而这50次提交中引入的代码几乎还没有准备好投入生产。 We know we can locally roll back (update) to the version that was pushed out to production and fix the code but we have no way to push that to Kiln and get it out to Cruise Control -- Mercurial on the Kiln server complains of multiple heads. 我们知道我们可以在本地回滚（更新）到生产版本并修复代码，但是我们无法将其推送到Kiln并将其发布到Cruise Control-Kiln服务器上的Mercurial抱怨有多个头 What's the best way to tackle this? 解决这个问题的最佳方法是什么？

We've googled around a bit and found references to branching and tags. 我们在Google上进行了一些搜索，找到了分支和标签的引用。 We ended up making a new branch in the repository on the Kiln server. 我们最终在Kiln服务器上的存储库中创建了一个新分支。 That branch had our main repository minus those 50 commits. 该分支的主存储库减去了这50个提交。 We then made our bugfix and edited the Cruise Control configuration to look there instead of the main repository. 然后，我们进行了错误修复，并编辑了“巡航控制”配置，以查找此处而不是主存储库。 After some builds, we had our bug fixed on the production server. 经过一些构建后，我们已将错误修复在生产服务器上。 This seems like a substantial amount of work to roll back, make a fix, and push that to a web server. 回滚，进行修复并将其推送到Web服务器上似乎需要进行大量工作。

Since we're a small shop, we usually have our own projects to work on. 由于我们是一家小商店，因此我们通常会有自己的项目要进行。 There's been no intentional branching (until now) and even minimal merging so although we're not new to version control, there are somewhat common aspects to that concept that we haven't had to deal with yet. 没有故意分支（直到现在），甚至没有最小限度的合并，因此尽管我们对版本控制并不陌生，但该概念仍有一些共同方面尚待解决。

1 个解决方案

You said that there was a problem in your code and after that you made some 50 commits. 您说代码中存在问题，之后进行了约50次提交。 So you made a branch which contains the current code - 50 commits. 因此，您创建了一个包含当前代码的分支-50次提交。

So my suggestion is that it should not be your branch , but it should be the Trunk only. 所以我的建议是它不应该是您的分支，而应该仅是Trunk。 The branch code should contains the code for a major change only ie you are working in that code for a long time and in the mean time there maybe chance to do some code in the trunk and can be moved to production. 分支代码仅应包含主要更改的代码，即您在该代码中工作了很长时间，与此同时，也许有机会在主干中编写一些代码，然后可以将其转移到生产环境中。

So while creating CI, my suggestion is to setup CI separately for both Trunk and branch, so you can do the testing. 因此，在创建CI时，我的建议是为Trunk和Branch分别设置CI，以便您可以进行测试。

Also moving to production should only be happened from trunk only. 转移到生产中也只能从主干进行。