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: An example of FinalBuilder– My current favorite build tool.
Do not use (for build scripts) tools such as :
- Ant, Nant, maven or msbuild (XML based editing)
- TeamCity, FinalBuilder Server, Microsoft Team Build Server (use these only for build configurations, not the scripts themselves)
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