--- title: "Build Bullets #2–Avoid XML Facing Build Tools" url: "https://osherove.com/blog/2012/11/18/build-bullets-2ndashavoid-xml-facing-build-tools.md" canonical: "https://osherove.com/blog/2012/11/18/build-bullets-2ndashavoid-xml-facing-build-tools.html" published: "2012-11-18T18:56:34" updated: "2012-11-18T18:56:34" tags: ["Build Bullet"] author: "Roy Osherove" description: "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) –…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Build Bullets \#2–Avoid XML Facing Build Tools By Roy Osherove November 18, 2012 In [Build Bullet](https://osherove.com/blog/category/build-bullet) **Historical article** · Originally published November 18, 2012; technical details may be outdated. 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](http://rake.rubyforge.org/) – Ruby Based DSL (Domain Specific Language) for builds, that is very robust and quite readable - [FinalBuilder](http://www.finalbuilder.com/) and [VisualBuild](http://www.kinook.com/VisBuildPro/) are two visual build scripting tools that give great readability into your build script [![image](https://osherove.com/img/sq/64993687-Windows-Live-Writer-Build-Bullets-2Avoid-XML_1149A.png)](https://osherove.com/s/files/Windows-Live-Writer-Build-Bullets-2Avoid-XML_1149A.png) 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](https://osherove.com/blog/2012/11/17/build-bullet-1-use-version-aware-build-scripts.html)) **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 ## More in Build Bullet [All posts in Build Bullet](https://osherove.com/blog/category/build-bullet) - Nov 27, 2012 ### [Build Bullet #4: Rolling Builds and the Plane of Confidence](https://osherove.com/blog/2012/11/27/build-bullet-4-rolling-builds-and-the-plane-of-confidence.html) - Nov 18, 2012 ### [Build Bullet #3– Start Products with an Empty Build and Deploy Pipeline](https://osherove.com/blog/2012/11/18/build-bullet-3ndash-start-products-with-an-empty-build-and-d.html) - Nov 17, 2012 ### [Build Bullet #1 - Use Version Aware Build Scripts](https://osherove.com/blog/2012/11/17/build-bullet-1-use-version-aware-build-scripts.html) --- ## About the author **Roy Osherove**: Senior Solutions Architect at AWS working on AI for production and AI-driven development; author of The Art of Unit Testing and Elastic Leadership, with about 20 years of consulting and training on unit testing, TDD, team leadership and continuous delivery. ### Sites - [RobotPaper](https://robotpaper.ai/): This blog: AI patterns and anti-patterns, AI and coding agents, and engineering leadership. - [osherove.com](https://osherove.com): Roy's personal site. Author of The Art of Unit Testing and Elastic Leadership; consulting and training on unit testing, TDD, team leadership and continuous delivery, plus about 20 years of blog posts. - [The Art of Unit Testing](https://www.artofunittesting.com): The Art of Unit Testing, 3rd Edition (Manning): readable, maintainable, trustworthy unit tests, plus TDD workshops in C#, JavaScript, Java and Kotlin. - [5whys.com](https://www.5whys.com): Roy's writing on software team leadership: self-organizing teams, surviving chaos, learning mode and the Elastic Leadership model. - [Pipeline Driven](https://pipelinedriven.org): Continuous delivery and DevOps practices: build patterns, pipeline-friendly testing, DevOps metrics and enterprise DevOps. - [Elastic Leadership](https://www.elasticleadership.com): Elastic Leadership, Roy's framework for software team leaders (survival, learning and self-organizing modes). ### Social - X: https://x.com/royosherove - LinkedIn: https://www.linkedin.com/in/osherove/ ### Contact - Contact form: https://forms.gle/jQSx5KoXvrVA1JCK7 ### License Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page). License: https://creativecommons.org/licenses/by/4.0/