If you haven't checked out CruiseControl.NET yet, you really ought to. Continuous Integration (CI) is, in my opinion, only slightly behind Test Driven Development on the list of “most important software development techniques I've ever encountered,” and that puts it very high indeed. I've found CruiseControl.NET to be far more flexible and reliable than Draco.NET, the other major .NET CI tool.
Recently, I took on the role of buildmaster for FlexWiki. As we make the move to SourceForge, I thought it would be an opportune moment to get a CI system set up, primarily because it would help us avoid the “source code, source code, who's got the source code” hell that we've been in for months now. So as I sat down and set up a CruiseControl instance, I had a chance to think about our needs, and about how we should configure things to allow us to grow the project.
Well, after thinking about it for a while, I came up with something I rather like. Since it differs somewhat from the out-of-the-box CruiseControl experience, I've gone ahead and written up what I did here. Hopefully someone else will find it helpful.
Very cool. I'm just starting to set up Cruise Control at work. This will be helpful to see your experience.
ReplyDeleteI really like ccnet myself. Let me know if there's anything I can do to help.
ReplyDeleteHave you tried using MSBuild with CC?
ReplyDeleteNope. I don't think it's a supported scenario. However, you could write a simple NAnt script that invoked an MSBuild script. That would probably work. The only thing you might have trouble with is the bits that parse the build log, looking for errors and warnings. But that's all customizable, I believe.
ReplyDeleteMy very first recommendation is *not* to use SourceSafe. It is basically the worst source control system in widespread use (not counting GotDotNet), with the worst tooling, the worst model, the worst distributed team capability, and the least flexibility. Use Subversion or CVS (in that order) if you want excellent free alternatives.
ReplyDeleteThat said, I would point out that there's no relationship between what CCNET calls a "project" and a project in VS.NET or VSS. A CCNET project is merely a group of folders - any group of folders - in your source control that you monitor for changes. When something in them changes, you rebuild the contents.
I'm no VSS expert, but I know you have some control over what users can see. For example, you could share a bunch of folders into a different hierarchy, and then monitor that, right?
Regardless, it comes down to this: if it doesn't makes sense for changes in A to cause a rebuild of B, then you probably want to put A and B into different CCNET projects. Generally, I find that since .NET projects build so quickly, most projects can get by with just building everything on every change.
Make sense?
Ha ha... Well I think that article should be renamed "Team Development With Visual Studio.NET and A Source Control System". We use Surround SCM (it was here when I got here).
ReplyDeleteThanks for the tip. This is helpful!
nospamplease75, did you check our continuous integation server Parabuild? It fully integrates with Surround SCM...
ReplyDeleteI've a question for you...
ReplyDeleteI'm using VSS and CC.net and when cc.net trys to get source code, throws an error "access denied", this is because my user haven't permissions. Any comments? what i've to do?
Sounds like you need to give whatever user you're accessing VSS with permission to access VSS...
ReplyDeleteYou realize that VSS accepts credentials on the command-line, right? That is, it doesn't pick up on the currently logged-in user or anything.
Also, VSS is an ancient, outdated, piece of shit. You should really consider replacing it with something else. There are lots of fantastic choices, many of them free (SVN, bzr, etc.).
But assuming you're unwilling or unable to do that, just make sure you provide the right credentials. I forget the switches needed to do that, but the docs have it listed.