关于Visual Studio：集中/控制.NET项目和解决方案的任意生成

多年来，我创建并调整了一组NAnt脚本以执行完整的项目构建。主脚本采用单个应用程序端点(例如，一个Web应用程序项目)，并从源代码控制中对其进行完整构建。脚本预先配置了与构建输出位置，源代码控制地址等有关的必要信息。要点是，您可以提供很少的信息并从头开始构建给定的项目。这满足了我问题的"任意"部分。

好的。

过去，我曾在生产几种软件产品(主要是Web应用程序)的公司工作。这种环境非常适合典型的连续集成设置，其中每个产品都有一个集成器。我已经设置了集成商以充当CI构建，也设置了集成商来处理完整的发布候选版本和QA部署。这些集成商使用主构建脚本，因此，集成商本身仅是源代码控制监视和对主NAnt脚本的调用。

好的。

我现在在一个创建许多应用程序的开发小组工作。通常，要求开发人员支持其他人最初构建的应用程序。我刚开始时没有构建管理。作为一个业务部门的产品套件(大约六套完整的系统)的四人团队的首席开发人员，我在集团中的职位特别独特。我已经使用主构建脚本实现了CruiseControl.Net，以同时进行CI构建和RC构建。该项目可在企业产品套件中的固定项目集合中找到。

好的。

我已经使用CCNet多年了，因此我完全知道它可以做什么。我将其用于我的产品套件中的所有项目，因此非常感谢它对持续集成领域的贡献。我向我的团队强调，使用官方的RC构建集成商作为主构建器，可以运用于除开发以外的任何位置。这样可以很好地控制CCNet所控制的固定项目集。

好的。

但是，还有其他开发人员在构建其他应用程序。其中一些是1开发人员项目，直到进入项目生命周期时，它们才经常处于源代码控制中(我正在尝试进行其他更改)。这些项目中有许多都是一次性的，一旦部署，就不会有很多生命。尽管如此，仍然需要他们的支持。支持这些功能的一个不可缺少的事实是，如果不对这些项目进行集中的构建管理，则要进行质量检查和最终生产的候选发布版本将留在单独的开发人员机器上进行。当然，这为开发人员构建机器的其他因素提供了零保证，即一切都在源代码控制中。

好的。

我一直试图解决的问题是：我可以使用哪种系统对这些任意构建进行集中控制？这绝对不是一个唯一的问题。但是，在我所做的有关集中式构建，构建自动化和持续集成的大部分阅读中，重点都放在固定的项目/产品以及支持其持续开发的任务上。在新项目上不断进行开发的企业使用什么类型的流程？他们不使用这些类型的过程吗？

好的。

虽然主构建脚本确实存在于构建服务器上，但它们使用起来很笨拙。另外，我更希望将控制台访问权限限制在构建服务器上。因此，需要一些管理系统来简化在中央系统上任意构建的部署。

好的。

我意识到我正在寻找的东西可能隐藏在MS Team Build的掩盖之下。不幸的是，每当我开始阅读它时，当我开始进入MS营销材料并很快迷失方向时，都会有种流沙的感觉，从来没有真正发现我想要做的事是否可以用它完成。另外，在过去有关Team Foundation Server和Team System的一般讨论中，许可成本已被视为可能的阻碍。

好的。

我热切希望收到解决此问题的任何人的建议。我已经基于我的主" build-any-project"构建脚本在集中化构建系统上做了一些工作。但是，我所处的还处于起步阶段，其构建目的主要是仅支持我从事的项目类型。在这一点上，缺乏处理许多应用程序类型或Visual Studio可能存在的过多项目/解决方案配置所需的支持。

好的。

好。

---

我在中央构建系统中看到的最大问题是，即使拥有世界上最好的意愿，工具也会在团队之间或随着时间的流逝而出现差异。

我喜欢为特定项目设计任何构建系统，例如，它需要签出单个模块。 MyProjectBuildEnvironment，然后以工具中立的方式运行单个脚本，例如在Windows系统上build.bat

只要有可能，只需通过检出MyProjectBuildEnvironmen模块即可运行构建环境使用的所有工具，而不需要机器级别的安装程序。

这两个限制不会妨碍团队在给定时间使用他们喜欢的工具的自由。

然后，中央构建系统可以是一个简单的系统，可以为每个项目检出一个模块，并简单地执行build.bat文件。您可以将其称为元构建系统。

老实说，它可能是一个简单的维基，它描述了每个项目的构建模块名称，足以让任何人签出该模块并通过通用的build.bat命令将其启动。

最后要注意的是，开始构建的脚本应始终检查环境，并告诉用户是否缺少任何工具或需要调整任何计算机配置以成功完成构建。

---