改善构建过程

Improving Your Build Process

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

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

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

相关工具：
视觉构建
Source Safe 6.0(我知道，但是我目前无法使用Source Safe。我可能会打下一场战斗。)

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

获取源代码并将其放置在本地目录中，包括项目所需的必要DLL。

获取配置文件并根据需要重命名(我们将它们存储在不属于实际应用程序的特殊子目录中，并且根据用途进行命名)。

使用Visual Studio进行构建

使用命令行进行预编译，然后复制到"构建"目录中

复制到目的地。

获取任何必要的其他资源-大多数与项目相关联的文档，图像和报告之类的东西(并从第5步放到目录中)。这些东西很多，我以前不想包括在内。但是，我将仅复制更改的项目，因此也许无关紧要。我不确定我是否真的想在早期步骤中包含这些内容。

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

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

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

首先使用自动化构建程序(即nant / msbuild)一步一步进行代码编译。我不会讨论哪个更好。找到一个令您感到舒适的东西并使用它。在源代码管理中将构建脚本与项目一起使用。

弄清楚如何触发自动构建。无论是将其连接到CruiseControl还是使用"计划任务"运行夜间构建任务。为此，CruiseControl或TeamCity可能是最佳选择，因为它们包括许多工具，您可以使用这些工具来简化此步骤。 CruiseControl是免费的，TeamCity是免费的，根据项目的规模，您可能需要为此付费。

好的，到此为止，您将对这些工具非常满意。现在，您可以根据要执行的测试，部署等操作添加更多任务。

希望这可以帮助。

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

脚本1：构建-这很简单，主要是通过调用msbuild来处理的，它还创建了我的数据库脚本。

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

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

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

对于web.config文件，我使用

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

[编辑]相当于配置部分的appSettings file =是configSource =" Local.config"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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