CI 服务器的比较? ？

小开

TeamCity has a wonderful feature of allowing the developer to perform a personal build before committing. Very useful!

CruiseControl.NET is the granddaddy of the bunch and is hence a little dated visually etc. As it has been around for a while, Google knows how to fix many issues you will come up against.

For these reasons (amongst others), I use CruiseControl.NET at work and TeamCity at home and in my open source life :)

小开

CruiseControl.NET - it can be a bit of a pain to set up (as can most CI systems), but it is worth perservering with. I currently have it set up to run unit tests on completion of builds, and to produce Wix installers on-demand. As Dan said, it looks a bit dated, but that doesn't matter, as it provides you with plenty of information that's easy to get at and easy to read.

One thing - make sure all your developers have CC Tray installed, running and pointing to their builds. It's a great feeling to get "Another successful build" in your notification tray.

小开

Nothing helpful in:

EDIT: A pointed out by Jonik in a comment, I missed What is the difference between Hudson and CruiseControl for Java projects? and How and why do I set up a C# build machine?. You'll find very insightful answers. In other words, I think that everything you're looking for is already on Stack Overflow.

小开

I'm fairly new to the CI-scene and I've been concentrating my efforts on CruiseControl.NET, using NAnt and Ivy to build my .NET projects.

I've found that CruiseControl.NET is very adaptable to lots of other tools, such as NCover/NUnit/etc. They all plug into this and integrate the results for a combined build process.

I'll be looking into TeamCity in the near future for my own interest, but I think that CruiseControl does a good job, but only as good as your build-scripts! If these are pants, then your builds can only be expected to be that good.

But in summary, CruiseControl.NET is a good solution, but I'm yet to find out how good the competition is in comparison.

小开

We're using ccnet at work, which is fine for most of our needs (we have about 50 automated builds), but it needs one person for full time tweaking and fixing.

If you're starting from scratch, please take a look at Bamboo. We have looked into it and it looks really promising, but it doesn't completely match our needs and we have invested way too much time in ccnet to switch to Bamboo now.

Regards,

Sebastiaan

小开

We use Hudson at work. The main reason is, that it is very easy to setup. You can directly execute the war (it's a executable jar) or deploy it at any servlet-container. And you're ready to start. Also Hudson supports many tools and is extensible through it's plugin-system.

小开

I'm a CruiseControl.NET user all the way. My teams uses it at work and I use it at home for personal projects.

In particular, CruiseControl.NET allows me to run through the whole CI process: builds, version update, unit and integration tests, archival of source or release candidate, code coverage, even deployment to our test system at work. It's highly customizable, works well with MSBuild and NAnt, and even had an extensible plug-in architecture.

It pretty much does everything I need.

The biggest disadvantage: configuration is sometimes a pain, and can take time. But once it's done, it's done, and as another poster said, I love seeing the "successful build" signal because I know that not only did the build itself work, but that also that my unit and integration tests all ran successfully.

小开

Team Foundation Build is an option as well as it interacts very well with Team Foundation Server. It's free as long as long you've licensed TFS.

小开

I inherited a luntbuild server. Not a good option for a .NET project. If you find that you're constantly falling back to using the build server to run generic command line tasks, then something is wrong. A good build server had a good understanding of unit tests output and msbuild tasks as more than opaque commands to be run when the source control system changes.

I'm enjoying migrating to Team City.

小开

We switched from CruiseControl.NET to TeamCity primarily because of ease of configuration. TeamCity also has more features, but the main reason was that a nice Web UI is simpler to use than XML configuration files.

EDIT: Most tasks TeamCity will do out of the box; when necessary we use NAnt.

小开

We're happy with Hudson. I don't have anything to compare it to, but it was simple to configure and get running. Right now it only builds Win32 C++ projects and an installer, but we're porting to Linux and it should work with that as well.

Gets Subversion repositories without any problems and mails out alerts, etc. We like it so far. Again, we have limited experience with comparisons.

小开

最佳答案

No question like this is complete without a link to the big CI Feature Matrix(Web Archive) which lists just about every CI option out there.

But I think it is important to look ahead to the scope of what you want to include in your CI system. Is it going to be just builds or are you going to be bringing in other elements like static analysis, cross-project dependencies, deployments, functional tests, etc. To help with that planning I created this wallchart on the Elements of Enterprise CI (PDF; no registration required). Please don't let the "E-word" put you off; I just mean stuff beyond the basic fast feedback CI build. :)

It isn't tool specific but lists a variety of practices you might consider while you're in the planning/evaluation stages.

小开

I've been working with CruiseControl.NET, TFS 2012 and TeamCity 7.x for several years and i believe TeamCity is the BEST due to it's ease of use, comfortable and informative UI and other cool features like build dependencies and many more. It just works, I love it.