如何启动并运行构建服务器？
我想这里的每个人都会同意，为了被认为是一个专业的软件公司，你必须具备一些基本的东西。
毫无疑问，其中之一就是构建服务器，问题是，你需要走多远。
- 构建服务器的最低要求是什么？ （在某个地方进行编译？）
- 构建服务器的最终目标是什么？ （预定、源代码控制集成、自动部署到测试/实时服务器）
- 假设您目前什么都没有，那么从哪里开始是一个好地方？
如果我们能够列出业余开发人员可以承担的一些简单任务，以便让他们走上功能齐全的构建服务器的正确轨道，那就太好了。
如果有人觉得他们拥有一个“完整”的系统设置，可以执行他们所需的所有功能，以及他们如何从头开始设置这一切，那也是很高兴的。
I think everyone here would agree that in order to be considered a professional software house there are number fundamental things you must have in place.
There is no doubt that one of these things is a build server, the question is, how far do you need to go.
- What are the minimum requirements for the build server? (Somewhere to just compile?)
- What is the ultimate goal for your build server? (Scheduled, source control integration, auto deployment to test / live servers)
- Where is a good place to start assuming you have nothing at the moment?
It would be great if we could list out a few simple tasks that an amateur developer could take on board in order to set them on the right track to a fully functional build server.
It would also be good to hear about people that feel they have a "complete" system setup that performs all the functionality they require and how they went about setting it all up from scratch.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（12）
您可以首先查看Cruise Control。
如果您中招的话，还有 CruiseControl.net。
但本质上，您需要以下要素：
在这种情况下，CruiseControl 充当 持续集成 服务器，并且可以确保您拥有构建当您签入代码时完成。 这意味着您知道与仅进行夜间构建相比，构建的破坏速度更快。 不过，您可能还应该进行夜间构建。
You can start by looking into Cruise Control.
There's also CruiseControl.net if that's your poison.
Essentially though, you need the following ingredients:
In this scenario, CruiseControl acts as the Continous Integration server, and can make sure that you have builds done as you check in your code. This means you know whether the build is broken quicker than if you just had nightly builds. You should probably also have nightly builds, though.
Hudson 是一个很棒的 CI。
我们在本地运行农场，但我们首先下载 hudson.war 并执行
它与 SCM、bug 卡车系统集成，非常棒。
如果您想保留旧版本，您将需要一些磁盘空间。
享受它是迄今为止最简单的 CI 解决方案。
哈特哈，
休伯特.
Hudson is a great CI.
We run farm locally, but we started by downloading hudson.war and doing
It integrates with SCM, bug trucking systems it is really awesome.
You'll need some disk space if you want to keep old build.
Enjoy it is most straightforward CI solution so far.
HTH,
Hubert.
如果您使用的是 Cruise Control，则可以从手动完成该工作的 Ant build.xml 开始。
您需要一个可以进行标记签出的版本控制系统。
您需要 JUnit 测试才能使用 Ant 任务运行并生成 HTML 报告。
If you're using Cruise Control, the place to start is an Ant build.xml that does the job manually.
You need a version control system that can do labeled check-outs.
You need JUnit tests to run using the Ant task and generate HTML reports.
我想说你必须从实施构建策略开始，这样你就可以以结构化的方式构建你的代码 - 我使用 NANT。
对于基本的构建服务器 - 使用 CI 产品之一来监视源代码控制并在检测到更改时触发构建。 例如：巡航控制。
一旦你完成了基本的构建 - 在成功构建后添加单元测试的运行。
我所拥有的最成功的系统有 3 种不同的版本：-
- 签入时触发的 - 所有这一切都是构建代码。
- 按需构建应用程序，生成安装程序，然后放置
将安装程序放入共享驱动器中以供测试人员使用
- 每天晚上 10 点触发的构建。 这：
- 运行一些代码生成以从 UML 模型构建 DB 和 C# 代码
- 构建代码
- 在测试 oracle 实例上创建了一个新的构建验证测试用户
- 将应用程序模式运行到数据库中
- 发起了一系列单元测试
- 清理数据库用户（如果测试成功）
- 运行覆盖率分析以构建单元代码覆盖率报告
我们为此使用的软件是 NANT、CruiseControl.NET、自定义代码生成系统、用于构建 Oracle 模式的自定义应用程序以及用于代码分析的 NCover。
Id say you'd have to start by implementing a build strategy so you can build your code in a structured way - I use NANT.
For a basic build server - use one of the CI offerings out there that monitors your source control and triggers a build whenever a change is detected. eg: cruiseControl.
Once you get the basic build together - add the running of your unit tests after a successfuly build.
The most successful system i've had in place had 3 different builds :-
- one that fired on a check in - all this did was build the code.
- an on demand one that would build the application, generate the installer and then put
the installer into a shared drive for the testers to pick up
- a daily build that fired at 10pm. This:
- ran some code generation to build DB and C# code from a UML model
- build the code
- created a new build verification test user on a test oracle instance
- ran the application schema into the db
- fired off a bunch of unit tests
- cleaned up the db user (if the tests were successful)
- ran coverage analysis to build a report of the unit code coverage
Software we used for this was NANT, CruiseControl.NET, a custom code generation system, custom app to build an oracle schema, and NCover for the code analysis.
首先阅读 Martin Fowler 关于持续集成的优秀论文。
我们为一个大于 2,000 kSLOC 的大型项目构建了这样一个系统，事实证明它是无价的。
HTH
干杯，
罗布
Start by having a read of Martin Fowler's excellent paper on Continuous Integration.
We built such a system for a major project >2,000 kSLOC and it proved itself to be invaluable.
HTH
cheers,
Rob
Cruise、Maven、Hudson 等都很棒，但总是值得有一个权宜之计的解决方案。
您应该有一个批处理文件、shell 脚本或简单的书面说明，以便您可以从任何计算机运行构建。 过去我们的构建服务器不可用，快速切换到另一台机器的能力是无价的！
除非您有一个巨大的项目，否则构建机器的规格并不重要。 我们尝试将构建时间控制在 10 分钟（包括单元测试），而且我们有一个相当大的项目。
不要因为“现有的工具都不够好”而试图创建或编写自己的构建系统。 所有现代构建系统都允许您编写插件来执行自定义操作。
Cruise, Maven, Hudson etc are all great but its always worth having a stopgap solution.
You should have a batch file, shell script or simply written instructions that will allow you to run a build from any machine. We have had build servers unavailable in the past and the ability to switch quickly to another machine was invaluable!
The spec of the build machine need not be important unless you have a monster project. We try and keep our build times down to 10 minutes (including unit tests) and we have a pretty big project.
Don't be tempted to create or write your own build system because "none of the tools out there are good enough". All modern build systems allow you to write plugins to do custom stuff.
我正在使用 Cruisecontrol.NET 和 msbuild 构建脚本。
我可以手动使用构建脚本，以便获得最新版本的代码库，使用命令行非常轻松地构建代码库。 （如果您正在开发由多个解决方案组成的应用程序，这非常有趣）。
除此之外，我的 CruiseControl.NET 构建服务器也使用此构建脚本。 它定期检查是否有提交到源代码管理的更改。
如果发生这种情况，CC.NET 将执行我在构建脚本中定义的“获取最新”任务，构建所有内容，执行单元测试并执行静态代码分析 (fxcop)。
我的“buildserver”只是一个旧工作站。 它是 PIV、3Ghz、1GB RAM，并且完美地完成了它的工作。
我觉得有趣的另一件事是能够自动部署新版本或构建设置。
我还没有这样做，因为我不确定这是否是一个好主意，也没有找到一个好的策略来这样做......
我是说; 将某些组件的新版本部署到生产中以用于关键任务应用程序是一个好主意吗？ 我不这么认为......
我认为这是一个很好的起点：
[http://confluence.public.thoughtworks.org /display/CC/Home;jsessionid=5201DA7E8D361EB164C40E519DA0F0DE][1]
至少，这是我在设置构建服务器时开始寻找的地方。 :)
[1]: CruiseControl 主页
I'm using Cruisecontrol.NET and an msbuild buildscript.
I can use the buildscript manually so that I can get the latest version of the codebase, built the codebase very easily using the commandline. (This is very interesting if you are working on an application that consists of multiple solutions).
Next to that, my CruiseControl.NET buildserver uses this buildscript as well. It checks on a regular interval if there have been changes committed to the source-control.
If that happens, CC.NET performs the 'get-latest' task that I've defined in the buildscript, builds everything, executes unit-tests and performs a statical code analysis (fxcop).
My 'buildserver' is just an old workstation. It's a PIV, 3Ghz with 1gb RAM, and it does its job perfectly.
One additional thing that I would find interesting, is to have the ability to automatically deploy a new version, or build a setup.
I haven't done that yet, since I'm not sure whether it is a good idea, nor have I found a good strategy yet to do so ...
I mean; is deploying a new version of some components into production for a mission-critical application a good idea ? I don't think so ...
I think this is a good place to start:
[http://confluence.public.thoughtworks.org/display/CC/Home;jsessionid=5201DA7E8D361EB164C40E519DA0F0DE][1]
At least, that's where I started looking when setting up my build server. :)
[1]: Home of CruiseControl
大致按顺序 - 最小/最不复杂到更复杂
...
这样的例子不胜枚举，
不要害怕从批处理文件、shell 脚本或其他临时方法开始。 在 CI 热潮出现之前，人们就已经制作出了完美的软件。 在 Hudson 和 Cruise Control 之前有很多好的流程 - （我不是在批评这些或其他流程 - 我使用 Hudson 等） - 但不要错过重点 - 这些东西是为了帮助你 - 而不是成为专横的流程）
Roughly in order - minimal/least sophisticated through more sophisticated
...
And the list goes on and on
Don't be afraid to just start with batch files or shell scripts or other ad-hoc means. People made perfectly good software before the CI craze. there were plenty of good processes before Hudson and Cruise Control - ( I am not knocking those or others - I use Hudson among others) - but don't miss the point - these things are here to help you - not become overbearing process)
我无法向您提供有关我们如何设置构建服务器的所有详细信息（我只在开始时参与），但是：
我们将它用于由提交触发的构建：这些只是构建二进制文件并运行单元测试。 从这里，我们可以进行完整的构建，这也可以完成 MSI。 从那里，我们进行了系统测试构建，在使用虚拟机（具有单独的域控制器、SQL Server 框等）构建的环境中运行更深入的测试。 当系统测试通过后，我们的 QA 部门即可使用该构建进行手动测试和一些我们尚未自动化的回归测试。
I couldn't give you all the details about how we set our build server up (I was only involved at the start), but:
We use it for builds triggered by a commit: these just build the binaries and run the unit tests. From here, we can do a complete build, which does the MSI as well. From there, we have system test builds that run more in-depth tests, across an environment built with virtual machines (with a separate domain controller, SQL Server box, etc.). When the system tests pass, the build is made available to our QA department for manual testing and some regression tests that we've not automated yet.
在 Java 领域，我测试了大多数可用的构建环境。 自动构建的问题在于，您通常最终会花费相当多的时间来跟踪它。 当我们从atlassian切换到商业bamboo后，我们发现我们要花费很多花在构建箱上的时间更少，在我们的例子中，这被证明是非常经济的。 Bamboo 还支持集群，因此您可以根据需求的变化添加廉价的盒子。
In the java space I've tested most of the available build environments. The issue with automatic build is that you quite often end up spending a fair amount of time following it up. After we switched to the commercial bamboo from atlassian, we found that we have to spend a lot less time pampering the build box, which in our case turns out to be very good economy. Bamboo also supports clustering, so you can add inexpensive boxes as needs evolves.
尝试& 找到一些适合您现有的构建实践的东西 - 例如，尝试和尝试它并不适合。 例如，如果您使用 Maven，请使用基于 Ant 的构建服务器！
理想情况下，它应该能够监视您的源代码控制系统、检查代码、构建、运行一些测试和测试。 在您不知情的情况下发布结果，或者至少在报告失败之前不会发布结果。 就个人而言，我建议 Hudson (https://hudson.dev.java.net/)作为一个很好的起点，因为它很容易安装和使用。 跑步& 有一个不错的用户界面。
Try & find something that fits in with your existing practices in terms of building - e.g. it's not going to be a good fit to try & use an Ant-based buildserver if you're using Maven, for instance!
Ideally, it should just be able to monitor your source-control system, checkout the code, build, run some tests & publish the results without you being aware of it, or at least not 'till it's reporting a failure. Personally, I'd suggest Hudson (https://hudson.dev.java.net/) as a good starting point as it's easy to get installed & running & has a decent UI.
我们首先编写将在开发人员计算机上运行的批处理脚本。 一旦我们将所有流程自动化，我们就会将它们转移到构建服务器。
在工具方面，我们目前正在从 Cruise Control 转向 TFS。
We start by writing batch scripts that will run on the developers machine. Once we have all the processes automated, we move them to the build server.
On the tools side we are currently moving from Cruise Control to TFS.