27

或者，实际上在没有太多合适的开始时建立一个构建过程。

目前，这几乎就是我的团队所面临的情况。我们主要进行网络应用程序开发（但目前没有桌面开发）。即使使用我们普通的应用程序，软件部署也很丑陋且笨拙，而且在我加入这个团队（和公司）的两年里，我们遇到了太多的问题。现在是时候做点什么了，结果是我们将能够用一块石头杀死两只乔尔测试鸟（每日构建和一步构建，两者都不以任何形式存在）。

我在这里寻求的是对我需要做或考虑的事情的一些一般性见解，来自那些从事软件开发的时间比我更长并且大脑也更大的人。我相信目前大多数在测试版中发帖的人都会这样做。

相关工具：Visual Build Source Safe 6.0（我知道，但我目前对是否使用 Source Safe 无能为力。这可能是我的下一场战斗。）

暂时，我有一个 Visual Build 项目可以做到这一点：

  1. 获取源并放置在本地目录中，包括项目所需的必要 DLL。
  2. 获取配置文件并根据需要重命名（我们将它们存储在不属于实际应用程序的特殊子目录中，并根据用途命名）。
  3. 使用 Visual Studio 构建
  4. 使用命令行预编译，复制到“构建”目录中
  5. 复制到目的地。
  6. 获取任何必要的附加资源 - 主要是与项目相关的文档、图像和报告（并从步骤 5 放入目录）。有很多这样的东西，我以前不想包括它。但是，我只会复制更改的项目，所以可能无关紧要。我不确定我是否真的想在前面的步骤中包含这些内容。

对于所有这些，我仍然需要诱使一些注销 Visual Build，但我还没有到需要这样做的地步。

有没有人有任何意见或建议？我会注意，我们目前没有使用部署项目。我认为它会删除此构建中的一些必要步骤（如 web.config 交换）。

4

8 回答 8

18

当承担一个从未有过自动化构建过程的项目时，分步进行会更容易。不要试图一次吞下太多，否则会感到难以承受。

  1. 首先使用自动构建程序（即 nant/msbuild）一步编译您的代码。我不会讨论哪个更好。找一个让你感觉舒服的并使用它。让构建脚本与源代码控制中的项目一起使用。
  2. 弄清楚您希望如何触发自动构建。无论是将其连接到 CruiseControl 还是使用计划任务运行夜间构建任务。CruiseControl 或 TeamCity 可能是最好的选择，因为它们包含许多工具，您可以使用它们来简化此步骤。CruiseControl 是免费的，TeamCity 在某种程度上是免费的，您可能需要根据项目的规模付费。
  3. 好的，到此为止，您将对这些工具感到非常满意。现在您已准备好根据您想要为测试、部署等执行的操作添加更多任务......

希望这可以帮助。

于 2008-08-18T18:07:27.763 回答
9

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

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

脚本 2：打包 - 这个脚本采用各种参数来打包各种环境的版本，例如测试，以及由许多机器组成的生产环境的子集。

脚本 3：部署 - 在包脚本创建的文件夹内的每台机器上运行（部署脚本作为打包的一部分复制进来）

从部署脚本中，我对机器名称等内容进行完整性检查，以免意外部署到错误的位置。

对于 web.config 文件，我使用

<appSettings file="Local.config">

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

[编辑] 配置部分的 appSettings file= 等效项是 configSource="Local.config"

于 2008-08-18T16:55:46.457 回答
5

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

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

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

于 2008-08-18T17:11:15.740 回答
1

我只从事过几个 .Net 项目（我主要从事 Java），但我推荐的一件事是使用像NAnt这样的工具。我在将我的构建与 IDE 耦合时遇到了一个真正的问题，它最终使得在路上设置构建服务器变得非常痛苦，因为你必须在你想要构建的任何盒子上进行完整的 VS 安装未来。

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

于 2008-08-18T16:58:47.137 回答
1

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

我建议您将其分解为单独的步骤，因为有时您想重建但不想获得最新的，或者可能只需要重新上演。我们的脚本还可以处理来自不同分支的构建，因此请考虑您开发的任何解决方案。

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

于 2008-08-18T17:23:13.560 回答
1

我建议确保您的构建脚本（和安装程序项目，如果与您的情况相关）在源代码控制中。我倾向于有一个非常简单的脚本，它只是检查\获取最新的“主”构建脚本，然后启动它。

我说这个 b/c 我看到团队只是在服务器上运行最新版本的构建脚本，但要么从未将其置于源代码控制中，要么当他们这样做时，他们只是随机签入。如果您将构建过程从源代码控制中“获取”，它将迫使您在其中保留最新和最好的构建脚本。

于 2008-08-29T18:26:25.133 回答
0

我们的构建系统是一个（或两个）makefile。让它工作起来相当有趣，因为它需要在两个窗口（作为 VS 下的构建任务）和 Linux 下（作为普通的“make bla”任务）运行。真正有趣的是构建从 .csproj 文件中获取实际的文件列表，从中构建（另一个）makefile，然后运行它。在这个过程中，make 文件实际上称它为 self。

如果这个想法没有吓到读者，那么（要么他们疯了，要么）他们可能会得到 make +“你最喜欢的字符串处理者”来为他们工作。

于 2008-08-18T17:42:45.113 回答
0

我们使用 Uppercut。UppercuT 使用 NAnt 构建，非常容易使用。

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

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

于 2009-05-16T18:54:49.077 回答