.NET、Java 和其他语言的持续集成工具链定义相对明确,但 C++ 市场似乎有很多多样性。
我所说的 CI“工具链”是指用于构建脚本、自动化测试、编码标准检查等的工具。
C++ 团队为 CI 工具链使用什么?
.NET、Java 和其他语言的持续集成工具链定义相对明确,但 C++ 市场似乎有很多多样性。
我所说的 CI“工具链”是指用于构建脚本、自动化测试、编码标准检查等的工具。
C++ 团队为 CI 工具链使用什么?
另一种选择可能是buildbot。
它是用 python 编写的,但不仅仅适用于 python 应用程序。它可以执行任何脚本来进行构建。如果您查看他们的成功故事,您会发现似乎有各种各样的语言。
我们使用 Parabuild 实现了我们的 C++ 跨平台持续集成基础架构
http://www.viewtier.com/products/parabuild/screenshots.htm
我们能够将各种类型的 Win/Mac/Linux QA 工具与其集成,并且它非常易于安装和维护:它可以在每个平台上一键安装,并且 Web 界面非常方便。
在评估几个持续集成服务器时,主要问题是它们偏向于 Java:另一方面,Parabuild 非常适合 C++ 跨平台开发和 QA 工作流程
Visual Build Professional 是我最喜欢的将所有其他工具整合在一起的工具。当然,仅限 Windows,但它集成了所有类型的 Visual Studio 以及许多测试工具、源代码控制工具、问题跟踪器等。不过,它只是Windows。我知道这不是整个堆栈,但这是一个开始。
天,
我们实际上在我之前签约的一个站点上遇到了这个问题。
一个家伙坐下来写了一些工具,主要是 shell 脚本,
我们只是找不到任何商业上可用的东西来做这件事,所以查理坐下来用 bash shell 脚本编写了这个,它在 HP-UX 上运行。
干杯,罗伯
与 C++ 中的所有其他任务一样,我只是勉强完成持续集成。我的设置从 Eclipse 开始。我将其设置为为我的项目生成 make 文件。我有 ant 脚本,它们通过在适当的 makefile 上运行“make all”或“make clean”来完成整体构建任务。这些 ant 脚本是我项目的一部分,当我向系统添加新的构建配置或新部分时,我必须更新它们。不过还不错。
我使用 CruiseControl 来实际运行构建。每个项目(所有项目)都有自己的 ant 脚本,用于执行构建特定任务(复制工件、处理结果),调用项目 ant 脚本来进行构建。
我必须使用 cppunit 进行测试,并使用我在某处找到的 xslt 文件处理结果。我在每个版本上也有错误的 svn 修订标签,因为我找不到合适的 svn 标签器。我所能找到的只是完成了半年的代码,人们争辩说其他人做错了。
在我看来,CC 是一个垂死的系统,但我还没有找到比 C++ 更好的东西。再说一次,我也觉得 C++ 是一门垂死的语言,所以也许它比这更大。
我们使用scons进行由中央构建服务器运行的持续集成。一些项目迁移到buildbot。
我现在开始研究rake并考虑本博客中调查的解决方案。Fowler 在他的持续集成文章中提到,ThoughtWorks 偶尔会使用 rake 来编写构建脚本。