针对C++的持续构建基础架构建议; GreenHills诚信

Question

我需要您为大型(1-2MLOC)软件开发项目提供持续构建产品的建议.特点:

• ClearCase版本控制
• 大约80%C++; 15%的Java; 5%的脚本或低级别
• 编译Green Hills Integrity OS,还有一些Windows和JVM块
• 主要是嵌入式系统; 还包括一些UI部分和一些开发支持(模拟工具,配置工具等......)
• 可交付成果的每个名义"版本"包括许多板,UI机器等的部署映像......(~10个单独的图像; 5个不同的操作系统)
• 需要维护/跟踪许多同步版本,特别是为各种不同的板支持包构建
• 构建周期时间是项目的一个主要问题,需要支持任何有助于解决这个问题的功能(主要是需要管理一大堆构建机器,我猜...)
• 在安全的环境中运行(这是一个政府计划)(编辑补充:这是一个机密程序;外包构建基础架构是一个非首发.)

对您可能提供的任何最佳实践或外围指导感兴趣.构建自动化问题是程序中似乎缺少的几个重叠的最佳实践之一,但尝试将您的答案集中在构建基础架构和直接相关的观察上.

成本不是驱动因素.可扩展性和易于改装到现有基础架构是关键.

(编辑解决@ Dan的评论.;-)

Answer 1

根据我对类似系统的经验，这个问题大约有两个部分：

• 一种可重复的方法，用于使用少量命令行调用来检查源代码、构建软件并测试它（如果您想在构建的同时进行持续测试）。

• 在构建场中的各种服务器上调用这些命令行的方法。

对于后者，我们一直在使用BuildBot，它似乎工作得很好。

对于前者，我们有一个自行开发的解决方案，最初是一个简单的 bash shell 脚本，然后不断发展……相当大。根据经验，我建议从 python 而不是 bash 开始——与实际调用程序相比，您将在处理设置和配置上花费更多的代码。（此外，如果您这样做的话，在 Windows 上运行它可能会更容易。）

我发现对我们的脚本的实用性来说真正关键的是：

• 铁定的重复性。我们有一套标准的构建工具，脚本从清理环境变量开始。命令行选项很少；所有内容都进入配置文件，并且这些内容进入版本控制。

• 记录。我们生成构建脚本执行的每个命令的日志。

• 配置文件继承。我们软件的每个变体都有一个配置文件，这些文件可以包含更通用的设置（其中包括更通用的设置）。

• 可扩展性。当我们添加一个新的源组件时，添加一组用于构建该组件的指令非常容易（并且这些指令可以是任意 bash 代码）。“可以是任意代码”部分可能是这里的关键；现有的产品不可能完成大型复杂的现实世界系统所需的所有奇怪的事情。

您可以从一个相当简单的脚本开始，并让它随着需要的出现而有机地发展；老实说，虽然我们的有点混乱，但我认为我们通过这种方式得到了比重型自上而下设计更有用的结果。