Devops – The Last Mile

Here are the links to the setup.exe and the GitHub project:

https://github.com/jflowers/virgo.sample-greenpages
http://jayflowers.com/Misc%20Downloads/Workspace-Setup.exe

Principles are like lighthouses. They are natural laws that cannot be broken. As Cecil B. deMille observed of the principles contained in his monumental movie, The Ten Commandments, “It is impossible for us to break the law. We can only break ourselves against the law.” — Stephen R. Covey 

Principles don’t require our belief for them to work.  I have also understood that practices and processes flow from principles.  What I just recently learned from the book Lean IT is about practices and processes.

…we use the term process to describe a series of actions or operations supported by structured information. Processes are activities that are generally repetitive, well-defined, routine, controllable, and standardized. In contrast, practices are nonroutine, highly variable, loosely defined, and require a degree of judgment and experience to carry out.

…information used in practice work is typically unstructured, difficult to define, and often experiential. When improving practices, the focus is on supporting a learning organization through an accessible collection of knowledge of past experiences to enable situation-specific decision making. To support practice work, knowledge management systems should be designed to manage both unstructured data (searchable content, documents, and images) and structured data (information in transactional databases, drilldown reports, trend analyses, etc.). They may also provide access to collaborative social networks, forums, blogs, wikis, and other sources of free-form knowledge sharing. Over time, some of the elements of practice work may be simplified and standardized into processes, effectively creating more efficiency without sacrificing agility.

Beyond the nice GUI you could count on the url for the artifacts to conform to a pattern.  For example the weblogic release installer exe can be found at this address:

http://cir51-build03/Chapter33-5.2/Artifacts/20120314114423/Chapter33-Weblogic-Release-5.2.1.40468.exe

This enabled me to write a script, Chapter33.Deploy.Release.For.Tester.bat, that would download the http content, database installer, and weblogic installer and install the Chapter33 application in a tester’s private(local) workspace.  Well I am getting a little ahead of myself, the script also read from a CCNet REST interface.  It would gather up the build numbers for the last 6 successful Release Builds and present a GUI to the tester asking them which version of the application they would like to install.

Jenkins offers the analogous features, both artifacts for download and a REST interface, that will enable an analogous script to be written.  First lets look at the REST interface.  You can quickly see the xml from a REST request in you browser by adding /api/xml to any Jenkins page you are on.  So if you were at the following URL(a project dashboard):

Just adding /api/xml to the URL will call the REST interface:

If you want some more info on options for calling the REST API just /api to the URL…  Now the Jenkins xml REST interface is pretty cool in that you can specify the depth of information as well as tune it with an xpath query.  We will need a deeper depth of information as the current depth does not show the result, success or failure, for each build, nor does it give us the build display name.  By adding the query param depth=1 we get:

Finally we just need the build number for the last 6 successful build.  Note on my projects where we set the build display name to the SVN revision number we select the fullDisplayName as opposed to the build number here.  By adding the this xpath query xpath=(/*/build[result=’SUCCESS’])[position()<=6]/number we get the following results: 

Only 5 results are returned here because there are only 5 successful builds retained on this job.  With this REST query we have enough to get started on a Groovy script to download the artifacts.

def protocol = ‘http://’
def serverName = ‘ci.jruby.org’
def port = ”
def jobName = ‘jruby-dist-release’
def resultSetSize = 6

def restEndPointBuildList = "${protocol}${serverName}${port}/job/${jobName}/api/xml?depth=1&xpath=(/*/build[result=’SUCCESS’])[position()<=${resultSetSize}]/number&wrapper=builds"
def slurper = new XmlSlurper()
def buildList = slurper.parse(restEndPointBuildList)

def goodBuilds = new ArrayList<String>()

buildList.number.each {
    goodBuilds.add(it.text())
}

This code will create an array of the build numbers returned from the REST query.  It uses the XmlSlurper to accomplish this, both downloading the REST result and parsing it so that we can loop over it creating the array of good build numbers.  Next we need to present the user with a UI so that they may choose a build that they wish to download and install.  I did not care about making the UI pretty so I opted to use a basic antforms UI.

def goodBuildsFlat = ”

goodBuilds.sort().each {
    if (goodBuildsFlat == ”){
        goodBuildsFlat = it
    }else{
        goodBuildsFlat = it + "," + goodBuildsFlat
    }
}

