多年来，我创建并调整了一组 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 可能的大量项目/解决方案配置所需的支持。