Visual Studio 2008 Professional构建过程

我想在构建过程中完成两件事:

运行单元测试 - 我有一个带有单元测试的测试项目.我想在构建时运行所有这些测试,并在构建验证失败时收到通知.

合并web.config文件 - 我有3个不同的环境,每个环境都有特定于每个的配置详细信息.我想根据Web应用程序的部署位置生成配置文件.

我已经查看了一些资源,并没有什么能够成为这个场景的最佳解决方案.我的大多数搜索围绕着目标的web.config部分,但如果我要这样做,我想同时完成单元测试.

Scott Hanselman发表了一篇文章,关于制作配置文件的多个副本,创建自定义配置,以及使用批处理文件复制web.config,使配置与源对齐.我不喜欢这个解决方案,因为我必须有相同文件的多个版本,并且有可能一个更新而另一个没有.

使用nAnt看起来很有希望.从我收集的内容中,我将使用批处理文件作为构建过程的一部分.使用xml文件中的变量替换文件模板中的{template}变量对我来说似乎非常简单,所以我想我倾向于使用MSBuild.我关心的是环境配置,多个开发人员需要将nant程序集放在同一个位置,因此应将它们检入源代码控制.这对我来说听起来不错.

我跑过CruiseControl,乍一看看起来很有趣,但似乎需要大量的学习.

我意识到这是一个非常雄心勃勃的目标,需要一些努力来纠正,所以我想在选择路径之前做出明智的决定.对于使用测试和文件配置启动和运行自动构建过程最简单,最干净的方法的任何建议都将不胜感激,谢谢.

对于初学者来说,这不是一个雄心勃勃的目标,这是一个很好的支持工具.因此,您正走在正确的轨道上,并且非常善于确定您的优先事项.

脚本

首先,如果可以帮助,请不要使用bat文件.蝙蝠脚本语言很糟糕.它中缺少许多语言结构,很难做任何复杂的事情.专家可以用蝙蝠做很多事情,但我在构建系统中使用bat脚本的经验是它们普遍无法维护.

您将需要编写许多操作系统级别的脚本来将所有这些组合在一起,但是您需要一种可靠的编程语言来实现它.建议包括:

电源外壳

蟒蛇

Bash(即cygwin)

nAnt是管理构建步骤的好工具.事实上,配置xml被检入,分支,合并,与所有其余部分分开是一个巨大的优势.

Make和Scons也是很好的工具.

关于这些脚本的几个注释.他们应该有干净的输出和良好的错误信息.我的意思是错误消息.您不能花太多时间编写提供良好错误消息的构建脚本.认真.此外,请仔细管理您的操作系统错误代码,并确保每个构建命令在失败时引发错误代码.所有CI服务器都将使用它来标记失败的构建.如果在步骤2中失败,但在步骤10之前没有引发错误代码,则调试非常困难.

单元测试

是的,它们应该是您构建的一部分.如今,在太阳下存在一种针对每种编程语言的单元测试框架,它们都在命令行中运行.因此,选择一个看起来最好的,你正在路上.

持续集成

一旦你的构建过程到了一个点,你可以坐下来命令shell并获得一个完整的构建,从Soup到Nuts(即从源代码到可交付),那么是时候看看他们称之为持续集成工具了/服务器.Jenkins是一个很好的,Cruise Control和Buildbot也是如此.我已经全部使用它们了,它们很好,选择一个然后继续使用它们.一旦你开始,他们就不那么难学了,他们管理了很多你要求的通知内容.要记住的主要事情是它们都是用于执行和报告命令行参数(或多或少)

构建构建过程时,请记住它包含四个基本步骤:

从存储库中获取代码

预建; 更新版本号等

编译/建筑

后期生成; 打包; 拉上构建产品,制作.iso图像等

发布:将构建产品移动到人们可以找到它们的位置(在您的情况下是Web服务器)

配置文件

如果您将配置管理归结为一个文件,请鞠躬.这将为您带来丰厚的回报.你说你不想维护三个不同的文件.您能否确定一组将一个基本文件转换为三个要发布的文件的规则？如果是这样,那么您可以编写一个脚本,在打包阶段为您进行转换.还记得当我说"不要使用蝙蝠文件吗？" 这是蝙蝠文件很糟糕的事情,这些类型的任务总是在构建系统中找到它们的方式.

结论

最后,请记住,所有这一切的要点是:

一个.确保提交代码和交付产品之间没有手动步骤.人们在这方面很可怕.他们犯错误,他们不会一直在周末工作,这样的事情.

湾 为开发人员提供快速,全面,具体的反馈,他们提交的内容将有效.

祝好运!