def ant = new AntBuilder()
ant.taskdef(
    name:"antform",
    classname: "com.sardak.antform.AntForm",
    classpath: System.getenv(‘ANT_HOME’) + "/lib/antform.jar"
);

ant.antform(title: "Choose Which Build to Deploy"){
   ant.label("Choose a build")
    ant.radioSelectionProperty(label: "Builds: ", property: "buildChosen", values: "${goodBuildsFlat}")
}
def buildNumber = ant.project.properties.buildChosen;

The antforms task will accept a comma separated value string of options to make radio buttons out of.  I wanted them to be sorted, that is first bit of code here.  Next we need to load the antforms task.  You can see here that the jar is loaded from the ant lib dir.  You could load it from anywhere…  After the ant task has been loaded we call to display the form passing in several options like a title and labels.  When the user clicks the OK button the ant property buildChosen will contain the value they chose.  This is placed in the local variable buildNumber.

def restEndPointBuild = "${protocol}${serverName}${port}/job/${jobName}/api/xml?depth=1&xpath=/*/build[number=’${buildNumber}’][1]"

def build = slurper.parse(restEndPointBuild)

build.artifact.each {
    def artifactFileName = it.fileName.text()
    def artifactRelativePath = it.relativePath.text()
    def artifactUrl = "${protocol}${serverName}${port}/job/${jobName}/${buildNumber}/artifact/${artifactRelativePath}"
    download(artifactUrl, "C:\\Temp\\${artifactFileName}")
}

Next the script makes a REST query getting the build details for the build chosen.  It then loops over the artifacts published in that build downloading each.  This is the part of the script that you will need to start tailoring to your needs.  Where do you want to download to?  Do you want to download all the artifacts or just a specified few?  What are you going to do after downloading the artifacts?  On the project that I am working on at the moment we publish full on headless installers.  After downloading these installers we execute them.  This provides a push button script for the testers or anyone on the project to deploy a personal instance of the application any time they wish.  They even get to choose the version they want to install.

Ooh before I forget here is the last bit of the script, the download method.  I used Curl so that if the download fails it will pick back up where it left off we you retry.  This assumes that Curl is in your PATH.

def download(url, destination){
    String command = "-0 -m 86400 -S -C – -o \"${destination}\" -k -L –retry 5 ${url}"

    def ant = new AntBuilder()
    ant.exec(executable: "curl"){
        arg(line: "${command}")
    }
}

This build server was working on the 5.2.1 branch and the most recent build was of SVN revision 40468.  This allows developer to easily communicate what build their changes or fixes are in.  So for example a tester can easily understand which build they want to download, install, and test…  That is very convenient, yes?

Jenkins does not have this feature.  In all fairness neither did CCNet, we had to write a plugin.  In this case I found a Groovy plugin for Jenkins that I used to script up a solution.  The documentation for the plugin can be found here.

I made the first build step a system Groovy step and added the following code:

Executing as a system Groovy step means this will be executed in the same JVM as Jenkins, allowing access to all the Jenkins objects…so we can alter the build display name.  The first two lines are importing the Jenkins(Hudson) packages.  The javadocs for what is available are located here.

import hudson.model.*
import hudson.util.*

The next line is a neat little trick that will give you a reference to the current build.

def build = Thread.currentThread().executable

We will first use this build object to get the workspace folder path.  This is where the build is executing out of.  We need this piece of information so that we can execute the subversion command “info” in the root of the workspace.

def workspace = build.getWorkspace()

In Groovy if you want to specify the directory from which to execute a shell command and you want to capture the command’s output the easiest way to use the Ant task exec like so:

def ant = new AntBuilder()
ant.exec(executable: "svn", outputproperty: "output", dir: workspace){
    arg(line: "info")
}

svnInfo = ant.project.getProperty("output")

That captured the out of the svn “info” command into the variable svnInfo.  Now we can use a regular expression to extract the revision we are currently on.  Here is some example output from an svn “info” command:

