我目前正在工作中建立持续集成环境。我们使用 VisualSVN Server 和 CrusieControl.NET。有时,构建会失败,症状是 CruiseControl.NET 工作副本中存在冲突。我相信这是由于我设置 Visual Studio 解决方案的方式造成的。希望我们在这个环境中运行的项目越多,我们对如何设置它们的理解就会越好,所以我不会质疑为什么在这个阶段会发生冲突。为了修复构建,我删除了工作副本并强制进行新的构建 - 这每次都有效(当前)。所以我的问题是:删除工作副本是持续集成构建过程的有效部分吗?我该如何处理?

我尝试过包括 MSTask 和从命令行调用删除在内的解决方案,但我没有任何运气。

抱歉这么啰嗦 - 干得好,这是测试版:)

有帮助吗?

解决方案

在构建之前或之后进行完全删除是一个很好的做法。这意味着您的构建环境不可能拾取过时的文件。您的构建完全根据存储库中的内容进行。

删除工作副本是可能的,就像我用 Nant 所做的那样。

在 Nant 中,我会在自己的文件夹中放置一个干净的脚本,而不是我想要删除的脚本,然后从 CC.net 调用它。

我认为这也可以通过批处理文件实现。看一下 rmdir 命令 http://www.computerhope.com/rmdirhlp.htm

@保罗杜

我更喜欢我的 CI 服务器执行完全删除,因为当我进行发布构建时我不希望出现任何意外,而发布构建应该始终在干净的状态下完成。但它应该能够处理两者,没有理由不

其他提示

@杰米:使用持续集成服务器时,您可能无法每次都进行干净的构建,原因之一是构建时间。在我参与过的一些项目中,干净的构建需要 80 多分钟(一个嵌入式项目由数千个 C++ 文件组成,需要签出然后针对多个目标进行编译)。在这种情况下,您必须权衡快速反馈的好处与干净构建捕获增量构建无法捕获的东西的可能性。在我们的案例中,我们致力于改进和并行化构建过程,同时允许在我们的 CI 机器上进行增量构建。我们确实遇到了一些问题,因为我们没有进行干净的构建,但是通过每晚或每周进行一次干净的构建,您可以消除风险,而不会失去 CI 机器的快速反馈。

如果你查看 CC.NET 吉拉 签入了一个补丁来实现 Subversion 的 CleanCopy,它完全可以满足您的需求,只需在源代码控制块中将 CleanCopy 设置为 true,就像 TFS 一样。

对于任何构建过程来说,在进行任何重要构建之前进行“清理”是非常常见的,并且通常是一个很好的做法。这可以防止以前构建中的任何“伪影”污染输出。

清理本质上是通过删除工作副本来执行的操作。

@布拉德·巴克

清洁意味着只清除构建产品。

删除工作副本也会删除其他所有内容(源文件和项目文件等)。

一般来说,如果您构建的机器可以在不执行完全删除的情况下运行,那就太好了,因为这复制了普通开发人员所做的事情。它在更新期间发现的任何冲突都是对开发人员预期的早期警告。


@杰米

对于正式版本,最好进行完全干净的检查。所以我想这取决于构建的目的。

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top