我想在构建过程中完成两件事：
我已经查看了一些资源，并没有什么能够成为这个场景的最佳解决方案。我的大多数搜索围绕着目标的web.config部分，但如果我要这样做，我想同时完成单元测试。
Scott Hanselman发表了一篇文章，介绍如何制作配置文件的多个副本，创建自定义配置，以及使用批处理文件复制web.config，使配置与源对齐。我不喜欢这个解决方案，因为我必须拥有相同文件的多个版本，并且有可能会更新，而另一个则不会。
使用nAnt看起来很有前景。从我收集的内容中，我将使用批处理文件作为构建过程的一部分。使用xml文件中的变量替换文件模板中的{template}变量对我来说似乎非常简单，所以我想我倾向于使用MSBuild。我关心的是环境配置，多个开发人员需要将nant程序集放在同一个位置，因此应将它们检入源代码控制。这听起来不错。
我遇到了CruiseControl，乍一看看起来很有趣，但似乎需要大量的学习。
我意识到这是一个非常雄心勃勃的目标，需要付出一些努力来纠正，所以我想在选择路径之前做出明智的决定。对于使用测试和文件配置启动和运行自动构建过程最简单，最干净的方法的任何建议都将不胜感激，谢谢。
答案 0 :(得分：12)
对于初学者来说，这不是一个雄心勃勃的目标，这是一个很好的支持工具。因此，您正走在正确的轨道上，并且非常善于确定您的优先事项。
首先，如果可以帮助，请不要使用bat文件。蝙蝠脚本语言很糟糕。它中缺少许多语言结构，很难做任何复杂的事情。专家可以使用bat做很多事情，但我在构建系统中使用bat脚本的经验是它们普遍无法维护。
您需要编写许多操作系统级别的脚本来将所有这些放在一起，但是您需要一种可靠的编程语言来实现它。建议包括：
nAnt是管理构建步骤的好工具。事实上，配置xml被检入，分支，合并，与所有其余部分分开是一个巨大的优势。
Make和Scons也是很好的工具。
关于这些脚本的几点说明。他们应该有干净的输出和良好的错误信息。我的意思是错误消息。您不能花太多时间编写提供良好错误消息的构建脚本。认真。此外，请仔细管理您的操作系统错误代码，并确保每个构建命令在失败时引发错误代码。所有CI服务器都将使用它来标记失败的构建。如果在步骤2中失败，但在步骤10之前没有引发错误代码，则很难进行调试。
是的，它们应该是您构建的一部分。如今，在太阳下存在一种针对每种编程语言的单元测试框架，它们都在命令行中运行。因此，选择一个看起来最好的，你就可以了。
一旦你的构建过程到了一个点，你可以坐下来命令shell并获得一个完整的构建，从Soup到Nuts（即从源代码到可发送），那么是时候看看他们所谓的了什么持续集成工具/服务器。 Jenkins是一个很好的，Cruise Control和Buildbot也是如此。我已经全部使用它们了，它们很好，选择一个然后继续使用它们。一旦你开始，他们就不那么难学了，他们管理了很多你要求的通知内容。要记住的主要事情是它们都是用于执行和报告命令行参数（或多或少）
构建构建过程时，请记住它包含四个基本步骤：
如果您将配置管理归结为一个文件，请采取措施。这将为您带来丰厚的回报。你说你不想维护三个不同的文件。您能否确定一组将一个基本文件转换为三个要发布的文件的规则？如果是这样，那么您可以编写一个脚本，在打包阶段为您进行转换。还记得当我说“不要使用蝙蝠文件吗？”这是bat文件很糟糕的事情，这些类型的任务总是会进入构建系统。
最后，请记住，所有这一切的要点是：
一个。确保提交代码和交付产品之间没有手动步骤。人们在这方面很可怕。他们犯错误，他们不会一直在周末工作，这样的事情。
湾为开发人员提供快速，全面，具体的反馈，他们提交的内容将起作用。
祝你好运！答案 1 :(得分：0)
如果您想合并web.config文件，我建议使用中描述的过程 http://blog.jpboodhoo.com/NAntStarterSeries.aspx
基本上，您有一个xml文件，在本例中称为local.properties.xml，它具有每个环境更改的所有值。这是一个在每个环境中都不同的文件。您从源代码管理中删除web.config。您有一个web.config.template文件，其中包含常见的web.config结构并将其添加到源代码管理中。您可以使用Nant的内置功能来复制文件，并通过filterchain进行变量替换，以便在构建过程中动态生成web.config文件。