tags:

views:

78

answers:

4

Time to ask the pros, since I can't find a good answer anywhere else and I'm venturing into a side of the world that I'm just learning.

I'm in a primarily open source shop that has recently begun taking in a lot of internal tools and partners that are .Net based. That got me to thinking that I may be able to utilize the best of both worlds by leveraging C#/mono in certain spaces. On a small scale I've been very successful and it's working great. However, pressing 'Build' and scp'ing the exe into place isn't going to scale well.

I'd like to step it up a bit and get some more resources behind it, so here's my question; what are the baseline resources I need to establish a good dev/testing/staging environment. I don't need uber-detailed information and I'm willing to consider both commercial and open source solutions, I guess I'm more looking for good advice on resources. 99% of the items developed on either side of the OS line will be services.

What sort of Unit/Regression testing tools are recommended, is NUnit the standard?

What sort of deployment mechanisms are recommended for service level software?

What, if any, additional tools have you found useful or indispensable during your development/design work?

The first 2 items are of interest since they are the last things I'm lacking before I have workable, repeatable development and deployment process.

+1  A: 

You might want to look into http://go-mono.com/monovs/ It will alow you to debug on Linux from within Visual Studio.

The unit testing framework in Visual Studio is rather good as well, but if you use the standard or free version of Visual Studio, NUnit is a good option as well (And there is the option of Visual Studio integration)

Aside from that I've come quite attached to Refactor Pro (and other products by that company) http://www.devexpress.com/Products/Visual%5FStudio%5FAdd-in/Refactoring/

As for scp'ing the files to your linux/mac machines, it might be easier to configure MSBuild to do that for you automatically. This might help: http://bartdesmet.net/blogs/bart/archive/2006/04/13/3896.aspx

Many more msbuild tasks can be found here: http://msbuildcontrib.codeplex.com/

I hope this helps.

TimothyP
+1 For refactor pro! Awesome tool and helps greatly with productivity.
GrayWizardx
A: 

For build and deployment you might give NAnt a try. It'll handle your builds, and has tasks for running your tests, doing clean SVN checkouts, zipping up releases, that kind of thing. You can embed C# too. Grab the nightlies rather than the releases and don't worry too much about the lack of recent activity. Also the nant-contrib project is full of additional goodies.

Another option is to try msbuild (I believe there's a Mono equivalent, although I'm not sure to what degree). Truth be told there's not a lot of difference between the two.

Pike65
A: 

I have built effective build/test/deploy infrastructure with the following:

We also use subversion to manage both source control, as well as deployment (for things like CMS and website systems)

A few of the build tools we use are:

Of course any of these tools can be substituted for other tools you like (perl, python, ruby, Ant, etc).

GrayWizardx
A: 

This is roughly how I've set up my environment at work:

  • I use NUnit as a unit-testing platform
  • I use TestDriven.NET as a plugin to easily run my unittests from within my IDE
  • I've set up a separate computer, which runs CruiseControl.NET

This CruiseControl.NET computer checks my source-repository on regular times. When it sees that something has changed, it gets the latest version from the source-repository and builds it. It also performs unit-tests, and runs fx-cop over the targets.

Next to that, i've configured it so that it performs a nightly build as well. This does roughly the same:
When something has changed during the day:

  • remove every file that exists locally
  • get the latest version from the source repository
  • build it
  • run unittests
  • run fxcop
  • create documentation using sandcastle helpfile builder
  • when the build was successfull, copy the build output to a separate folder which is named 'build-yyyymmdd'.

I've setup my source-repository so that I can keep different versions (branches) from my project. In short, my source-repository looks like this:

  • I have a folder which is called 'devtrunk', which contains the actual codebase. (On which I'm actively developping)
  • I have a folder calles 'releases'. Every time I release a new version, I make a branch of the trunk, and I put this branch in a new folder under 'releases'. This allows me to fix bugs in a version that has been released, without disturbing my actual work on the trunk.

Since I'm working on the Windows platform, I use MSBuild to create my build-scripts (which are executed by Cruisecontrol), but, you can use NAnt instead. (Which I've used as well).

Frederik Gheysels