|
 Build engineers must often support complex build processes. Many times we inherit complex Ant and Maven scripts that can be very difficult to decipher. Usually, we also have a release to get out the door - which often leaves little time to rewrite the entire script. I have found that taking a "divide and conquer" approach reduces the complexity (especially the risk) and helps get the job done a lot quicker. Read on if you would like to see how you can structure your Ant scripts and break down the toughest build into simpler, more manageable procedures.
Past experiences I have seen many build scripts that were so complex that every member of the team was puzzled by the build procedure. Unfortunately, many developers only know how to build from their IDE (e.g. Eclipse). I remember one build that was so fragile that we had to make small changes very carefully (and hope that we could still build our code). One of the most brittle moving parts was the direct calls to the source management tool. I always recommend that calls to the source code management tool be kept in a separate script. Mixing calls to the source code repository with other build commands may sound pretty cool, but, in practice, can be hard to support. Organizing your Ant script into separate procedures is a much better way to handle complex builds and makes your job a lot easier. Here's how to do that: Organizing your procedures In this example, we will have a master Ant build script and three procedures called "A", "B" and "C". I have setup procedure "C" to depend upon procedure "B" and also procedure "B" to depend upon procedure "A", but they can all be run separately as well. The Master script calls the other procedures using the Ant call directive as follows: <target name="runA"> <ant antfile="buildProjectA.xml"> </ant> </target> Master procedure that calls the other procedures $ cat build.xml <!-- CM Basics Example Ant script calling other ant scripts --> <project name="Master" default="runC" basedir="."> <description> Test Ant 1.6.5 build file </description> <target name="runA"> <ant antfile="buildProjectA.xml"> </ant> </target> <target name="runB" depends="runA"> <ant antfile="buildProjectB.xml"> </ant> </target> <target name="runC" depends="runB"> <ant antfile="buildProjectC.xml"> </ant> </target> </project>. Here are the three procedures $ cat buildProjectA.xml <!-- CM Basics Example Ant script calling other ant scripts --> <project name="ProjectA" default="StepA" basedir="."> <description> Test Ant 1.6.5 build file </description> <target name="StepA" description="This is the first step" > <echo> "This is Step A" </echo> </target> </project> $ cat buildProjectB.xml <!-- CM Basics Example Ant script calling other ant scripts --> <project name="ProjectB" default="StepB" basedir="."> <description> Test Ant 1.6.5 build file </description> <target name="StepB" description="This is the second step" > <echo> "This is Step B" </echo> </target> </project> $ cat buildProjectC.xml <!-- CM Basics Example Ant script calling other ant scripts --> <project name="ProjectC" default="StepC" basedir="."> <description> Test Ant 1.6.5 build file </description> <target name="StepC" description="This is the third step" > <echo> "This is Step C" </echo> </target> </project> Conclusion Organizing your Ant build scripts allows you to break down any build project into smaller, more manageable, pieces. It also improves the quality of your build process by avoiding time consuming mistakes that can be very painful to debug. Please send me your tips on how to create more effective build procedures! Bob Aiello is the Editor-in-Chief for CM Crossroads and an independent consultant specializing in Software Process Improvement including Software Configuration and Release Management. Mr. Aiello has over 25 years experience as a technical manager in several top NYC Financial Services firms where he had had company-wide responsibility for CM, often providing hands-on technical support for enterprise Source Code Management tools, SOX/Cobit compliance, build engineering, continuous integration and automated application deployment. Bob is a long standing member of the Steering Committee of the NYC Software Process Improvement Network (CitySPIN), where he serves as the chair of the CM SIG. Mr. Aiello holds a Masters in Industrial Psychology from NYU and a B.S. in Computer Science and Math from Hofstra University. You may contact Mr. Aiello at raiello@acm.org or link with him at http://www.linkedin.com/in/bobaiello .
Set as favorite
Bookmark
Email this
Hits: 4762 Trackback(0)Comments (4)
|
TrackBack URI for this entry
Subscribe to this comment's feed |
... The difference for me with ANT was it seemed like bait-n-switch. You start out simple and as you learn you need to make adjustments. Over time, those adjustments become increasingly difficult to implement since you have to touch so many scripts. So, you figure, hey... I try those includes and some of these other features that take care of that. But then your scripts stop looking like Ant scripts, developer who thought they knew Ant can't comprehend what your doing. At least with Maven and a three tiered structure POMs, project, team and enterprise we can easily make course corrections at any level. Once we got build going we wanted to turn on metrics, it was a snap, literally like flipping a switch. In ANT it has been torturous. In one of the next parts of my blog article I'll go into more detail on this stuff. |
David Hegland
said:
 |
... In regards to SCC calls being in an outside script, I agree and would go one step further even! What I refer to as "my formal build scripts" really are mostly version control scripts with a call to Ant in the middle of them. The call to Ant does the actual compiling, but I look upon that as trivial. What is important is knowing what went into the build, both code and metadata like defects. So, "my formal build script" is something like this: 1 - establish the unique name of this build 2 - establish what code comprises this build 3 - establish what defects are fixed in this build 4 - get the code 5 - compile it (CALL ANT) 6 - do something with the build products So, all of my SCC activity is in 1,2,3, and 6. Ant never has to "think" about it. |
Bob Aiello
said:
 |
... Thanks for your comment Curtis. I definately agree that you need to keep it simple. Frankly, I have also seen some very obtuse Maven scripts that used Ant plugins because Maven just didn't have the features needed. So one point that I was trying to make with this article is that it is better to break down the problem into smaller, more managable pieces and then call the individual Ant scripts from a master Ant script. I definately do not like SCC calls to version control systems embedded in the Ant build scripts. I agree that they should be at separated out into separate scripts - so that WHEN they break, you can deal with them separately and still be able to build your release. I would love to hear about other people's experiences with Ant and Maven as well!!!!!!!!!!! Bob Aiello http://www.linkedin.com/in/BobAiello |
Curtis Yanko
said:
|
... As someone who has taken Ant as far as it can go with libraries and re-usable targets, facade patterns and every trick Eric Hatcher had to offer in the end it only made me appreciate Maven more. What we ended up with was obfuscated Ant that only the most advanced practitioners could comprehend and it still doesn't address the bigger issue of dependency management in a highly modularized CI build system. Or the brittleness of simply changing directions or adding functionality. The care and feeding of such a system in Ant severely limits the ability of a centralized team to scale their support. Without the centralized team the hopes of everyone doing Ant the same way are virtually zero. With Maven, our team of three can support 1000's of developers while creating a common culture where all builds always run in a predictable pattern. SCC calls should be handled by Build Management Systems. |
Write comment
You must be logged in to post a comment. Please register if you do not have an account yet.
