设置集成服务器，我对使用多个任务完成构建的最佳方法存有疑问。是只有一个大工作或制造小型工作的最佳方法吗？
答案 0 :(得分：3)
你绝对想要分手。这是CruiseControl.NET配置的一个很好的例子，它为每个步骤提供不同的目标（任务）。它还使用common.build文件，该文件可以在几乎没有自定义的项目之间共享。
http://code.google.com/p/dot-net-reference-app/source/browse/#svn/trunk
答案 1 :(得分：1)
我将TeamCity与nant构建脚本一起使用。 TeamCity可以轻松设置CI服务器部分，而就构建报告而言，nant构建脚本可以轻松完成许多任务。
这篇文章是我写的一篇关于在CruiseControl.NET中使用CI的文章，它在评论中有一个非常有用的构建脚本，可以跨项目重复使用：
答案 2 :(得分：1)
我赞成的方法是以下设置（实际上假设您在.NET项目中）：
在许多项目中，您发现当有人进行签到时，会发生不同级别的测试和活动。有时这些可能会在构建之后很长一段时间内增加，然后开发人员可以看到他们是否已经通过签入破坏了构建。
在这些情况下我做的是创建三个版本（或者两个版本）：
任何CI系统的关键在于它需要是有机的并且不断被调整。 CruiseControl.NET有一些很棒的扩展，可以记录和绘制构建时间等步骤，让你进行历史分析，让你不断调整构建以保持它们的活泼。这是经理人难以接受的事情，一个构建盒可能会让你忙于工作时间的五分之一，只是为了阻止它停止运转。
答案 3 :(得分：1)
我们使用buildbot，将构建细分为不连续的步骤。在构建步骤以足够的粒度细分并成为一个完整的单元之间可以找到平衡点。
例如，在我目前的职位上，我们在各自的平台上为我们的每个平台（Mac，Linux，Windows）构建子部件。然后我们只有一个步骤（有几个子步骤）将它们编译成最终版本，最终版本将在最终版本中结束。
如果在任何这些步骤中出现问题，很容易诊断。
我的建议是尽可能以模糊的术语在白板上写出步骤，然后根据这些步骤进行操作。在我的情况下，这将是：
答案 4 :(得分：0)
我肯定会打破工作。您有可能在构建中进行更改，如果您有较小的任务而不是搜索整体构建，则可以更轻松地跟踪问题。
无论如何，你应该可以用较小的作品创造一个大工作。
答案 5 :(得分：0)
天儿真好，
当您谈论集成测试时，我的大（明显）提示是尽可能使测试服务器尽可能地靠近部署环境进行构建和配置。
</thebloodyobvious> (-:
欢呼声， 罗布
答案 6 :(得分：0)
将您的任务分解为离散的目标/操作，然后使用更高级别的脚本将它们全部绑定在一起。
这使得您的构建过程更容易被其他人理解（您正在记录，因此团队中的任何人都可以提取它，对吗？），以及增加重复使用的可能性。您可能不会重复使用高级脚本（尽管如果您有类似的项目，这可能是可能的），但您可以很容易地重复使用（即使它是复制/粘贴）离散操作。
考虑从存储库获取最新源代码的示例。您需要将用于检索代码的任务/操作分组，并使用一些日志记录语句并引用相应的帐户信息。这是从一个项目到下一个项目很容易重用的东西。
对于我团队的环境，我们使用NAnt，因为它在开发机器（我们编写/调试脚本）和CI服务器之间提供了一个通用的脚本环境（因为我们只是在干净的环境中执行相同的脚本）。我们使用Jenkins来管理我们的构建，但是在它们的核心，每个项目只是调用相同的NAnt脚本，然后我们操作结果（即归档构建输出，标记失败的测试等）。