多年来，我创建并调整了一组NAnt脚本来执行完整的项目构建。主脚本采用单个应用程序端点（例如Web应用程序项目），并从源代码控制构建完整的脚本。这些脚本预先配置了有关构建输出位置，源控制地址等的必要信息。重点是，您可以提供非常少的信息并从头开始构建给定项目。这满足了我问题的“任意”部分。
过去，我曾为那些生产一些软件产品（主要是Web应用程序）的公司工作过。这种环境非常适合典型的连续集成设置，每个产品都有一个集成器。我已经设置了集成商，既可以作为CI构建，也可以作为集成商来处理完整的候选版本构建和QA部署。这些集成商使用主构建脚本，因此集成商本身只是源控制监控和对主NAnt脚本的调用。
我现在为创建许多应用程序的开发组工作。通常，开发人员被要求支持最初由他人构建的应用程序。当我开始时，没有建立管理。作为一个业务部门产品套件（大约六个完整系统）的4人团队的首席开发人员，我在集团内部处于一个特别独特的位置。我已经使用主构建脚本实现了CruiseControl.Net，用于执行CI构建和RC构建。这适用于业务产品套件中的固定项目集。
我已经使用CCNet很多年了，所以我完全知道它能做什么。我非常尊重它对持续集成领域的贡献，因为我将它用于我的产品套件中的所有项目。我向我的团队强调使用官方RC构建集成器作为主要构建器，用于发往开发之外的任何位置的任何东西。这可以很好地控制CCNet控制下的固定项目集。
但是，还有其他开发人员正在构建其他应用程序。其中一些是1个开发人员项目，在项目生命周期（我正在尝试改变的其他事情）之前，它们通常甚至不在源代码控制中。其中许多项目都是一次性的，在部署后不会有太多的生命。尽管如此，他们仍然需要得到支持。支持这些的不可或缺的是，如果没有对这些项目进行集中构建管理，那么发布候选版本将构建到QA，最终生产将在各个开发人员计算机上完成。当然，这无法保证所有内容都在开发人员机器构建的其他因素之间进行源代码控制。
我一直试图解决的问题是：我可以使用哪种系统来集中控制这些任意构建？这绝对不是一个独特的问题。然而，在我对集中构建，构建自动化和持续集成所做的大部分阅读中，重点是固定项目/产品以及支持持续开发的任务。不断在新项目上进行开发的业务使用哪些类型的流程？他们没有使用这些类型的流程吗？
虽然主构建脚本在构建服务器上存在，但它们使用起来很笨拙。此外，我更愿意限制对构建服务器的控制台访问。因此，需要一些管理系统来提供更容易的访问，以便在中央系统上触发任意构建。
我意识到我正在寻找的东西可能属于MS Team Build的封面。不幸的是，每当我开始阅读它时，当我开始进入MS营销材料并迅速迷失方向时，我会感受到流沙感，从未真正发现我想做的事情是否可以完成。此外，在过去关于Team Foundation Server和Team System主题的一些一般性讨论中，许可成本已经成为一个可能的阻碍。
我很想听到解决这个问题的人可能会提出建议。我已经在基于我的主“构建任何项目”构建脚本的集中构建系统上做了一些工作。但是，我所拥有的只是处于起步阶段，而且主要是为了支持我所从事的项目类型。此时缺少必要的支持来处理许多应用程序类型或Visual Studio可能提供的大量项目/解决方案配置。
答案 0 :(得分：3)
我看到中央构建系统遇到的最大问题是，即使拥有世界上最好的意愿，工具也会在团队之间或随着时间的推移而分歧。
我赞成为特定项目设计任何构建系统，以便它需要签出单个模块，例如。 MyProjectBuildEnvironment，然后以非常工具中立的方式运行单个脚本，例如在Windows系统build.bat
上只要有可能，构建环境使用的所有工具都应该只需通过签出模块MyProjectBuildEnvironmen就可以运行，而不需要机器级安装程序。
这两个限制不会妨碍团队在特定时间使用他们喜欢的工具的自由。
中央构建系统可以是一个简单的系统，每个项目检出一个模块，只需执行build.bat文件。你可以称之为元构建系统。
说实话，它可能有点过分，因为描述每个项目的构建模块名称的简单wiki就足以允许任何人签出那个模块并通过常见的build.bat命令启动它。
作为最后一点，启动构建的脚本应该始终检查环境并告诉用户是否缺少任何工具或者需要调整任何机器配置才能成功完成构建。