"The NAnt script for this simple build weighed in at a
hefty 162 lines."
Its almost always easy to reduce line-count at the
expense of ease-of-comprehension.
@AndrewSeven -
That quote is taken a bit out of context. I said just
that later in my post.
Let's check in after I'm finished porting our 2000+ line
automated deployment pipeline scripts.
@Roy -
Nice post! This is a good viewpoint and I'm glad there
are choices like rake and finalbuilder for different
teams. Pick what works best in context! I know I sound
like a middle child here, but that's something I really
do believe. More choices = better.
My post was a very early version. I've since created
customized methods for the various common things you'll
want to do with a build script.
So this (ugly!):
task :compile => [:init] do
sh "#{DOT_NET_PATH}msbuild.exe
/p:Configuration=#{CONFIG} #{SOLUTION}"
end
Becomes this (pretty!):
task :compile => [:init] do
msbuild the :solution
end
(I plan on distributing a "rake tasks for .net" library
based on this work. Hopefully people will add to it.)
For the record: I love FinalBuilder too. We use it as a
nice solution for managing batch integrations for our
customer's various business partners. Works like a
charm.
Ayende: did you read this?
"FinalBuilder saved to an XML File. it’s not great but
it is somewhat mergeable. Ruby is very easy to merge.
Assuming this is a frequent task (two people working on
the build) Ruby will be much easier. However, I almost
never need to do this since the build is usually handled
by one person (or pair) at any time anyway."
also, if it took you four minutes to figure out the
build - I'm not sure what is so complicated to figure
out about it. can you elaborate?
I wish visual tools would serialize to an internal DSL
like Ruby+Rake. It _is_ possible to make everyone happy
if tool makers take it into account!
Excelent post Roy, very detailed.
I'm still in the dark ages of msbuild-only build
scripts, written in a damn XML editor.
I get none of the benefits of a text file (intellisense,
a real programming language, etc.) neither the visuals
that could be layered on top of an XML file like FB
does.
I need to take care of this...
Excellent post, definitely summing up the visual vs.
executable build debate.
Coming from the executable camp, I can say I for one
found some food for thought here -- especially the point
of task discoverability, which is vital when introducing
automated build practices in a new environment.
All in all, I agree with Dave that having the choice of
good tools in both approaches is a good thing.
And yes, an executable build script that can also be
rendered graphically would be awesome, and that should
be too hard to create -- even a simple visualization of
tasks, dependencies and control logic, without
customized visualization for each task, will go a long
way in combining the benefits of both approaches.