C:\Projects\Chapter33\Trunk\Build>svn info
Path: .
URL: https://va33-repo01/svn/Chapter33/Trunk/Build
Repository Root: https://va33-repo01/svn/Chapter33
Repository UUID: f1ce2e10-74e2-f14b-9613-4d7166fa18d4
Revision: 40498
Node Kind: directory
Schedule: normal
Last Changed Author: bassettt
Last Changed Rev: 40484
Last Changed Date: 2012-03-14 16:24:37 -0400 (Wed, 14 Mar 2012)

We want to extract from all that the Last Changed Rev value, and we can do that with this code:

def pattern = /Last\s+Changed\s+Rev:\s+(\d+)/
def matcher = (svnInfo =~ pattern)

def buildLabel = ‘Dev-‘ + matcher[0][1]

We take the extracted value, in this example 40484, and set a variable named buildLabel to “Dev-40484”.  Lastly we set the Jenkins build display name.

println ‘setting build label for this build’

build.setDisplayName(buildLabel)

This results in a Build History widget that looks like this:

If you are familiar with Jenkins you might ask why not just use the Build Name Setter Plugin?  I would have but the svn env var Jenkins sets is often incorrect as documented here(I too see this bug).  So I wrote my own solution…  I also use variations on this to show versions of the application as the move through the build pipeline.  Instead of grabbing the build name from subversion in downstream builds I grab it from the triggering upstream build.  There are lots of interesting uses for this.

If they have been the norm what has changed to allow us to go a different route?  Two things: first increased performance of workstations and laptops and second improved automation in the dev/test workspace.  Increased performance in hardware has allowed us to run more servers in a local workspace.  On my laptop I can easily run several Weblogic servers and an Oracle Database with resources left for an IDE and other dev/test tools. Not so long ago this was impossible.  Managing all my servers, the applications running on them, and one or more databases would leave little time to do anything else in a fast changing development project.  Automation alleviates this time sink.  Providing push button headless automation to setup, deploy, and manage these servers is key.  This too was thought of as impossible not to long ago, yet fully automated deployments are more and more common these days.

Okay, so maybe it is possible you say.  Why would I want to do this?  Haven’t shared environments been working…

No, I don’t think they have been working.  The whole purpose behind this change is to enable developers and testers to test the application more easily, spend less time identifying and recovering from collisions, and for developers specifically to spend less time chasing the version of the shared env.  When several people share an environment they can easily collide with each other.  There are many types of collision, they depend on the architecture of the application under test as well as it’s dependencies.  Many of these types of collision revolve around data.  There are schemes to minimize data collisions, yet no scheme is foolproof.  If every developer and tester has a private environment to work in several things become possible:

• testers and developers can easily roll back to any version of the application to replicate a bug, or return to last working version
• testers and developers can execute automated tests at will, or any kind of test for that matter, no more collisions due to data, execution resources, etc…
• no one is forced to update to a new version of the application, in shared envs updates are normally done nightly, for example a developer could work uninterrupted on a bug through one day and into the next, i.e. no more chasing the shared env version…

All of these things will dramatically increase the productivity of a team!

At this point you may think that I am claiming that a whole environment should be hosted locally on a developer/tester workspace.  I am not.  I only think that all read/write servers should be local.  Readonly servers could, most of the time should, be shared.  Remember that what counts is how you interact with the server.  If your application only ever reads from it then you should treat it as a readonly server.

If you search around the internet on this subject you will mostly find that this subject has been written on from the database point of view.  Here are a few good examples:

• The unnecessary evil of the shared development database
• Working on a Shared Development Server is Bad
• Top 4 Reasons Why a Shared Development Database is Evil.

Most of the issues that have been documented around shared database servers effect shared webservices, EJBs, .Net Remoting, REST, etc…

Just in case you are not yet convince let’s try some systems thinking.  This situation of shared servers or resources indicates that we should take a look at the archetype “Tragedy of the Commons”.  This is taken from the site http://www.systems-thinking.org:

Tragedy of the Commons

The Tragedy of the Commons structure represents a situation where, to produce growth, two or more Reinforcing Loops are dependent on the availability of some common limited resource.

A’s activity interacts with the resources available adding to A’s results. A’s results simply encourage more of A’s activity. The same sequence plays out for B’s activity. And, the more resources used the greater the results. This simply encourages A and B to use more resources.

A’s activity and B’s activity combine to produce some total activity. This total activity subtracts from the resources available. The extent of the resources available being defined by the resource limit.

