或者，实际上在没有太多准备的情况下建立构建过程。

目前，这就是我小组所面临的情况。我们主要进行Web应用程序开发(但目前不进行桌面开发)。即使使用适度的应用程序，软件部署也很丑陋和笨拙，而且在我加入该团队(和公司)的两年中，我们遇到了太多问题。对此已经过去了，其结果是，我们将能够用一块石头杀死两只乔尔测试鸟(每日构建和一步构建，两种形式都不存在)。

我所追求的是，​​从从事软件开发工作的时间超过我并且也拥有更强的头脑的人那里，我对我需要做的事情或者正在思考的事情有​​一些一般的了解。我有信心将会成为目前在测试版中发布的大多数人。

相关工具：
视觉构建
Source Safe 6.0(我知道，但是我目前无法使用Source Safe进行任何操作。这可能是我接下来的战斗。)

暂时，我有一个Visual Build项目可以执行以下操作：

• 获取源代码并将其放置在本地目录中，包括项目所需的必要DLL。
• 获取配置文件并根据需要重命名(我们将它们存储在不属于实际应用程序的特殊子目录中，并根据用途进行命名)。
• 使用Visual Studio进行构建
• 使用命令行进行预编译，然后复制到"构建"目录中
• 复制到目的地。
• 获取任何必要的其他资源-大多数与项目相关联的文档，图像和报告之类的东西(并从第5步放到目录中)。这些东西很多，我以前不想包括在内。但是，我将仅复制更改的项目，因此也许无关紧要。我不确定我是否真的想在早期步骤中包含这些内容。

对于所有这些，我仍然需要从Visual Build中退出，但是现在还不需要这样做。

有人有什么建议或者建议吗？我会注意，我们当前未使用"部署项目"。我认为此构建将删除一些必需的步骤(例如web.config交换)。

解决方案

回答

我有一组Powershell脚本可以为我完成所有这些工作。

脚本1：构建此脚本很简单，它主要由对msbuild的调用来处理，并且还创建了我的数据库脚本。

脚本2：打包该包采用各种参数来打包针对各种环境(例如测试)和生产环境的子集的发行版，该环境由许多机器组成。

脚本3：部署在Package脚本创建的文件夹中的每台机器上运行(Deploy脚本作为包装的一部分复制到其中)

在部署脚本中，我对机器名称之类的内容进行了完整性检查，以确保不会将它们意外地部署到错误的位置。

对于web.config文件，我使用

<appSettings file="Local.config">

功能具有生产机器上已经存在的替代，并且它们是只读的，因此不会被意外覆盖。 Local.config文件未签入，并且在构建时不必进行任何文件切换。

[编辑]相当于config节的appSettings file =是configSource =" Local.config"

回答

我只从事过几个.Net项目(我大部分都做过Java)，但是我建议使用的是NAnt之类的工具。将我的构建耦合到IDE时遇到了一个真正的问题，这最终使我们很难在以后设置构建服务器，因为我们必须在要从中构建的任何盒子上进行完整的VS安装。未来。

话虽如此，任何自动化构建都比没有自动化构建要好。

回答

两年前，我们从使用Perl脚本切换为MSBuild，并且没有回头。
只需在主xml文件中指定它们，即可完成Visual Studio解决方案的构建。

对于任何更复杂的事情(获取源代码，执行单元测试，构建安装包，部署网站)，我们只需在.net中创建一个继承自Task的新类，该类将覆盖Execute函数，然后从构建xml文件中引用该类。 。

这里有一个很好的介绍：
介绍

回答

我们的构建过程是一堆自家开发的Perl脚本，这些脚本已经发展了十多年左右，没什么花哨的东西，但它能完成工作。一个脚本获取最新的源代码，另一脚本构建它，第三脚本将其转移到网络位置。我们进行桌面应用程序开发，因此我们的暂存过程还构建了用于测试并最终交付给客户的安装程序包。

我建议我们将其分解为各个步骤，因为有时我们想重建而不是最新，或者只是需要重新登台。我们的脚本还可以处理来自不同分支的构建，因此请考虑我们开发的任何解决方案。

最终，我们有一台专用的构建机器，该机器每晚都会重建主干和维护分支，并发送一封有任何问题或者是否成功完成的电子邮件。

回答

我们的构建系统是一个makefile(或者两个)。使它正常工作非常有趣，因为它需要同时在Windows(作为VS下的构建任务)和Linux(作为常规的" make bla"任务)上运行。真正有趣的是，构建从.csproj文件获取实际文件列表，从中构建(另一个)makefile，然后运行该文件。在该过程中，make文件实际上将其称为自身。

如果这种想法不会吓到读者，那么(他们或者疯了，或者)他们可能会得到make +"我们最喜欢的字符串mangler"来为他们工作。

回答

在进行从未具有自动构建过程的项目时，分步进行将更容易。不要一次吞咽太多，否则会感到不知所措。

• 首先使用自动化构建程序(即nant / msbuild)一步一步完成代码的编译。我不会辩论哪个更好。找到一个令我们感到舒适的东西并使用它。在源代码管理中将构建脚本与项目一起使用。
• 弄清楚如何触发自动构建。无论是将其连接到CruiseControl还是使用计划任务运行夜间构建任务。为此，CruiseControl或者TeamCity可能是最佳选择，因为它们包含许多可用于简化此步骤的工具。 CruiseControl是免费的，TeamCity是免费的，根据项目的规模，我们可能需要为此付费。
• 好的，到此为止，我们将对这些工具非常满意。现在，我们准备根据测试，部署等操作添加更多任务。

希望这可以帮助。

回答

我建议确保构建脚本(和安装程序项目，如果我们需要的话)在源代码控制中，这是一件事。我倾向于使用一个非常简单的脚本，该脚本只检出\最新的"主"构建脚本，然后启动它。

我说这个b / c我看到团队只是在服务器上运行最新版本的构建脚本，但是他们从未将其放到源代码管理中，或者在执行时只随机检查了它们。如果我们使构建过程从源代码控制中"获取"，它将迫使我们在其中保留最新最好的构建脚本。

回答

我们使用UppercuT。
UppercuT使用NAnt进行构建，并且非常易于使用。

http://code.google.com/p/uppercut/

这里有一些很好的解释：UppercuT