9

We currently use once cc.net server for our build process, which builds both .net (using msbuild & nant) and java (using maven and ant).

CC.net monitors source control, and triggers a remote build running on a separate server. CC.net then collates the results.

When we run the remote build, it typically:

  • runs nunit or junit or similar using mocked data
  • optionally runs a DB script to create a fresh database instance or restore a database from a known position.
  • runs selenium or similar to test UI
  • runs emma or ncover for code coverage
  • builds the system for various deployment environments (test, acceptance, production)

We may have several builds running at a time, some .net and some java (from different project teams).

It's quite time consuming to get the remote builds working when we set up a new project and we feel that there must be something more suited to remote builds than cc.net.

Does anyone have any experience with remote builds with continuous integration systems?
I don't really want feature lists of CI servers, I'd more appreciate hearing about how you've used them in a multi language, multi server environment.

Improve this question

4 Answers 4

Reset to default
8

Hudson (Update: in today's world, I would use Jenkins, a fork of Hudson.)

I've used hudson in both Java and .NET enterprise environments for high visibility projects (you've probably been to some of the sites). Hudson is solid from the start, but the best part is that there are lots of plugins to do just about anything you want. Hudson is highly configurable, has a great community, and is really easy to set up in a cluster environment if you need multiple builds going at once. It's my favorite CI server of all the ones I've used (CC.NET, Hudson, and TFS).

Plus, you can use the ChuckNorris plugin to have him give you the thumbs up or down.

Improve this answer
4
  • 1
    Hudson is a good choice if you aren't doing anything exotic, but at the end of the day if you cannot do what you are trying to do in a batch script Hudson is not likely to do it very well either.
    – Bill
    Sep 27, 2010 at 16:46
  • Hudson has forked into Jenkins and Oracle Hudson. Care to share which one to use?
    – user1249
    Jun 21, 2011 at 11:40
  • 1
    @Thorbjørn: I'm pro-Jenkins. There several reasons, but the killer one for me is that Jenkins is getting more active development - largely because Kohsuke Kawaguchi, the main guy behind Hudson, is in the Jenkins camp. And it seems he feels that Jenkins is the true continuation of the project he started. Oh, and lastly, Jenkins has a logo which isn't Microsoft clip art!
    – Tom Anderson
    Jun 21, 2011 at 17:30
  • @Thorbjørn - I agree with Tom. I've not used Hudson in about a year now (currently use TFS), but that's the general consensus that I've heard is that Jenkins is the way to go. Again, I've not used either since they were forked, but if I had to pick it up again, I would likely go the Jenkins route.
    – Ryan Hayes
    Jun 21, 2011 at 17:51
7

We were facing this question some time ago and decided to go with TeamCity. We only looked at Hudson, CC and TeamCity. The choise was easy to make - TeamCity ended up being our build server. Please note that I am not a pro in this and it was my first experience with build servers at that time.

Hudson - I had no idea what to do and where to read about it. And even though I could understand something there it was not an option - too much work. I decided to take a look at CC.

Cruise control - same as Hudson, yet in a slightly different way. Absolutely nothing can be understood there without a manual and a ton of help from google. I just went on to take a look at TC.

TeamCity - TeamCity felt like heaven after the first two. It is the most usable out of those three. Install, go to admin panel, configure a project (show where the SVN is, point to build files, specify coverage/unit tests etc.) and start enjoying. And even though I cannot say that I did not google anything, still 95% of the setup process was very easy and clear. I highly recommend this tool. Go and take a look at it. It will save you a lot of nerves and time :)

I should also note that TC is not free. Though they do have a free edition that can be used in commercial projects with some limitations (max build configs 20) - take a look in their pricing page.

PS I sound like I work for TC, but I really don't :)

Improve this answer
0
2

We use CC.NET 1.4.

We are trying to upgrade to 1.6... what a nightmare.

Its powerful... but ONLY if you use it right and understand how everything fits together. Which is a lot to ask from the whole team. We have 'buildmasters' who have access to the server and can change the configs. Even so, there is a lot of Googling with regard to ccnet and the whole business has become a huge mess.

I personally want to move to TeamCity.

I recommend you steer clear of ccnet.

Improve this answer
1

good question. We are currently also trying to find out which tool fits best for us. So I will only be able to tell you a little experience. But we would be very interested in, which CI system you chose now and for which reasons. So please keep us informed.

I'm very impressed how high the level of your CI is. I have to admit that we have less requirements because we don't run UI tests yet and don't create database instances or similar, we just using mocks for our unit tests.

Now to our experiences up to now:

For Java projects we are using Bamboo which works fine using JUnit and Emma. And there is not so much effort to set up a new project.

For .NET projects we are still searching for the best solution

  • Cruise Control: We could not get it running yet due to problems with connection to our repository

  • TFS :

    a) There are a few setup steps necessary to be able to execute the first build.

    b) There are some pitfalls where you have to get over regarding access rights. There are many roles you can define and you have to know exactly which rights has your build process and which has your personal login account. But if you have enough time to manage, you can define every particular granularity you need.

    c) Regarding referenced libs there are also some things to manage if you want to share libs for many projects and don't want to handle them at every single project

    d) Running NUnit test is not so easy as we thought. It's only easy if you are using test execution provided by Visual Studio, but this is not NUnit

    e) We didn't try to run NCover yet (first things first :-))

  • Hudson : Next tool we'll try. Seems to have a really good and easy plugin for .NET, I will let you know how it worked

  • Bamboo : First prediction we got: "Too Java specific". But maybe we'll try the .NET plugin nevertheless, I will let you know

Hope, we can continue this discussion and exchange experiences.

Andy

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.