主要针对 C++ 的持续构建基础设施建议绿山诚信
我需要您对大型 (1-2MLOC) 软件开发项目的持续构建产品的建议。特性：
- ClearCase 修订控制
- 约 80% C++； 15% 爪哇； 5% 的脚本或低级
- 编译适用于 Green Hills Integrity OS，但也有一些 Windows 和 JVM 块
- 主要是嵌入式系统；还包括一些 UI 部分和一些开发支持（模拟工具、配置工具等...）
- 交付物的每个概念“版本”都包括许多板、UI 机器等的部署映像...（约 10 个单独的映像; 5 个不同的操作系统）
- 需要维护/跟踪许多同步版本，这些版本特别是为各种不同的板支持包构建的
- 构建周期时间是项目的一个主要问题，需要支持任何有助于解决此问题的功能（大多数情况下需要）我猜是为了管理一个大型构建机器场..）
- 在安全的环境中运行（这是一个政府计划）（编辑添加：这是一个机密计划；外包构建基础设施是不可能的。）
对您可能提供的任何最佳实践或外围指导感兴趣。构建自动化问题是该程序中似乎缺少的几个重叠的最佳实践之一，但请尝试将您的答案集中在构建基础设施部分和直接相关的观察结果上。
成本并不是驱动因素。可扩展性和对现有基础设施进行改造的便捷性是关键。
（编辑以解决@Dan 的评论。；-）
I need your recommendations for continuous build products for a large (1-2MLOC) software development project. Characteristics:
- ClearCase revision control
- Approx 80% C++; 15% Java; 5% script or low-level
- Compiles for Green Hills Integrity OS, but also some windows and JVM chunks
- Mostly an embedded system; also includes some UI pieces and some development support (simulation tools, config tools, etc...)
- Each notional "version" of the deliverable includes deployment images for a number of boards, UI machines, etc... (~10 separate images; 5 distinct operating systems)
- Need to maintain/track many simultaneous versions which, notably, are built for a variety of different board support packages
- Build cycle time is a major issue on the project, need support for whatever features help address this (mostly need to manage a large farm of build machines, I guess..)
- Operates in a secure environment (this is a gov't program) (Edited to add: This is a classified program; outsourcing the build infrastructure is a non-starter.)
Interested in any best practices or peripheral guidance you might offer. The build automation issues is one of several overlapping best practices that appear to be missing on the program, but try to keep your answers focused on build infrastructure piece and observations directly related.
Cost is not the driving concern. Scalability and ease of retrofitting onto an existing infrastructure are key.
(Edited to address @Dan's comment. ;-)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
根据我对类似系统的经验，这个问题大约有两个部分：
一种可重复的方法，用于检查源代码、构建软件和测试它（如果您想在构建的同时进行持续测试），使用少量的命令行调用。
在构建场中的各种服务器上调用这些命令行的方法。
对于后者，我们一直在使用 BuildBot，它似乎工作得很好。
对于前者，我们有一个自行开发的解决方案，最初是一个简单的 bash shell 脚本，然后不断发展……相当大。根据经验，我建议从 python 而不是 bash 开始——与实际调用程序相比，您将在处理设置和配置上花费更多的代码。 （此外，如果您这样做，在 Windows 上运行它可能会更容易。）
我发现对我们的脚本有用性真正关键的事情是：
铁定的可重复性。我们有一套标准的构建工具，脚本从清理环境变量开始。命令行选项很少；所有内容都进入配置文件，并且这些内容进入版本控制。
记录。我们生成构建脚本执行的每个命令的日志。
配置文件继承。我们软件的每个变体都有一个配置文件，这些文件可以包含更常规的设置（其中包括更常规的设置）。
可扩展性。当我们添加一个新的源组件时，添加一组用于构建该组件的指令非常容易（并且这些指令可以是任意 bash 代码）。 “可以是任意代码”部分可能是这里的关键；现有的产品不可能完成大型复杂的现实系统所需的所有奇怪的事情。
您可以从一个相当简单的脚本开始，并让它随着需要的出现而有机地发展；老实说，虽然我们的有点混乱，但我认为我们通过这种方式得到了比重型自上而下设计更有用的结果。
From my experience with similar systems, there are approximately two parts to this problem:
A repeatable method for checking out sources, building the software, and testing it (if you want to do continual testing as well as building), using a small number of command-line invocations.
A means of calling these command lines on various servers in the build farm.
For the latter, we've been using BuildBot, which seems to work pretty well.
For the former, we have a homegrown solution that started out as a simple bash shell script and grew ... rather substantially. From experience, I'd suggest starting out in python rather than bash -- you'll spend far more code in handling setup and configuration than in actually invoking programs. (Also, it's probably easier to run it on Windows if you're doing that.)
The things I've found to be really key in our script's usefulness are:
Ironclad repeatability. We have a standard set of build tools, and the scripts start out by scrubbing environment variables. There are very few command-line options; everything goes into configuration files, and those go in version control.
Logging. We produce a log of every command that the build script executes.
Configuration file inheritance. Each variant of our software gets a configuration file, and those files can include more-general settings (which include even-more-general settings).
Extensibility. When we add a new source component, it's pretty easy to add a set of instructions for building that component (and the instructions can be arbitrary bash code). The "can be arbitrary code" part is probably key here; no way is a pre-existing product going to be able to do all of the quirky things that you need for a large complex real-world system.
You can get started with a reasonably simple script and let it grow organically as the need arises; honestly, although ours is a bit messy, I think we got a much more usable result that way than we would have with heavy top-down design.
成本不是一个对象？我曾在 GreenHills 工作过，他们已经为其内部构建/测试农场解决了这些问题。请他们为您做同样的事情。
Cost isn't an object? I've worked for GreenHills, and they've solved these issues for their in-house build/test farms. Ask them to do the same for you.
当我看到构建系统中对可扩展性和安全性等方面的强调时，我开始认为您可能是企业级构建系统/CI 系统的候选人。方便的是，听起来你也买得起。一年前的SD Times 文章提供了企业级和团队级构建工具之间的基本细分。
我的公司生产 AnthillPro，我们与许多公司就大型嵌入式项目以及高度安全的项目进行了合作。 IBM 可能是 BuildForge 领域最大的其他参与者。
AnthillPro 特别强调您在构建后的几分钟/几小时/几天内对图像所做的事情（您是否将它们安装到模拟器/硬件上并运行自动化测试？暂存它们？推广它们？），但我们也看到人们将它用于只是建造。
When I see emphasis on things like scalability and security in a build system, I start thinking that you might be a candidate for the enterprise class build systems / CI systems. Conveniently, it sounds like you can afford them as well. A year old SD Times article provides a basic breakdown between the enterprise and team level build tools.
My company makes AnthillPro and we've worked with a number of companies on large embedded projects as well as highly secure projects. IBM is probably the largest other player in the space with BuildForge.
AnthillPro puts some extra emphasis on what you do with the images in the minutes/hours/days post build (do you install them onto simulators / hardware and run automated tests? stage them? promote them?) but we also see folks using it for just build.