"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.