集中/控制.NET项目和解决方案的任意生成

多年来,我创建并调整了一组NAnt脚本来执行完整的项目构建。主脚本采用单个应用程序端点(例如web应用程序项目)并从源代码管理中完成它的构建。脚本预先配置了有关生成输出位置、源代码管理地址等的必要信息。主要的一点是,您可以向它提供很少的信息,并从头开始生成给定的项目。这就满足了我问题的“武断”部分。

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

我现在为一个开发小组工作,这个小组创建了许多应用程序。通常,开发人员需要支持最初由其他人构建的应用程序。当我开始的时候,还没有建立管理。作为一个业务部门产品套件(大约6个完整系统)的4人团队的首席开发人员,我在集团内处于一个特别独特的位置。我已经用主构建脚本实现了CruiseControl.Net,用于执行CI构建和RC构建。这项工作适用于企业产品套件中的固定项目集。

我已经使用CCNet很多年了,所以我完全知道它能做什么。我非常尊重它对持续集成领域的贡献,因为我将它用于我的产品套件中的所有项目。我已经向我的团队强调使用官方的RC构建集成器作为主构建器,用于任何目的地,而不是开发。这提供了对CCNet控制下的固定项目集的极大控制。

不过,也有其他开发人员在构建其他应用程序。其中一些是1个开发人员项目,在进入项目生命周期之前,这些项目通常甚至不在源代码管理中(我正在尝试更改其他内容)。这些项目中的许多都是一次性的,在部署之后就不会有太多的生命在开发中了。尽管如此,他们仍然需要支持。支持这些功能的一个不可分割的事实是,如果没有对这些项目进行集中的构建管理,那么提交给QA并最终进行生产的候选发布版本就只能在单独的开发人员机器上完成。当然,除了开发人员机器构建的其他因素外,这也为一切都在源代码管理中提供了零保证。

我一直试图解决的问题是:我可以使用什么样的系统来集中控制这些任意的构建?这绝对不是一个独特的问题。然而,在我所读的大部分关于集中构建、构建自动化和持续集成的文章中,重点放在固定的项目/产品以及支持其持续开发的任务上。在不断开发新项目的企业使用什么类型的流程?他们不使用这些类型的流程吗?

虽然主构建脚本确实位于构建服务器上,但它们使用起来很笨拙。另外,我希望限制对生成服务器的控制台访问。因此,需要一些管理系统来提供更方便的访问,以便在中央系统上触发任意构建。

我知道我要找的东西可能藏在MS Team Build的封面下。不幸的是,每当我开始阅读这本书的时候,当我开始接触微软的营销材料,很快就迷失了方向,从来没有真正发现我想做的是不是可以用它来完成。另外,在过去一些关于TeamFoundationServer和TeamSystem主题的一般性讨论中,许可成本可能是一个阻碍因素。

我很想听听谁解决了这个问题谁可以提供建议。我已经做了一些工作,在一个集中构建系统的基础上,我的主“建立任何项目”构建脚本。然而,我所拥有的是在它的婴儿期,并且主要是为了支持我工作的项目类型。目前缺乏处理许多应用程序类型所需的支持,或者Visual Studio中可能存在的大量项目/解决方案配置。