4

Ok, so here's my current setup and my problem at the moment. I have a growing set of projects in a Visual Studio solution. The solution contains about 15 projects (give or take a few) and a quickly growing code-base. I realize that I should have had a continuous build system set-up before I got to this, but its never too late I suppose. So after doing a little research, I believe that my perfect setup would be:

  • NUnit 2.5.x (we are already tied to this... so a necessity)
  • Integration with CruiseControl.Net (open to other options, but only free ones with Git support)
  • Integration with a code-coverage tool (NCover, DotCover) would be nice
  • Integration to run shell commands (for JSLint and compression tools, etc.)

What I am missing is a tool to run the automated build. I looked at NAnt, but it's support for running MSBuild (to build the project) seemed fairly outdated (we're using VS2010) and utilizing the solution files in our build process would be a HUGE time saver. I also looked at MSBuild (for the obvious reasons) but the process that I found for running NUnit tests only supports 2.4.x (MSBuild extensions project).

I am curious how everyone else has organized their continuous build systems. NUnit if fairly popular, so I must not be the only one who is wondering about this.

  • if you want to build from the solution files, you can always use devenv.exe using the /build and associated options... http://codebetter.com/raymondlewallen/2005/07/20/using-devenv-at-the-command-prompt-to-build-projects/ – shelleybutterfly Aug 10 '11 at 04:18
  • This would work... yes. But i'm hoping for a something that looks a little cleaner in the build file and would be more intuitive to other people that will have to manage this after me. –  Aug 10 '11 at 04:25
  • unfortunately the only project i was on in which i was going to be able to set up continuous builds was canceled just prior to finishing the CI stuff; i had looked into it and since we were using the solutions to build during development i didn't want to have two separate build definitions; i did look a bit at MSBuild and decided it wasn't worth the effort in our case. but, it sounds like you are further than i ever was. :) may i ask what you find unclean about building w/ devenv and the .sln files? once i had gotten the hang of the /build options, it seemed pretty straightforward to me. – shelleybutterfly Aug 10 '11 at 04:33
  • @shelleybutterfly - As much of a fan of the CLI as I am (more of a unix nut and less on the windows side of things) I don't think most of the developers would be comfortable around a command line. Also, if I'm using a build-tool I would like to keep everything in a common format (XML) such that whoever manages/touches the build-scripts will only have to learn one format. It would also keeps things a little more readable and therefore more maintainable. –  Aug 10 '11 at 13:18
  • hmm, i never got this completely set up :`(, but i had never intended developers to do anything other than their usual IDE development, followed by a check-in to mercurial. i was planning to have automatic test runs (configurable) on the developer box with a systray type healthmon after local commits, and the same setup but with a full configuration on our release point box upon a push from a dev. now, i also was looking at rolling my own tool to do the build that would give me the functionality, rather than going with a big tool that had way too much and too little. but it seemed worth doing. – shelleybutterfly Aug 11 '11 at 01:57

3 Answers3

4

my first question is how may build projects will you have?

Teamcity Professional is free for 20 build configurations per server and will make your like sooooo much easier, has dotcover build in, and is really easy to setup, run your tests, etc. and it's by far the most fully baked CI server out there.

Jenkins is the next runner up, it's a fork of Hudson and is very flexible with plugins
to do just about anything making it a little more flexible then Teamcity but it's not as easy to set up, code coverage is a pain to set up and has some annoying quirks, but is completely free.

unless you have some really strong reason to use CruiseControl.Net, don't bother, for it's time it was very powerful but it's now sadly out dated and painful to use.

As far as setting up builds, both Teamcity and Jenkins support MSBuild, NAnt, Rake, etc. they also support multiple build steps like would do in an msbuild or Nant file. What I have done in the past is just use the .sln file to do the build with one build step, used the build in task for unit tests, then used the built in task for code coverage then used a another build task for pushing the files.

I have used TeamCity, Jenkins, TFS, and I tried to used CruiseControl.Net but found it painfully clunky. By far Teamcity is the best, with Jenkins a close second, I would not willing use TFS even if I had it.

If you have any questions please feel free to contact me.

Bob The Janitor
  • 20,292
  • 10
  • 49
  • 72
  • So, I guess my biggest question is, with something like TeamCity Pro, do I still need an automated build-script (using NAnt or MSBuild) or is that taken care of for me with TeamCity? –  Aug 10 '11 at 12:45
  • No you dont need msbuild or nant if you move to TC.Depends how much you want to extend the process. I think you could defintely do without them. – James Woolfenden Aug 10 '11 at 12:57
  • That's good to know. I foresee this project having a fairly extensive build process (at least for release) and an agnostic automated build process would be nice. However, that might have to come later as we are in need of a (simple) CI system sooner rather than later. –  Aug 10 '11 at 13:12
  • With TeamCity and Jenkins you can setup build steps to get around having to use MSBuild or NAnt – Bob The Janitor Aug 10 '11 at 13:13
2

You can use NAnt to build your Visual Studio 2010 solutions. I do it all the time. I provided sample NAnt script in my answer here: <msbuild> task or msbuild.exe with NAnt?

Community
  • 1
  • 1
Babak Naffas
  • 12,395
  • 3
  • 34
  • 49
0

If all you need is compile and run tests you can't go wrong with TeamCity it has great support for NUnit/VS and a bunch of reports built in.

If you need to run a more complex build script I suggest you use FinalBuilder for creating the build script and TeamCity command runner to execute that script. By importing the test result into TeamCity you can still get the reports and there is a simple way to output build status from FinalBuilder to TeamCity:

Community
  • 1
  • 1
Dror Helper
  • 30,292
  • 15
  • 80
  • 129
  • Like the post implied, I'm really not looking to spend a lot of money on my build process. So the fact that FinalBuilder SE costs $839 for 10 licenses is already out for me. –  Aug 10 '11 at 15:08