Search The Blog
My Books

New:

My Songs

 

The Art of Unit Testing

Buy PDF or Print book at Manning

Buy on Amazon

Latest Posts
from 5whys.com
Twitter: @RoyOsherove
About this site

TDD in .NET Online Course

TDD and BDD in Ruby Online Course

 

Subscribe!

This site aims to connect all the dots of my online activities - from tools, books blogs and twitter accounts, to upcoming conferences, engagements and user group talks.

« Build Bullet #3– Start Products with an Empty Build and Deploy Pipeline | Main | Build Bullet #1 - Use Version Aware Build Scripts »
Sunday
Nov182012

Build Bullets #2–Avoid XML Facing Build Tools

Having your build scripts in XML is one of the worst things you can do for maintainability and readability.

Treat your build scripts like you treat your source code (or, how developers should treat their source code) – with respect for readability and maintainability, not just for performance.

To that end, XML is a bad candidate to have. If you have any more than 15 or 20 lines of xml in a build document:

  • It is hard to tell where things start, and what they depend on
  • It is hard to debug the build
  • It is hard to add or change things in the build logic
  • XML case sensitivity sucks
  • Creating, Adding and using  custom actions is a chore

To avoid XML, you can start using some of the many build tools out there that are either visual, or support a domain specific language for builds that is more readable, maintainable or debuggable than XML:

  • Rake – Ruby Based DSL (Domain Specific Language) for builds, that is very robust and quite readable
  • FinalBuilder and VisualBuild are two visual build scripting tools that give great readability into your build script

image

Image: An example of FinalBuilder– My current favorite build tool.

Do not use (for build scripts) tools such as :

Avoid XML editing like the plague, and you might find:

  • It is easier to introduce new team members to your build script, and ask them to share in the burden of maintaining it quickly.
  • It is easier to enable or disable certain actions quickly for debugging purposes
  • It is easier to reuse build scripts
  • It is easier to find out what went wrong and where when the build fails if you have a visual tool

PrintView Printer Friendly Version

Reader Comments

There are no comments for this journal entry. To create a new comment, use the form below.

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
Post:
 
Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>
Web Analytics