5

我们的软件建立在 linux 和 windows 平台上。根据开发人员的偏好,在任一平台上开发和测试贡献,然后提交到我们的 subversion 存储库。然后事实证明,该贡献并未建立在其他平台上,因此必须进行修复。其他平台上的修复可能会再次破坏原始平台上的构建,依此类推。

我宁愿看到在提交之前也在另一个平台上构建了一个贡献(并进行了回归测试)。我们有一个持续构建服务器 (CruiseControl),但该服务器是从存储库构建的。我正在寻找一种解决方案,其中连续构建服务器在另一个平台上构建作为预提交检查,然后在构建和测试成功时提交内容。

有什么建议么?

4

5 回答 5

6

Teamcity 处理预先测试的提交,您可以使用 4.0 中的新构建链接功能做一些事情(http://www.jetbrains.com/teamcity/features/newfeatures.html)。代理是跨平台的,可以配置为仅运行构建的特定位,因此可以配置为仅运行一部分测试。

请注意,我实际上并没有这样做:)

于 2008-11-28T13:15:35.893 回答
1

拥有两个分支可能更容易,一个是人们签入的地方,另一个是他们在通过持续集成后将更改合并到的地方。

于 2008-11-28T13:09:44.627 回答
0

我们使用了一个定制的构建和测试平台,可以远程部署到多个操作系统(以及多个操作系统上的多个数据库产品)。这是作为夜间构建完成的,规则是您在第二天早上修复错误。

那时不是完全连续的,但这可能需要在预提交挂钩上做很多工作。特别是如果您的源代码控制存储库在预提交挂钩执行期间锁定受影响的文件。

我认为在白天运行的持续集成测试(每次提交)和每晚运行的系统集成测试是有区别的。

于 2008-11-28T13:18:21.830 回答
0

Matheiu Godlewski 在CruiseControl wiki上提出了一个很好的建议

如果你将他的建议与否决元素结合起来,我认为你应该被设置。

于 2008-11-28T20:46:49.663 回答
0

Douglas Leeder 提出了一个“集成”分支——它的好处是可以实现自动化。如果测试通过 - 合并到“主干”。

一些版本控制系统(例如 bzr/hg/git)比其他系统更容易做到这一点,但在大多数情况下都是可能的。

于 2008-11-28T21:00:27.373 回答