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

Question

我需要为大型（1-2MLOC）软件开发项目提供持续构建产品的建议。特性：

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

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

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

（编辑以解决@ Dan的评论。; - ）

Answer 1

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

• 使用少量命令行调用来检查源，构建软件并对其进行测试（如果要进行连续测试以及构建）的可重复方法。

  < / LI>

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

对于后者，我们一直在使用BuildBot，这看起来效果很好。

对于前者，我们有一个本土的解决方案，最初是一个简单的bash shell脚本，并且相当长大。根据经验，我建议从python而不是bash开始 - 你将花费更多的代码来处理设置和配置而不是实际调用程序。 （另外，如果你这样做，在Windows上运行它可能更容易。）

我发现在我们的剧本中非常有用的东西是：

• Ironclad重复性。我们有一套标准的构建工具，脚本从清理环境变量开始。命令行选项很少;一切都进入配置文件，然后进入版本控制。

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

• 配置文件继承。我们软件的每个变体都会获得一个配置文件，这些文件可以包含更多常规设置（包括甚至更常规的设置）。

• 扩展。当我们添加一个新的源组件时，添加一组用于构建该组件的指令非常容易（并且指令可以是任意的bash代码）。 “可以是任意代码”部分可能是关键所在;没有办法预先存在的产品能够完成大型复杂的真实世界系统所需的所有古怪事物。

您可以开始使用一个相当简单的脚本，并在需要时让它有机地发展;老实说，虽然我们的设备有点混乱，但我认为我们得到的结果比自上而下的设计更加实用。

Answer 2

成本不是一个对象？我曾为GreenHills工作，他们已经为他们的内部构建/测试农场解决了这些问题。请他们为你做同样的事。

Answer 3

当我看到构建系统中的可扩展性和安全性等重点时，我开始认为您可能是企业级构建系统/ CI系统的候选者。方便的是，听起来你也可以负担得起。一年前的SD Times article提供了企业和团队级构建工具之间的基本细分。

我的公司制作AnthillPro，我们与许多公司合作开展大型嵌入式项目以及高度安全的项目。 IBM可能是BuildForge空间中最大的其他玩家。

AnthillPro特别强调你在构建后的分钟/小时/天内对图像的处理（你将它们安装到模拟器/硬件上并运行自动化测试吗？将它们分级？推广它们？）但我们也看到了人们用它来构建。