In part two of this video series, a developer Deb is assigned an enhancement request for an existing COBOL/CICS Application (JKE Banking Application). The application currently uses VSAM files to store its application data. The development team is being requested to change the application to use a DB2 database to store the application data.

In this video Deb will use Rational Developer for z Systems (RDz) and Rational Team Concert (RTC) to:

• check out the application code out of the SCM

• perform some code analysis

• implement a code change

• compile the code change to RD&T

• run a debug session

• perform quality analysis on the changed code (zUnit & Code Coverage)

Background

If you missed part one of this video series, it will help to review DevOps for z using Rational Development and Test Environment for z Systems (RD&T): Video Series – Part 1 and the first video Better DevOps on IBMz with Rational Development and Test Environment for z Systems (RD&T) - Part 1 which will show priming a RD&T environment from an existing mainframe environment using UCD.

Prior to Deb, the developer, being assigned the enhancement request it is assumed that there has been some preliminary work that has been done up to this point. In the DevOps model it is typical for a stake holder to open a story work item up against the development team, which will outline a need for change to an application, and business reasons for this change. Then an analyst who is monitoring the work item queue and familiar with the application will take the work item and perform some initial assessments on the complexity and risk of the changes being requested.

After the assessment from the analyst usually a project manager will take the work item and request the development team lead to schedule the enhancement in the current release. The development team lead then decides when to schedule the work, and to whom to assign the work to, in this case Deb. At this point, this is where the video will start with Deb being assigned the work item to implement the enhancement request.

Quality Analysis

In this video there will be a couple of quality analysis tools being demonstrated that are provided by RDz, zUnit and Code Coverage. In order to help facilitate an automated build process with feedback, these quality analysis tools are scripted to run upon the completion of an RTC build. This way the development team has zUnit and Code Coverage results associated with each build that is produced.

zUnit

What is zUnit? zUnit is automated code driven unit tests that run against z System applications. With the zUnit runtime that is provided by RDz, these zUnit test cases are written in COBOL or PL/I.

For more information on zUnit please visit the RDz knowledge center:
http://www.ibm.com/support/knowledgecenter/SSQ2R2_9.5.1/com.ibm.etools.rdz.zunit.doc/topics/c_zunit_overview.html

Code Coverage

What is Code Coverage? Code Coverage is analysis of the application code to determine what lines of code are executed vs. the total number of lines of executable code in an application, on a particular execution session of the application. Why is this important and what kind of information can be gleaned from this type of analysis?

When code coverage is paired with test executions of an application, the code coverage analysis can give you a couple of data points about the quality of your test cases. It can tell you how much of your code is being reached by the test cases (how many modules are being executed vs. the total number of modules that make up an application). It also tells you how much of the modules that are being reached and what percentage and what paths are being executed in those modules.

So in essence when zUnit and code coverage are paired, it can tell you not only the number of test cases that you have but it can also tell you the quality of your testing. Beyond the numbers that code coverage can tell you, it can also highlight where there might be gaps in the code that aren’t being tested.

For more information on code coverage, please visit the RDz Knowledge Center:
http://www.ibm.com/support/knowledgecenter/SSQ2R2_9.5.1/com.ibm.guide.hostconfig.doc/topics/hb_codecoverage.html

Integrating RDz Quality Analysis with RTC Builds

Integrating the RDz quality analysis tools with RTC builds is not a standard configuration that comes with RDz or RTC. There is some set up work that must be done in order to extend and integrate the two processes.

When creating the RTC Build Definition, which controls the way the application is pre-processed, compiled, linked etc., there is an area in the definition which allows for post-build operations. In this field you can specify an ANT script which will allow for operations to be performed after all of the build operations are complete.



In this ANT script we can call other shell scripts or execute other programs in the USS environment. In this particular case we have an ANT script “qaANT.xml” which performs the following operations in order to call the RDz quality analysis tools and provide those results back to the RTC Build results:



Here the ANT script starts the code coverage daemon on z/OS, copies the built modules from the RTC build into a testing area, and then runs the zUnit test framework that is testing the JKE Banking Application. The zUnit test framework and the JKE Banking Application are configured to connect to the code coverage daemon. After the test execution the ANT script stops the code coverage daemon, and then gathers the zUnit and code coverage results and publishes it to the RTC Build.

When the ANT script runs, it executes with knowledge of the RTC Build Properties and therefore the ANT script can be variablized and then can be used for several different build operations. Here is an example of some of the ANT script that can be run, that demonstrates using properties from the RTC Build:



To learn more about how RTC can use ANT reference:
http://www.ibm.com/support/knowledgecenter/SS2L6K_6.0.2/com.ibm.team.build.doc/topics/r_ant-tasks.html

Video Series

Today’s installment of this video series will show a developer implementing a development change set based on an enhancement request. Please view the video here.

In the upcoming weeks, I will post blogs and videos that describe completion of the scenario:

• Part 3 of this video series will show an integration build with zUnit + Code Coverage, thus showing how a team build or an automated build will be run to pick up new change sets. Once this build is successfully run, a UCD package is created setting up for the next phase, deploying for unit/function test.

• Part 4 of this video series will show deploying a package for unit/function test with UCD using automated zUnit + code coverage analysis.

Additional Items (Not Covered in the Video)

After some reviews on the video, it was suggested that an operation that is probably missing from the demo, but is still important in the development process is a code review of the code changes. This is pretty important, especially in an enterprise development environment, and so I want to describe how that would be done with RTC and RDz.

Code Review

So this step would be done prior to Deb delivering her changes in the video. She would request a peer developer, to review her changes before delivering them to RTC.

In order to do this the developer reviewing Deb’s changes would open the RTC Work Item that Deb was working on and navigate to the Links tab:



In the Links tab, the developer would see all of the references to the change sets associated with this work item. From here the developer would double click on a particular Change Set and the Change Summary view should appear with all of the files that have been changed as part of the Change Set.



Double clicking on one of the changed files will bring the source file up in the Compare editor with all of the changes in the source highlighted, and thus creating an easily navigable view for the developer to review Deb’s changes.