Total activity continues until it completely depletes the resources available. When this happens A’s results and B’s results stop growing as there are no more resources to use. What makes this structure even worse is that whoever figures out the structure first, A or B, wins because they use all the resources before the other has a chance to. This structure is often referred to as "All for one and none for all."

Managing the Structure

This structure repeatedly appears in organizational contexts where a service organization supports the success of multiple departments who fail to support the service organization in return. There are two strategies for dealing with this structure, one more effective than the other.

• The most effective strategy for dealing with this structure is to wire in feedback paths from A’s results and B’s results to the resource limit so as A and B use resources their results promotes the availability of additional resources.
• The alternate, and less effective, strategy for dealing with this structure is to add an additional resource to control the use of resources by A and B. This strategy limits the overall potential results of the structure to the predefine resource limit. It also adds additional resource to the equation, and probably results in endless disputes as to the fairness associate with the allocation of resources. While not really the most appropriate strategy this is the one most often used — out of ignorance I would suspect.

Examples

• If It’s Free I Want All I Can Get
• When Fair is Unfair

In our case the resource can be replenished in a couple of ways depending on how it was or is being depleted.  A scorch and rebuild of the data will replenish a data depletion.  If the server resources, CPU, memory, IO, etc… where depleted then simply curtailing the over usage will replenish the server.  I find this site’s offered solutions lacking.  It’s presentation is as if it is a syllogism.  An easy third solution is to dedicate a resource per user.  This removes some of the limiting factor from the system and all of the shared aspect leaving a set of independent reinforcing loops, one per user.  I this case both A and B get their own resource. 

http://veterans.house.gov/prepared-statement/prepared-statement-hon-roger-w-baker-assistant-secretary-information-and

Witness Testimony of Hon. Roger W. Baker, Assistant Secretary for Information and Technology and Chief Information Officer, U.S. Department of Veterans Affairs

 

Hearing on 03/11/2012:

 

Introduction

Chairman Johnson, Ranking Member Donnelly, members of the Subcommittee: thank you for inviting me to testify regarding the Department of Veterans Affairs’ (VA) Information Technology (IT) strategy for the 21st century.  I appreciate the opportunity to discuss VA’s plans, actions, and accomplishments that will position VA’s IT organization as a 21st century leader in the Federal Government.

1. Product Delivery

IT is an enabler to the implementation of the Secretary’s 16 Transformational Initiatives, which cannot be executed without newly developed IT products.  These initiatives are key to improving VA’s services to Veterans, and IT investments have allowed us to deliver products or plan for on-time delivery of the following programs:

• Successful, on-time delivery of the critical G.I. Bill project. VA successfully converted all processing of new Post-9/11 GI Bill claims to the Long Term Solution (LTS) prior to the commencement of the Fall 2010 enrollment process.  Since installation, processing with the new system has been excellent, with no significant “bugs” encountered.  The Veterans Benefits Administration claims processors like the new system and find it easier and more efficient to use.  By dramatically changing its development processes, adopting the Agile methodology for this project, VA also dramatically changed its system development results;

Agile development

A primary driver of our success under PMAS has been the adoption of incremental development.  Every project at VA, without exception, must deliver functionality to its users at least every six months.  Several of our most important projects, including the GI Bill and VBMS, have adopted Agile development methodologies. Whereas PMAS addresses the planning and management aspects of short, incremental delivery, the Agile development methodology provides the technical management guidance of how to turn project requirements into working software quickly and in collaboration with the customer.  

Agile development is important to the VA because it encourages continuous input from our customers.  In agile projects, all the development priorities are set by the customer, which ensures that the work is performed in the order of importance.  To increase the likelihood of success, large projects are broken down into small but valuable increments, each of which could potentially be a candidate for release.  This is consistent with our PMAS delivery requirements.  Lastly, agile development requires continuous quality assurance throughout the entire development effort, further ensuring high quality deliverables.

Agile software development methodologies are an effective means of improving the predictability, quality, and transparency of software products and their development. At the core of Agile is the iterative work process. Business problems are broken down into small increments of delivery that are tangible products that can be reviewed and verified regularly by business stakeholders. By constantly incorporating feedback, the software that is essential to solving the business problem is created in partnership with stakeholders and any miscommunications, revisions, or changes in business needs can be accommodated quickly and with little rework. The quality of software is kept high throughout the development process as the product in development is kept as close to a production-ready state as possible with each release increment. In addition, prior to the start of each increment, business stakeholders and the development team agree upon which features or requirements are to be satisfied during that increment thus ensuring that the most important work is completed first.

