|
 All of the industry standards (e.g. IEEE 828, EIA 649-A) and frameworks (e.g. Cobit 4.1, ITIL v3) state that all Configuration Items must be controlled and uniquely identified. Many CM experts get a little puzzled by this requirement and I am often shocked to find out how many production releases have runtime components that cannot identify themselves to the operations support team. It's really not hard to make all of your release components fully capable of identifying themselves. In this article I will show you a couple of ways to do this. One method is to use Ant to update the MANIFEST in your jar and the other is to write a little java code and embed that in your release. Read on if you want to comply with industry practices - not to mention the spirit of Sarbanes-Oxley IT Controls.
In my C++ days I used to do a lot of release management in a C/C++ shop where would embed a static char variable with strong that could be accessed using the SCCS what command. This was called "whating" an executable and it worked pretty. When the New York Stock Exchange went down for one hour, many years ago, we used this command and our trusty release map to show senior management how the CM team could immediately account for every runtime component in the release. So today, I am amazed at how many Java SOA developers write applications that do not give you any way to ascertain their version id - let alone the version label or tag used to build them. It turns out that Ant gives you an easy way to update the MANIFEST in the jar with the version id (and anything else that you would like to put in there as well). Updating the MANIFEST in Ant In the Ant script below I set two properties show the version number and the build number. In this little example, I do it manually, but obviously you can update this using a perl script when you automate your build and deploy. I usually pull out the release based upon a version label or tag and, in the same script, update the tokens to automatically document the Version and Build Numbers. The manifest command updates the MANIFEST with the properties that I set. $ cat build.xml <project default="dist"> <target name="myTest" depends="dist"> <java fork="true" classpath="dist/apps.jar" className="myTest" /> </target> <target name="dist" depends="compile"> <property name="version.num" value="2.01"/> <property name="build.num" value="1.00"/> <manifest file="MANIFEST.MF"> <attribute name="Main-Class" value="myTest"/> <attribute name="Version-Id" value="${version.num}-b${build.num}"/> </manifest> <jar basedir="build" destfile="dist/apps.jar" manifest="MANIFEST.MF" /> </target> <target name="compile" depends="init"> <javac srcdir="src" destdir="build" /> </target> <target name="init"> <mkdir dir="build" /> <mkdir dir="dist" /> </target> <target name="clean"> <delete dir="build" /> <delete dir="dist" /> </target> </project> So then you can also write a little script to pull this information out as I do in these manual steps. $ jar -xvf dist/apps.jar MANIFEST.MF $ cat MANIFEST.MF Manifest-Version: 1.0 Ant-Version: Apache Ant 1.6.5 Created-By: 1.5.0_09-b03 (Sun Microsystems Inc.) Main-Class: myTest Version-Id: 2.01-b1.00 WhoAmI ? I also created a little class called WhoAmI and a method called $ cat src/WhoAmI.java // WhoAmI.java import java.io.*; import java.util.*; // Simple example of a class embedded in a jar // that identifies the Version and Build number for the jar public class WhoAmI { static void printVersionID () { System.out.println("Version Number 2.01 Build Number 7"); } } Testing my little printVersionID Here is my little test program that invokes the printVersionID $ cat src/myTest.java import java.io.*; public class myTest { public static void main(String[] args) System.out.println("Hi there"); WhoAmI myWhoAmI = new WhoAmI(); myWhoAmI.printVersionID(); } } I invoke this class from my test program as follows: $ cat runme.bat java -jar ./dist/apps.jar Obviously, from a technical point of view, I will not be impressing anyone with my technical prowess as a java developer. I believe that the best solutions are usually the simplest and both these methods are a good start to being able to make sure that all of your configuration items can identify themselves. In the future Now the way that I really want to do this is to write a cryptographic signature such as MAC SHA1 and wrap the jar with a signature that cannot be revoked (non-repudiation). But I would suggest that many organizations should start by confirming that all of their runtime components can identify themselves. We'll get to the advanced stuff soon! You can find out lots more information on Ant by visiting http://ant.apache.org. Build engineering is a lot of fun and learning more about Maven and Ant will put you in a good position to setup your builds in a reliable and repeatable way! Make sure that all of your Configuration Items (CIs) can identify themselves and you will have taken an important step in implementing CM best practices! 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
Set as favorite
Bookmark
Email this
Hits: 4297 Trackback(0)Comments (5)
|
TrackBack URI for this entry
Subscribe to this comment's feed |
... Hi There, I liked the article but i am bit confused with Version-Id: 2.01-b1.00; does this mean 2.01 is the version number of apps.jar file and 1.00 is the build number?? If we are building the jar file from the codebase, then this version 2.01 should be same as that of build number as jar is being built and every time the build/version number gets incremented. One more thing, as per the article, we are talking about configuration items but when we talked about application (myapps.jar; as per my understanding from the article), it turned out to be a release componenet. Regards Deepak Verma. |
Bob Aiello
said:
 |
... Slava, as always you are an expert with a wealth of information. Yes you should automated these steps so that you do not have to manually update the Version/Build ID - that is true. I was giving a simple example so that the concept would be clear. Here's a challenge - can anyone send me an example java snippet that reads the version id from the Manifest? I will post the response after testing it. So the best way to do this is to automate updating the version id using the information from the version control tool. This way there is no room for manual mistakes - like the typos in my articles lately :-) Thanks everybody!!!!!!!!! |
Imeshev, Slava
said:
 |
... Bob, That's nice. The only problem here is that your WhoAmI would always contain the same version information, without regard to the actual state of the code base. A better approach is to use a version template class and have a release management system provide the information about version and change list numbers that the build was run against. This way your WhoAmI would contain correct information: public final class Version { private static final String RELEASE_DATE = "@release.date@"; private static final String RELEASE_CHANGE = "@release.change@"; private static final String RELEASE_BUILD = "@release.build@"; private static final String RELEASE_PATCH_VERSION = "@release.version@"; } And then the Ant script would do the following: That's how it is done in Parabuild: http://www.viewtier.com/products/parabuild/feature_details.htm#product_version_templates_and_counters |
Bob Aiello
said:
|
... I want to thank my wonderful colleagues who dropped me a note on that really bad typo! Sometimes I put them in just to see if anybody will notice - and you did! Thank you ! Thank you! Thank you! Bob Aiello raiello [at] acm.org http://www.linkedin.com/in/BobAiello |
dcd
said:
|
... is there a missing "NOT" in the message above - rather confusing without it. "So today, I am amazed at how many Java SOA developers write applications that do give you any way to ascertain their version id - let alone the version label or tag used to build them." |
Write comment
You must be logged in to post a comment. Please register if you do not have an account yet.
