主要用于C++；GreenHills完整性的连续构建基础设施建议

Question

我需要你的建议，为一个大型(1-2MLOC)软件开发项目的持续构建产品。特点：

• ClearCase修订控制
• 大约80%的C++；15%的Java；5%的脚本或低级
• 为Green Hills完整性操作系统编译，但也有一些窗口和JVM块
• 主要是嵌入式系统；还包括一些UI部分和一些开发支持(模拟工具、配置工具等)
• 每个概念的“版本”的交付包括部署映像的许多板，用户界面机器等.(~10个单独的映像；5个不同的操作系统)
• 需要维护/跟踪许多同时版本，特别是为各种不同的板支持包构建的版本。
• 构建周期时间是项目中的一个主要问题，需要支持任何有助于解决这一问题的功能(我猜，大部分需要管理大量的构建机器)
• 在安全的环境中操作(这是一个非政府组织的程序)(编辑以添加：这是一个分类程序；外包构建基础设施是不可能的)。

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

成本不是驱动因素。可伸缩性和对现有基础设施进行改造的易用性是关键。

(编辑以回应@Dan的评论。;-)

Answer 1

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

• 一种可重复的方法，用于签出源代码、构建软件并对其进行测试(如果您想要进行持续的测试以及构建)，可以使用少量的命令行调用。
• 在构建场中的各种服务器上调用这些命令行的方法。

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

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

在我们的脚本的有用性中，我发现的关键是：

• 铁质可重复性我们有一套标准的构建工具，脚本从清理环境变量开始。命令行选项很少；所有的东西都进入配置文件，而这些都在版本控制中。
• 伐木。我们生成构建脚本执行的每个命令的日志。
• 配置文件继承。我们软件的每个变体都有一个配置文件，这些文件可以包含更多的一般设置(其中包括-更一般的设置)。
• 可扩展性当我们添加一个新的源代码组件时，很容易添加一组用于构建该组件的指令(这些指令可以是任意的bash代码)。“可以是任意代码”部分可能是这里的关键；一个预先存在的产品不可能完成一个大型复杂的现实世界系统所需要的所有奇怪的事情。

你可以从一个相当简单的脚本开始，在需要的时候让它有机地增长；老实说，虽然我们的脚本有点混乱，但我认为我们得到的结果比我们用自上而下的设计要有用得多。

Answer 2

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

Answer 3

当我看到对构建系统中的可伸缩性和安全性的强调时，我开始认为您可能是企业级构建系统/ CI系统的候选人。很方便，听起来你也能买得起。已有一年历史的“SD时报”文章提供了企业级和团队级构建工具之间的基本分解。

我的公司生产AnthillPro，我们与许多公司合作开发大型嵌入式项目和高度安全的项目。IBM可能是BuildForge领域中最大的其他参与者。

AnthillPro特别强调了在构建后的几分钟/小时/天内如何处理映像(您是否将它们安装到模拟器/硬件上并运行自动测试？表演他们？提拔他们？)但是我们也看到人们用它来构建。