Comments on: Relentless Build Automation

By: Zorched / One Line Fix » Automated Subversion Tagging With MSBuild

Zorched / One Line Fix » Automated Subversion Tagging With MSBuild — Fri, 23 Feb 2007 18:05:25 +0000

[...] CompactFramework XmlEnum with WhitespacePragmatic Project AutomationHow Do You Deal With Blog Spam?Relentless Build AutomationGetting the Revision Number of your Subversion Working CopyRuby 1.8 (today) vs C# 3.0 (some future [...]

By: Allan Wick

Allan Wick — Tue, 22 Aug 2006 15:12:54 +0000

My reporting scripts are in a separate build file though… Developers don’t normally run them as part of thier development routine.

By: Allan Wick

Allan Wick — Tue, 22 Aug 2006 14:54:57 +0000

I run the build reports on every successful build as a regular part of the continuous integration cycle. I know several other buildmasters that do the same thing.

By: Geoff Lane

Geoff Lane — Mon, 21 Aug 2006 18:25:03 +0000

Al,
Good point. By running code metrics (code coverage, complexity analysis, etc) as a regular part of your build process, you can track changes over time to make sure that you are not sacrificing on quality. Most often I would recommend that this is done using a Continuous Integration server as it’s mostly a tracking, early warning system. Do you think it’s the kind of thing that belongs in a day-to-day development build script?

By: Allan Wick

Allan Wick — Mon, 21 Aug 2006 12:52:09 +0000

I also have added source code reports like Emma (Unit test Coverage), PMD/Checkstyle, JavaNCSS, etc. To provide feedback and quality metrics to the build scripts.

These reports can then be used to improve code quality as part of the build process.

By: Geoff Lane

Geoff Lane — Mon, 21 Aug 2006 03:10:38 +0000

I want to talk about relentless build automation, once you get outside of the things that you need to get a system up and running from source, then you’re outside that realm. So, error reporting wouldn’t count in my book…

The beauty of a shared automation script is that not everyone on the team has to be an expert in that scripting technology. Everyone on the team can benefit from the automation expertise of only a few people. The same way that you can benefit from having a CSS expert or a SQL expert. Everyone will know the basics, but you’ll have a “goto guy” for more complex tasks.

I also don’t think that script size is relevant, they should be as big as they need to be and no bigger. Automation with something like Ant is programming in a Domain Specific Language. It is a DSL that is optimized for scripting repeatable developer tasks (just like XSLT is a DSL for transforming XML documents). DSLs can be much more powerful and expressive because they are working at a higher level of abstraction. Take advantage of that power when you can.

If you’re build scripts can’t create a database, if they can’t populate it with test data, if it’s not an automated, repeatable process, then you can’t get a new developer up and running without intervention, you can’t deploy to a new server without manual steps, you can’t trash your development environment and start from a new hard drive without rebuilding a whole bunch of stuff by hand. Think of all the time you’re wasting.

By: Brennan Stehling

Brennan Stehling — Mon, 21 Aug 2006 02:49:39 +0000

You could also automate error reporting, but at that point it is really just programming. It seems once you have gotten past automating building, testing and deploying you are in a different territory beyond simple scripting. Sure you could write a script (Ant) which aggregates your errors and produces a report, but at that point you are allowing your scripting to bleed into the domain of what the application would be better equipped to handle.

It is best to ensure that build scripts do not go too far. To script a database you will likely have PL/SQL (or T/SQL) procedures you can schedule or set up with a trigger to run on an as needed basis which works best in that domain. I know how trivial it is to create a DTS package in SQL Server and schedule it to run nightly. And by allowing that code to be written in that language native to that area you allow the experts in that area to maintain it because not everyone on a team will take the time to learn to write an Ant script.

I also consider that automation scripts should be a very small portion of a project which act as the glue to keep everything together. If they become a significant portion of your project you have to reconsider the role of that scripts. It reminds me of how you can put looping and conditional statments into XSLT and soon you end programming more in your templating solution than you do in your actual code. Just because you can do it, does not mean it is a good idea.