Contrary to popular belief, the successful Agile program requires great rigor as it is essentially a process based on statistical analysis. Every work product (software or otherwise) is defined, broken down and estimated. As work progresses, these work products are carefully tracked on a daily basis and results of progress are published to the team and stakeholders (and any other authorized, interested party) to provide complete transparency. The result of this hyper-transparency is that problems in the development process are identified early and changes, regardless of their origin, can be accommodated quickly and efficiently.

I am honored to work on this project.  We have accomplished a significant number of releases in the course of the project.  I am proud to say the we truly are practicing Agile.  This is the first project where I have gotten to implement automated deployments all the way to production!  I hope the next project I work on is as rewarding as this one is.

On a simple and small project this would entail:

1. Update to the latest source
2. Recompile (a clean compile)
3. Run all the tests (may require a local deployment)

The larger and more complex the project gets the less tenable this procedure becomes.  When you end up with thousands of unit tests, thousands of integration tests, and hundreds of user acceptance tests, functional tests, etc… it becomes unreasonable to run all of them every time before you commit.  To run all these tests would take a long time.  So how long is acceptable you say?  You need to decide that for yourself.  The project I am working on as I write this has decided that the whole precommit process should take about 30 minutes.  That doesn’t mean that we throw away tests until we can complete the process in the allotted time.  We need to take educated guesses as to which tests we should run, which tests are most relevant to the changes that are being tested.  For example if I was making changes to how the system processes orders there would be no value in running tests on product comparison.

In the book “Software Configuration Management Patterns: Effective Teamwork, Practical Integration” the pattern Private Build System is basically the same thing:

Context

A Private Workspace allows you, as a developer, to insulate yourself from external changes to your environment. But your changes need to work with the rest of the system too. To verify this, you need to build the system consistently, including building with your changes. This pattern explains how you can check whether your code will still be consistent with the latest published code base when you submit your changes.

Problem

How do you verify that your changes do not break the build or the system before you check them in?

Solution

Before making a submission to source control, build the system using a Private System Build similar to the nightly build.

This patlet raises the why of it: why do we need a precommit process?  And just like it says to make sure that we do not break the codeline (i.e. trunk or a branch).

Why don’t we want to break the codeline(build)? So that we don’t negatively affect the rest of the team.

How would breaking the codeline(build) negatively affect the rest of the team?  In two ways; first it would prevent anyone else from committing to the build as we follow the rule of not committing on top of a broken build, two if anyone updates from source control their local build will be broken too.

Why is blocking the build a bad thing?  It is not so bad if you fix the build quickly.  It really only becomes a bad thing when it is broken for an extended period of time.  This prevents others from committing to the build and so they continue to work, increasing the size of their changeset.  Large change sets are more likely to break the build, and when they do break the build they usually take a long time to fix.  This can easily lead to a situation where the build is often broken for extended periods of time.

Why is having the build broken for extended periods of time or all the time a bad thing?  The build then looses it usefulness.  It is clearly no longer keeping the codeline stable, which is its purpose.

Those 5 whys get us to the root of it.  We need a precommit process to support a centralized build process.  They also paint a picture that many feel is a slippery slope, causing great fear of breaking the build.  The danger is in how long you let any given broken build remain broken.  As long as you fix the build quickly, or rollback the offending changes to last good build quickly there is no danger.

Fear of Broken Builds

Fear of breaking the build has caused some people to adopt measures to keep the build green at all costs.  There are several commercial CI Servers that play into this fear with features that provide precommit isolated private builds.  These are builds that occur outside of the developer’s workspace, they are private in the sense that the results are only shown to the developer who submitted the changes and the changes don’t make there way into source control unless the build passes.  Another common measure is to insist that all tests are run as a part of the precommit process.  Both of these have the side effect of increasing the average size of a changeset committed to the build.  Granted that these large changesets will pass the build…they will not necessarily be easy to integration into each developer’s workspace.  The larger the changeset the greater the chance it will impact changes in a developer’s workspace, especially if the local changes are large as well.  Gradual changes over time are easier to integration into a developer’s workspace than big bang changes.  A significant compounding factor with big bang changes is that they tend to be committed at the end of an iteration.  This means you would likely have multiple developers competing to commit large changesets at the end of an iteration.  When the competition gets rough developers often rationalize breaking the build in favor of being able to commit their changes hoping to differ testing to the next iteration. We finished the story, except for the testing, we’ll test it next iteration.

