通常，企业标准化一个单独的生态系统，比如Java和Maven或者Ruby和Rake。除此之外的其他构建系统主要用来处理本地组件和第三方组件。

总而言之，我们不能假设在自己企业的代码库里只会碰到一个构建系统，就像我们也不能假设只用一种编程语言那样。

我发现这条规则在实践中很有用：一个开发者签出代码之后，应该能够在他或她的本地开发机上顺利地构建。

这暗示了我们应该标准化版本控制系统，并且有一个单独的接口来开始本地构建。

如果需要支持不止一个的构建系统，就基本上意味着你需要把一个构建系统包装成另一个。构建的复杂性会因此而被隐藏，并同时允许不止一个的构建系统。对某个特定构建不熟悉的开发者也能有望签出代码并且比较轻松地构建。

例如Maven适用于声明式Java构建。Maven也能够从自己的构建内部开始其他的构建。

通过这种方式，在以Java为中心的企业内的开发者可以期待以下命令总能构建企业的一个组件：

一个实际的例子是用Nullsoft NSIS Windows安装系统来创建一个Java桌面应用安装工具。Java组件用Maven来构建。当Java工件准备好了以后，Maven调用NSIS安装器脚本来生成一个自包含的可执行文件，可用于Windows安装。

虽然Java桌面应用近来不那么时髦了，但是在某些领域内它们还是用得很广。