我需要您对大型（1-2MLOC）软件开发项目的持续构建产品的建议。特征：
对您可能提供的任何最佳实践或外围指导感兴趣。构建自动化问题是该程序中似乎缺少的几个重叠的最佳实践之一，但请尽量将您的答案集中在构建基础设施部分和直接相关的观察上。
成本不是驱动因素。可扩展性和易于改造到现有基础设施是关键。
（编辑以解决@Dan 的评论。;-)
根据我对类似系统的经验，这个问题大约有两个部分：
一种可重复的方法，用于检查源代码、构建软件并对其进行测试（如果您想在构建的同时进行持续测试），使用少量命令行调用。
一种在构建场中的各种服务器上调用这些命令行的方法。
对于后者，我们一直在使用BuildBot，它似乎工作得很好。
对于前者，我们有一个自主开发的解决方案，它最初是一个简单的 bash shell 脚本，然后逐渐发展……相当大。根据经验，我建议从 python 而不是 bash 开始——与实际调用程序相比，您将花费更多的代码来处理设置和配置。（此外，如果您这样做，在 Windows 上运行它可能会更容易。）
我发现在我们的脚本有用性中真正关键的是：
铁定的可重复性。我们有一套标准的构建工具，脚本从清理环境变量开始。命令行选项很少；一切都进入配置文件，而那些进入版本控制。
记录。我们生成构建脚本执行的每个命令的日志。
配置文件继承。我们软件的每个变体都有一个配置文件，这些文件可以包含更通用的设置（包括更通用的设置）。
可扩展性。当我们添加一个新的源组件时，很容易添加一组用于构建该组件的指令（指令可以是任意 bash 代码）。“可以是任意代码”部分可能是这里的关键；现有的产品不可能完成大型复杂现实世界系统所需的所有古怪事情。
您可以从一个相当简单的脚本开始，并在需要时让它有机地增长；老实说，虽然我们的有点乱，但我认为我们得到的结果比使用沉重的自上而下的设计要好得多。
成本不是一个对象吗？我曾在 GreenHills 工作过，他们已经为他们的内部构建/测试农场解决了这些问题。要求他们为你做同样的事情。
当我看到构建系统中对可扩展性和安全性等方面的重视时，我开始认为您可能是企业级构建系统/CI 系统的候选人。方便的是，听起来你也买得起。一年前的SD Times 文章提供了企业级和团队级构建工具之间的基本细分。
我的公司生产AnthillPro，我们与许多公司合作过大型嵌入式项目以及高度安全的项目。IBM 可能是 BuildForge 领域中最大的其他参与者。
AnthillPro 更加强调您在构建后的几分钟/几小时/几天内对图像所做的事情（您是否将它们安装到模拟器/硬件上并运行自动化测试？暂存它们？推广它们？）但我们也看到人们使用它只是建立。