Working in Small Changes

If the team works by decomposing stories into small tasks, tasks that can be completed in less than a day, preferably a couple of hours, things can work very smoothly.  Imagine that every hour or two the developers are committing changes as they complete tasks.  Their precommit process would involve integration of a small number of changes from a source control update and executing a small number of tests to exercise their changes.  I am sure you can see how this would result in a short precommit process with little chance that the updates from source control would impact local changes.

Below is a loop diagram that shows some of the forces and effects task size can exert on CI.  If you have never seen a loop diagram before you can read this diagram by ideas relating to each other either in the same way or in the oppisite way.

As task size increases changeset size will increase as well.  People tend to commit changes when they have completed a task.

As changeset size increases so does the average time to fix a build.  When a build breaks and the changeset size was small it is generally easy to know what went wrong and fix it.  If the changeset size was large there are more things to suspect, investigate, and debug.  This takes longer.

As the average time to fix a broken build increases the build availability decreases.  This is assuming that you don’t allow committing changes to a broken build…the more often you have hard to fix builds the less available the build will be.

As the build is less available the changeset size will increase.  This is because developers will continue working while the build is not available, thus increasing the size of their changesets.

As changeset size increases the build stability will decrease. This is because the build breaks more often with large changesets than small changesets.

As build stability decreases the development environment tractability will decrease.  It is more difficult to work on a codeline that is unstable than a stable codeline.

As the environment tractability decreases the rate of change to the codeline will decrease.  Again it is more difficult to work on an unstable codebase.

As the rate of change decreases there will be less broken builds.  If you have a high rate of change you will have more broken builds.

As the number of broken builds increases the build availability will decrease.

I don’t mean to show this loop diagram as a standalone or complete system.  There are other forces that can come into play here to address the number of build breaks, how long it takes to fix a broken build, or even isolating build breaks.  These are important.  But they are not the core system.  This is the core system and the root input affecting the system’s output is the size of tasks.  If people are working with small tasks they will break the build far less often and when they do it will be easy to fix.  If people are working with large tasks they will break the build often and when they do it will be difficult to fix.  From what I have seen it works best when one or more small tasks can be completed in a day.  You will need to figure out what works on your project. 

You can also add to this diagram mitigating forces such as a precommit developer build to help control the number of broken builds.

P.S. If you are having a hard time getting task sizes down maybe you should draw a loop diagram of the forces at play keeping task sizes large on your project.

That is not a clear enough picture though.  Depends is not just for defining a dependency chain, it also includes the much desired feature of run once.  That is to say when I call the target deploy, compile will only been run once even though both recompile and unittest depend on it.

The output from calling the target deploy would be:

c:\>ant -f scratch.build.xml
Buildfile: scratch.build.xml

clean:
[echo] clean missile

compile:
[echo] compile the missile

recompile:

unittest:
[echo] test the missile

package:
[echo] package the missile

deploy:
[echo] deploy the missile

BUILD SUCCESSFUL
Total time: 0 seconds

Sidenote: you should almost never use antcall.  It violates the principle of least astonishment.  You should think of it like you are ask for Ant to execute the target in isolation.  You should use runtarget from Ant contrib.

I have found the use of orchestration targets to be far more powerful when I can ask for a target to be executed and optionally specify that it only be run once.  The depends run once is not as robust as you might think.  If you call multiple targets from the command line run once does not always work:

c:\>ant -f scratch.build.xml recompile unittest
Buildfile: scratch.build.xml

clean:
[echo] clean missile

compile:
[echo] compile the missile

recompile:

compile:
[echo] compile the missile

unittest:
[echo] test the missile

BUILD SUCCESSFUL
Total time: 0 seconds

What would be ideal would be the following.

With the output:

c:\>ant -f scratch.build.xml recompile unittest
Buildfile: scratch.build.xml

recompile:

