Using Rational Team Concert on the mainframe to promote dependency builds

Team Concert can handle complex dependency builds on the IBM mainframe. If you have a long deployment tasks that are highly manual, and error prone, using the RTC build agents on z/OS could save you bookoos of time and money. This video from Thom Haynes at IBM's user experience team shows you how:

Setting up Dependency Builds for RTC on z/OS

Promoting Dependency Builds for RTC on z/OS

Jazz based CLM Beta 3 products now are available

For those interested, the Jazz team announced Beta 3 for all three Rational CLM products including:

• Team Concert
• Quality Manager
• Requirements Composer

 While each of these three are worthy in their own spotlight, when put together, the whole is worth more than the sum of its parts. Its interesting to note that the Jazz team REALLY eats their own dog food. They run on a continual beta, meaning they develop the tools using the tools. With RTC running continuous builds, they are always the the latest release, with complete traceability from requirements to source code, to build, to test result.  The image on the left here demonstrates cross relationships between work items owned by different products.

Those who read this blog know I am a big advocate of RTC as it can radically change (for the positive) a development team from being reactive and stifled of innovation to productive, creative, and responsive to the customer or stakeholder needs.

This latest group of betas (which I am downloading as I write this) has even deeper integration with each other. So much so, that its offered as  a single download for all three products. 


For more details check out the latest blog entry at:
http://jazz.net/blog/index.php/2011/03/29/clm-beta-3-now-available/

Agile Sketching with Rational Software Architect

Rational Application Developer's bigger brother is Software Architect. I've been using it for years for all sorts of development and modeling. In v8 of the product, Rational is introducing a new agile sketching feature. This demo shows how the product can help you flesh out general architecture in a non-intimidating, simple format, yet be able to convert those sketches over to a full strength UML model. Take a look:

iframe>

Deploying to WAS or Tomcat using the RTC build engine

The build engine capability of Rational Team Concert is capable of doing anything you want to do with Apache ANT, Maven, or even a shell script via the command line option.  On top of that it adds its own calls to so that you can get instrumentation on the status and history of your builds from the RTC interface. Builds can be automated so you have full continuous integration, which can help improve the overall quality of your project.

Build definitions are associated with an RTC project, and will call either ANT, Maven, CL, JCL, or command line scripts. A full build definition of any web app should also include a deployment target. You can deploy to just about any application server if you know the right calls.

In the case of WebSphere App Server, you need to know  a little about wsadmin scripting. The wsadmin interface is in the <WAS_HOME>\bin directory. It is the interactive scripting interface. This scripting interfaces uses your choice of Jython or JACL languages. Both of which are Java implementation of Python and TCL respectively. If you are writing a new script, start with Jython as it is the more powerful of the two, and JACL has been deprecated (but is still supported on WAS 7).  You can send interactive commands in wsadmin, or you can feed wsadmin with a script file using the -f command switch. From a command line, if you were to call a deployment script to automate the deployment of a Java EE app, your call may look like this:

C:\IBM\WebSphere\AppServer\profiles\AppSrv01\bin\wsadmin.bat -f deploy.py -lang jython -user wasadmin -password waspassword -host localhost -port 8880 -connTYPE SOAP


Now, the various command params are available in the WAS InfoCenters, so I won't cover those in detail.  Suffice it to say, the above is a fairly close approximation to what you may see in a dev or prod environment.

Now, what you need to do is to put that into an ANT call:

<exec executable="${was.home}/bin/wsadmin.bat" failonerror="false" resultproperty="deploystatus">
            <arg value="-lang" />
            <arg value="jython" />
            <arg value="-user" />
            <arg value="${was.userid}" />
            <arg value="-password" />
            <arg value="${was.password}" />
            <arg value="-host" />
            <arg value="${was.host}" />
            <arg value="-port" />
            <arg value="${was.port}" />
            <arg value="-f" />
            <arg value="deploy.py" />
            <arg value="install" />
            <arg value="${path.ear.file}" />
            <arg value="${appname}" />
            <arg value="server1" />
        </exec>

Notice, we are passing in all the key parameters as ANT variables. Also, notice that we are storing the wsadmin command result in a property called 'deploystatus'. We will use that to confirm deployment of our application. This is a nice generic element. Next we want to inspect the property to ensure our deployment was a success. This all assumes that you've done a compile, a unit test, a war/ear, etc on the project before it gets to this target.

<condition property="isNotDeployed">
   <equals arg1="86" arg2="${deploystatus}" />
</condition>
<fail if="isNotDeployed" message="Deployment Failed!!" />

If deployment succesds, and wsadmin exits normally, it will return a code 86 (at least on Linux it does). By checking to make sure we have that as our code, we can confirm that it has succeeded.

The deploy.py script can be as complex as you need it. You can deploy and map your modules to your web servers, distribute across clusters, set custom JVM args and more. But the meat and potatoes of the  script is in two lines of code:

AdminApp.install(earfile, ['-verbose', '-appname', appname, '-server', server])

AdminConfig.save()

That is it! I've highlighted the variables I pass into it, and I've excluded some other options, but if you don't need anything fancy, you could hard code this into your script, or you could feed the parameters from the RTC build definition properties, to the jython script. Do so is a very convenient way of passing in the wsadmin user credentials. This allows you to pass in one set of credentials for a dev build definition, but force the user to manually enter credentials for a production definition. Deploying to Apache Tomcat is fairly similar.

<deploy localwar="${basedir}/${warfile}" url="${tomcat.manager}" username="${tomcat.user}" password="${tomcat.password}" path="${path}">
</deploy>

<import file="${catalina.home}/bin/catalina-tasks.xml" />
<taskdef name="deploy" classname="org.apache.catalina.ant.DeployTask" classpath="${catalina.home}/lib/catalina-ant.jar" > </taskdef>
 

In the case of Tomcat, we don't need a specific jython script, but we do need to include the task def from the catalina-tasks.xml found in the bin directory of Tomcat. 

One last thing to note, for continuous integration, you will need also to remove the applications if they are already installed before you install them, or you can call the appropriate update API's. Otherwise the installs will fail stating the application is already deployed. I would put all that in the list above, but then I don't want to give away all my secrets do I?


In closing, you should now be able to do some simple deployments with your build engines.