改善您的构建过程

Question

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

目前，这几乎是我的小组面临的情况。我们主要进行网络应用程序开发（但目前没有桌面开发）。即使使用我们适中的应用程序，软件部署也很难并且笨拙，而且我在这个团队（和公司）的两年中遇到了太多问题。现在已经过去了，我们可以一箭双雕杀死两只乔尔测试鸟（每日构建和一步构建，两者都不以任何形式存在）。

什么这里经过，我是在各种各样的事情，我需要做或思考，从谁已经在软件开发的时间比我有，也有更大的大脑有些人一般见识。我相信这将成为目前发布在测试版中的大部分人员。

相关的工具： 视觉构建 源安全6.0（我知道，但我不能做，我们是否不使用Source Safe中的任何内容，这可能是接下来的战斗我打。）

姑且，我有一个视觉构建项目，这是否：

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

我仍然需要哄一些从Visual Build中注销所有这些，但我还没有达到我需要做的那一点。

有没有人有任何意见或建议，使？我会注意到，我们目前没有使用部署项目。它会删除我假设的这个版本中的一些必要步骤（比如web.config交换）。

Answer 1

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

1. 首先使用自动化构建程序（即nant/msbuild）通过一步来编译代码。我不打算辩论哪一个更好。找到一个让你感觉舒服并使用它的人。构建脚本与源代码控制中的项目一起生活。
2. 找出您希望如何触发自动构建。无论是将其连接到CruiseControl或使用计划任务运行每晚构建任务。 CruiseControl或TeamCity可能是最好的选择，因为它们包含许多工具，可用于简化此步骤。 CruiseControl是免费的，TeamCity是免费的，您可能需要为此付费，具体取决于项目的规模。
3. 好吧，到了这一点，你会对这些工具感到非常舒服。现在您已经准备好根据您想要做的测试，部署等来添加更多任务...

希望这有助于您。

Answer 2

我有一套Powershell脚本，为我做这些。

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

脚本2：软件包 - 这一个需要各种参数来为各种环境（例如测试）打包发布，以及由许多机器组成的生产环境的子集。

脚本3：部署 - 这是由包脚本创建的文件夹中的每个单独的机器上运行（部署脚本复制作为包装的一部分）

从部署脚本，我做理智检查诸如机器名称之类的东西，所以事情不会意外地被部署到错误的地方。

对于web.config文件中，我使用

<appSettings file="Local.config"> 

功能有那些已经在生产机器替代，他们是只读的，所以他们不会意外覆盖。 Local.config文件没有签入，我不必在构建时进行任何文件切换。

[编辑]的appSettings文件的当量=一个配置部分是configSource =“Local.config”

Answer 3

我只上了几个.NET项目的工作（我已经做了大部分的Java），但我建议的一件事是使用像NAnt这样的工具。我将构建连接到IDE时遇到了一个实际问题，它最终导致建立构建服务器变得非常痛苦，因为您必须在任何想要从未来。

这就是说，任何自动构建比没有自动构建要好。

Answer 4

两年前我们从使用perl脚本切换到MSBuild，并没有回头。 构建Visual Studio解决方案可以通过在主XML文件中指定它们来完成。你可以在.net中创建一个新的类，从任务中重写Execute函数，然后引用这来自你的build xml文件。

有一个相当不错的介绍在这里： introduction

Answer 5

我们的构建过程是一堆已经发展了十年左右的自产自销的Perl脚本，没有什么幻想，但它能够完成任务。一个脚本获取最新的源代码，另一个脚本创建它，第三个脚本将其转移到网络位置。我们进行桌面应用程序开发，所以我们的分期过程还构建了用于测试的安装程序包，并最终向客户交付。

我建议你把它分解成单独的步骤，因为有些时候你想重建但没有得到最新的，或者只是需要重新阶段。我们的脚本还可以处理来自不同分支的构建，因此可以考虑使用您开发的任何解决方案

最后，我们有一个专门的生成机器，每天晚上重建干线和维护分支，并发送任何问题或成功完成的电子邮件。

Answer 6

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

如果思想不吓唬读者，然后（他们要么是疯了还是），他们或许可以得到令+“你最喜欢的字符串压榨机”为他们工作。

Answer 7

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

我说这二/三我看到球队只是在服务器上运行最新版本的构建脚本，但不仅不会把它的源代码控制，或当他们这样做，他们只检查它在一个随机的基础上。如果你让构建过程从源代码控制中“获得”，它会迫使你保留最新最好的构建脚本。

Answer 8

我们使用UppercuT。 UppercuT使用NAnt构建，使用非常简单。

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

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