This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Hello I have been using small ANT scripts for small automated functional testing for about 5 months now. I now have it configured to work with Visual Age 3.5. I am looking at attempting to build a script that will be able to pull all the code out of Visual Age, compile, package and prepare for (or just do it) deployment. I have looked at other ANT scripts that cover conditional operations such as if jar files present do or don't do this, functional tests, unit tests, and everything under the sun. However. I have a slightly different requirement and I am wondering how best to put the structure together. The best way to describe it is to start with the development use of the code. (Application UI developer, Web Application UI Developer, Common Components developer -- develops common stuff for both UI groups, and BuildMaster). Obviously based on application layering, the different groups will want different "views" of the code and as a result, different purposes/requirements of the script ( exporting, compiling, functional tests, etc..). How do I design my ANT script to support this? - lots of conditional targets that are driven from the parameter that is passed in? - separate the ANT scripts out into different smaller ones that get called from the main script that is invoked for each specific group(i.e. Application UI developer invokes the scripts as ANT -f applicationBuild.xml) I have thought about adding a specific task per purpose per logic grouping of projects within Visual Age but I am now thinking that that may cause the script file to become too large and a maintenance problem. And I am also trying to keep in mind that the users of the Script may not actually know what the script is doing just that it is the one they want so I have to watch out for default behaviour requirements? i.e. when a full-fledged build is taking place, everything is required. During an incremental build, not everything is required. The application UI Developer will only want the latest code from the Application UI code and the common components parts (along with the functional tests of them as well), but not the code or tests from the online development group. any thoughts on how I should proceed? thanks. Rob
How do I design my ANT script to support this? - lots of conditional targets that are driven from the parameter that is passed in? - separate the ANT scripts out into different smaller ones that get called from the main script that is invoked for each specific group(i.e. Application UI developer invokes the scripts as ANT -f applicationBuild.xml)
Great question and it's this type of question that we address in the book. IMHO, a basic quesiton with any tool is how can one use it in the large. It is in this sense that IMHO, both make and ANT have some difficulties. The solution outlined in the book is to carefully categorize and then contain each element of the build into it's own container. Speaking in terms of ANT, this means, one should make use of property files and as well as several build files. Most build files will actually do real work but, you'll also need at least one build file that will orchestrate the flow of the build. The characteristics of ANT that you must be wary of include the immutability of properties. Consequently, managing your name space becomes very important. Fortunately, we have patterns for success (or near success) to help us out. The one pattern or model that comes to mind are URLs. If one takes the rules that apply to URLs and adapts them for ANT properties, then one can avoid a lot of difficulties. This is but one solution, there are a number of others. Applying an adapted set of rules.
I have thought about adding a specific task per purpose per logic grouping of projects within Visual Age but I am now thinking that that may cause the script file to become too large and a maintenance problem.
You are quite correct in being wary of the size of the scripts. The primary techniques that I use to manage this are all take-offs of writing OO code. First, we all know the stressors, small methods are more reusable but add to the problem of trying to manage them. There are no hard and fast rules to solve this one but, I try to keep related bits of functionality together. For example, if I need to compile source, then I would make the target subdirectory as part of that compulation target. Secondly, if you try to divide on the principle of volitility, then you may find that you don't have to maintain as much as you first thought you might. For example, I try to ensure that no one has to look at the build script it's self. I find that the most volitile information is that which describes the system in which the script will operate. Consequently, I will either keep that information at the top of the build script (in the form of properties) or in a seperate properties file. The more volitile, the further I want to stay away from the actual build script it's self. For instance, I might keep SCC user id/password information in a seperate properties file in the users home directory. This information is highly volitile accross a development team. Slightly less volitile would be the values for the home directories of third party products. Slightly less volitile would be the names and the locations of the jars that are included with that third party product. And (hopefully) even less volitile would be your deployment/test/development environment. Having some sort of taxonomy like this will go a long way to helping you maintain reasonable size limits on your build scripts and will also help you manage change.
And I am also trying to keep in mind that the users of the Script may not actually know what the script is doing just that it is the one they want so I have to watch out for default behaviour requirements?
If the UI people only have a build script for the UI portion of the application and the others only have the bits that they need, then you have just used configuration management to eliminate the problem. Using an upper level script to coordinate a full build/release becomes much more managable in this type of situation. There is also another OO principle at play here, deligation. If you deligate functionality to each of the groups, then they will get what they need (as a matter of developing the process). It really says, don't do what others should be doing. So, let the UI people decide what they need to do. Just agree on a standard template (or interface) so that all can play together. As I mentioned earlier, this is exactly the type of question the advanced portion of the book tries to answer. HTH, Kirk
Author of <a href="http://www.amazon.com/exec/obidos/ASIN/0672324261/ref=jranch-20" target="_blank" rel="nofollow">Ant Developer's Handbook</a>
Joined: Sep 20, 2002
Hi Kirk. thank you for the reply. I believe you have addressed everything that I was considering potentially challenging and I must apologize as I forgot to mention about the interest in this process. I know what ANT can do but not everyone on the team has the same understanding or technical knowledge to understand (ranging from UI developers to Management) the power of ANT and automated builds (and incremental integration testing). By organizing some build scripts that can be run by different users (UI, common, buildmaster) and by running the same script, I want to show the same script can be used for full fledged builds as well as incremental exports to ensure functional testing done by developers is done by the most recent code which will improve the build process. Therefore, I need to attempt to think of all requirements when building it. My technical knowledge of the environments, users, Java and ANT are I believe (I hope) enough to be able to provide something to the team to show its power.
Originally posted by Kirk Pepperdine:
Most build files will actually do real work but, you'll also need at least one build file that will orchestrate the flow of the build
I believe your answers have convinced me to structure the specific pieces as separate build files with the one main one as the controlling piece. As we are currently using Visual Age, one or two of the targets per component / UI piece will be tied to Visual Age functionality. Using OO concepts, as you suggest, I will isolate these pieces in their own separate buildfiles. thanks again for you quick and detailed responses. Rob
Joined: Jan 17, 2001
not everyone on the team has the same understanding or technical knowledge to understand (ranging from UI developers to Management) the power of ANT and automated builds
IME, the organization that you're describing sounds pretty much normal. The one thing that will help your cause is to find a point of irritation in the build process and use ANT to remove it. For example, I was stationed at a place where the CM team were performing a build from a recepie provided by the developers. Needless to say, the process was error prone due to finger problems and/or step/artifacts that the development team totally missed. On top of that, the build was just one huge monster build! Mix in the fact that both management and CM were reluctant to change (a certian case of, we know it's broken but were ok with that because it's familiar). So, typical stuff, FUD takes over. In this case, I identified one small portion of the process to ANTify (is that even a word? ). Fortunately, the responsible developer was responsible . He converted that portion of the build and then we got CM interested. Once they had drank the purple cool-ade, there was no turning back. The duration of their long arduous build process was reduced to minutes and if the build script broke, they could throw something back at the developers which placed the problem back squarely where it belonged, on the developers plate (important point, developers own ANT scripts because it's an artificat of the development process, CM owns the template from which the scripts are built. Template design is a shared activity). There were other effects that trickled through the organization. For one, CM was no longer the goat in the deployment process. The time that was freed up by using ANT was then used to start improving the entire CM process which had positive feedback into the development process (less stove piped, more iterative) which in turn had the effect of even further reducing the defect rate in the process (and in development). One thing to be aware of, the change was evolutionary, not revolutionary. IOW, it took about 3 months to really grab hold so, patients, persistance, and a little evaglisum along with a good dose of "show me" will all most likely be needed even if management realizes that it should be done.
I believe your answers have convinced me to structure the specific pieces as separate build files with the one main one as the controlling piece.
Yes, that's what I'd recommend. HST, each of the seperate build pieces should be functional independent of the upper build script. Chapter 9 of our book dives into this in detail. Good luck!
Joined: Sep 20, 2002
Kirk, thank you. yes, I have been going through the evolutionary soapbox preaching for about 2 months now. The hardest part that I have seen is getting upper management to recognize that the flaws identified which we accept could be corrected and thus , as you say, improve the misconception of the "CM" - build process failing, and thus create a better and faster development turnaround. I have recognized within management that they find it difficult to have an individual work on something that doesn't map "physically" to a CR being implemented. (Personally, I find this one really hard to put together a business case for , but that's another discussion) In part of my soapbox preaching I have mentioned to many different people (developers, functional, management), that these scripts / tests could evolve over time and the functional testing could improve greatly and, again,as you say, improve the process. In converting to fully using ANT, the only potential issues that I have seen are 1) we currently package code as jar files and we like to create "upgrade" files that only contain the differences from one build to the next. This I believe still needs to be done via the UNIX script that we have (which basically uses UNIX CVS)... 2) starting / stopping WebLogic. As we have a differnt script to start weblogic (use of AWK), I am not sure if the problem is in the Weblogic start up script or in my preliminary use of ANT script trying to invoke the script. 3) Management giving me time to work on it. * grin * Kirk, thanks again for your valuable input and time. Rob