clean:
[echo] clean missile

compile:
[echo] compile the missile

unittest:
[echo] test the missile

BUILD SUCCESSFUL
Total time: 0 seconds

I implemented the call task with a macrodef that checks if the target has been run; this is tracked by checking the existence of a property.

This macrodef depends on a property being set after the successful execution of every target.  To accomplish this I created a simple logger to set a property for each target called; source is at the end of the post.  I also made sure that the logger was loaded with the script task at the beginning of the Ant project file.

Once you have this functionality you can begin to orchestrate in more robust ways.  With depends you can only string targets together, one after the other with no customization between the execution of each target.  Now you have the opportunity to wrap each and every target call with any customization you can write.  You can reuse in any way you want.  For this example we only want to compile and package on a developers machine (e.g. env.dev==true).

c:\>ant -f scratch.build.xml -Denv.dev=false
Buildfile: scratch.build.xml

deploy:
[echo] deploy the missile

BUILD SUCCESSFUL
Total time: 0 seconds

package com.agilex.ant;

import java.lang.reflect.Field;
import java.util.Enumeration;
import java.util.Hashtable;
import java.util.Vector;

import org.apache.tools.ant.BuildEvent;
import org.apache.tools.ant.BuildListener;
import org.apache.tools.ant.Project;
import org.apache.tools.ant.ProjectHelper;
import org.apache.tools.ant.Target;

public class TargetListener implements BuildListener {

@Override
public void buildFinished(BuildEvent arg0) {
// TODO Auto-generated method stub
}

@Override
public void buildStarted(BuildEvent arg0) {
// TODO Auto-generated method stub
}

@Override
public void messageLogged(BuildEvent arg0) {
// TODO Auto-generated method stub
}

@Override
public void targetFinished(BuildEvent event) {
Target target = event.getTarget();
if (event.getException() != null)
this.forceProperty(event.getProject(), event.getProject().getName() + “.Target.” + target.getName() + “.State”, “Failed”);
else
this.forceProperty(event.getProject(), event.getProject().getName() + “.Target.” + target.getName() + “.State”, “Success”);
this.forceProperty(event.getProject(), event.getProject().getName() + “.Target.” + target.getName() + “.Executed”, Boolean.toString(true));
}

@Override
public void targetStarted(BuildEvent event) {
Target target = event.getTarget();
this.forceProperty(event.getProject(), “Target.” + target.getName() + “.State”, “Running”);
}

@Override
public void taskFinished(BuildEvent arg0) {
// TODO Auto-generated method stub
}

@Override
public void taskStarted(BuildEvent arg0) {
// TODO Auto-generated method stub
}
private Object getValue( Object instance, String fieldName ) throws IllegalAccessException, NoSuchFieldException {
Field field = getField( instance.getClass(), fieldName );
field.setAccessible( true );
return field.get( instance );
}
private Field getField( Class thisClass, String fieldName ) throws NoSuchFieldException {
if ( thisClass == null ) {
throw new NoSuchFieldException( “Invalid field : ” + fieldName );
}
try {
return thisClass.getDeclaredField( fieldName );
}
catch ( NoSuchFieldException e ) {
return getField( thisClass.getSuperclass(), fieldName );
}
}

private void forceProperty(Project project, String name, String value) {
try {
Hashtable properties = (Hashtable) getValue(project, “properties”);
if ( properties == null ) {
project.setUserProperty(name, this.parseProperty(project, value));
}
else {
project.setProperty(name, this.parseProperty(project, value));
}
}
catch ( Exception e ) {
project.setUserProperty(name, this.parseProperty(project, value));
}
}

@SuppressWarnings(“deprecation”)
private String parseProperty(Project project, String value){
Vector fragments = new Vector();
Vector propertyRefs = new Vector();
ProjectHelper.parsePropertyString(value, fragments, propertyRefs);

if (propertyRefs.size() != 0) {
StringBuffer sb = new StringBuffer();
Enumeration i = fragments.elements();
Enumeration j = propertyRefs.elements();
while (i.hasMoreElements()) {
String fragment = (String)i.nextElement();
if (fragment == null) {
String propertyName = (String)j.nextElement();
fragment = project.getProperty(propertyName);
}
sb.append( fragment );
}
return sb.toString();
}
return value;
}
}