Myself as well as a number of CCNET users create a build system which is a 
combination of CCNET and Nant.  Nant is an XML based scripting language which 
is specifically designed and intended for build, configuration management and 
other types of code/project management.

Different projects have different needs.  Nant might be worth a look.  We use 
it for a fairly complex build, configuration management and automated 
deployment system.  Not perfect, but very capable and it works reliably.

In general, we do the bulk of our build and CM scripting in Nant and call these 
scripts from CCNET.  This has several advantages:  1)  Testing complicated 
operations via CCNET can sometimes be tricky due to multi-threading and timing 
issues.  2)  The scripting capabilities in CCNET are limited and it is 
generally more difficult to do complicated tasks in CCNET vs. Nant.  3)  Our CM 
scripts can be tested and run manually without the involvement of CCNET.  Not 
just a matter of 'Force'-ing a task, but having a much higher level of control 
over what is being executed.  One can use command line parameters with Nant 
tasks.

Here's a URL:

http://nant.sourceforge.net/

Ken Parrish
Gomez, Inc.

-----Original Message-----
From: [email protected] [mailto:[email protected]] On 
Behalf Of gargayle
Sent: Saturday, April 17, 2010 9:13 PM
To: ccnet-user
Subject: [ccnet-user] What do people typically do for .net labeling with CCNET 
and for source control with branches etc...?

I see they added the assemblyfileversionlabeller which is cool and all
but I still find that depending on CCNET for the labeling and even for
the source control is a bit confining or leaves you with redundant
project blocks that only have small changes.... Or just having messy
configuration overall

This might be due to my ignorance of features or ways to set things up
though...

Right now we are using fortress.. We branch on a released label after
we release code into production...
So building a project that's able to cope with both the branch and the
trunk doesn't really seem super easy with ccnet... Right now I just
handle everything source control and label related directly through
msbuild files since those are super easy to make dynamic....

I use the new dynamicParameters in ccnet to send information to
msbuild like

IsBranch = yes/no

Than the msbuild file takes this information and sets up the proper
path for the repository it needs based on the branch/trunk.
It checks out a version file
uses the msbuild community task to increment the Major number if it's
a trunk and the Revision if it's a branch....
I do all the source control through msbuild as well via <EXEC>command
line</EXEC> cause command line isn't really that hard... Losing out on
the fortress ccnet plugins doesn't really vex me that much. And
setting up the dynamic paths for the repository and the output is
really simple in MSBUILD

That kind of flexibility directly from ccnet seems a little tricky to
achieve but that might just be cause I'm not aware of certain ways to
do things in CCNET... I find that anytime I'm confronted with the need
to allow for dynamic situations or variances (even simple ones) it's
just easier to pass variables (which are now easy given the dynamic
stuff) into msbuild and let it deal with what needs to change for
this...

Which makes everything super simple.... I basically use the same
msbuild files for all our projects since they all follow the same unit
test/source control/deployment strategies..
So setting up new projects is fairly simple... Include masterbuild
file set parameters and go....... it's all very write once use
everywhere.. Plus all the dependencies are built into the msbuild
files so it's not dependent on ccnet really. I could specify
everything from my dev system that doesn't have CCNET installed and
given the proper parameters it'll just perform the exact same build
process... Labeling/SC/everything

This all makes using the labelers though (so it looks pretty on the
ccnet screen) not really possible though since the labelers all run
PRE any tasks... So I don't get the benefit of a CCNETLabel variable
that I can pass into remote clients and what not....

What I figured I'd do is just write my own labeler that executes the
versioning portion of my msbuild files and just use that

Just figured I'd kind of put that out there see if anyone had any
comments or thoughts:-)



-- 
Subscription settings: http://groups.google.com/group/ccnet-user/subscribe?hl=en

Reply via email to