设置集成测试服务器的最佳方法是什么？
设置集成服务器，我对使用多个任务完成构建的最佳方法有疑问。 最好的方法是将所有工作集中在一项大工作上，还是只做一些小的依赖工作？
Setting up an integration server, I’m in doubt about the best approach regarding using multiple tasks to complete the build. Is the best way to set all in just one big-job or make small dependent ones?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
我们使用 buildbot，将构建分解为离散的步骤。 在以足够的粒度分解构建步骤和成为一个完整的单元之间需要找到平衡。
例如，在我目前的职位上，我们在各自的平台上为每个平台（Mac、Linux、Windows）构建子部分。 然后，我们有一个步骤（带有几个子步骤）将它们编译成最终版本，最终出现在最终发行版中。
如果这些步骤中的任何一个出现问题，都很容易诊断。
我的建议是用尽可能模糊的术语将步骤写在白板上，然后以此为基础制定步骤。 就我而言，这将是：
We use buildbot, with the build broken down into discrete steps. There is a balance to be found between having build steps be broken down with enough granularity and being a complete unit.
For example at my current position, we build the sub-pieces for each of our platforms (Mac, Linux, Windows) on their respective platforms. We then have a single step (with a few sub steps) that compiles them into the final version that will end up in the final distributions.
If something goes wrong in any of those steps it is pretty easy to diagnose.
My advice is to write the steps out on a whiteboard in as vague terms as you can and then base your steps on that. In my case that would be:
我肯定会分解工作。 您很可能会在构建中进行更改，如果您的任务较小，而不是搜索一个整体构建，那么跟踪问题会更容易。
无论如何，你应该能够从小事中创造出一项大工作。
I would definitely break down the jobs. Chances are you're likely to make changes in the builds, and it'll be easier to track down issues if you have smaller tasks instead of searching through one monolithic build.
You should be able to create one big job from the smaller pieces, anyways.
您好，
当您谈论集成测试时，我的重要（明显）技巧是使测试服务器的构建和配置尽可能接近部署环境。
干杯，
抢
G'day,
As you're talking about integration testing my big (obvious) tip would be to make the test server built and configured as close as possible to the deployment environment as possible.
cheers,
Rob
将您的任务分解为离散的目标/操作，然后使用更高级别的脚本将它们适当地连接在一起。
这使得您的构建过程更容易被其他人理解（您在进行过程中进行记录，以便团队中的任何人都可以拿起它，对吗？），并增加重用的潜力。 您可能不会重用高级脚本（尽管如果您有类似的项目，这可能是可能的），但您绝对可以相当轻松地重用（即使是复制/粘贴）离散操作。
考虑从存储库获取最新源的示例。 您需要将用于检索代码的任务/操作与一些日志记录语句进行分组，并引用适当的帐户信息。 这是一种很容易从一个项目到下一个项目重用的东西。
对于我团队的环境，我们使用 NAnt，因为它在开发机器（我们编写/调试脚本的地方）和 CI 服务器（因为我们只是在干净的环境中执行相同的脚本）之间提供了一个通用的脚本环境。 我们使用 Jenkins 来管理我们的构建，但每个项目的核心只是调用相同的 NAnt 脚本，然后我们操纵结果（即归档构建输出、标记失败的测试等）。
Break your tasks up into discrete goal/operations, then use a higher-level script to tie them all together appropriately.
This makes your build process easier to understand for other people (you're documenting as you go so anyone on your team can pick it up, right?), as well as increasing the potential for re-use. It's likely you won't reuse the high-level scripts (although this could be possible if you have similar projects), but you can definitely reuse (even if it's copy/paste) the discrete operations rather easily.
Consider the example of getting the latest source from your repository. You'll want to group the tasks/operations for retrieving the code with some logging statements and reference the appropriate account information. This is the sort of thing that's very easy to reuse from one project to the next.
For my team's environment, we use NAnt since it provides a common scripting environment between dev machines (where we write/debug the scripts) and the CI server (since we just execute the same scripts in a clean environment). We use Jenkins to manage our builds, but at their core each project is just calling into the same NAnt scripts and then we manipulate the results (ie, archive the build output, flag failing tests etc).
我喜欢的方法是以下设置（实际上假设您在 .NET 项目中）：
在许多项目中，您会发现当有人签入时会发生不同级别的测试和活动。 有时，这些时间可能会增加到开发人员在构建后很长时间才能看到他们是否通过签入破坏了构建的程度。
在这些情况下，我所做的是创建三个构建（或者可能是两个）：
任何 CI 系统的关键在于它需要是有机的并不断进行调整。 CruiseControl.NET 有一些很棒的扩展，可以记录和绘制步骤的构建时间等，并让您进行历史分析，从而允许您不断调整构建以保持敏捷。 经理们很难接受，一个构建箱可能会让你忙上五分之一的工作时间，只是为了阻止它慢慢停止。
The approach I favour is the following setup (Actually assuming you are in a .NET project):
On many projects you find that there are different levels of tests and activities which take place when someone does a checkin. Sometimes these can increase in time to the point where it can be a long time after a build before a dev can see if they have broken the build with a checkin.
What I do in these cases is create three builds (or maybe two):
The key thing about any CI system is that it needs to be organic and constantly being tweaked. There are some great extensions to CruiseControl.NET which log and chart build timings etc for the steps and let you do historical analysis and so allow you to continously tweak the builds to keep them snappy. It's something that managers find hard to accept that a build box will probably keep you busy for a fifth of your working time just to stop it grinding to a halt.
我将 TeamCity 与 nant 构建脚本一起使用。 TeamCity 可以轻松设置 CI 服务器部分，而 nant 构建脚本可以轻松执行报告生成方面的许多任务。
这是我写的一篇关于在 CruiseControl.NET 中使用 CI 的文章，它的注释中有一个 nant 构建脚本，可以跨项目重复使用：
与 CruiseControl 持续集成
I use TeamCity with an nant build script. TeamCity makes it easy to setup the CI server part, and nant build script makes it easy to do a number of tasks as far as report generation is concerned.
Here is an article I wrote about using CI with CruiseControl.NET, it has a nant build script in the comments that can be re-used across projects:
Continuous Integration with CruiseControl
你肯定想分解任务。 这是 CruiseControl.NET 配置的一个很好的示例，每个步骤都有不同的目标（任务）。 它还使用 common.build 文件，该文件可以在几乎不需要定制的项目之间共享。
http://code.google.com /p/dot-net-reference-app/source/browse/#svn/trunk
You definitely want to break up the tasks. Here is a nice example of CruiseControl.NET configuration that has different targets (tasks) for each step. It also uses a common.build file which can be shared among projects with little customization.
http://code.google.com/p/dot-net-reference-app/source/browse/#svn/trunk