Automated Testing - Group home

This blog/video series is based upon a demo session that I presented “Continuous Integration and Deployment on Rational Development and Test Environment for z Systems” at InterConnect 2016. Slides for this session can be found here.In this session I presented how developers could perform code changes to an existing application, do builds/compiles of that application, run debug sessions, and run automated unit testing with code coverage on their changes while having minimal impacts to mainframe environments.

I am doing a reprise of this session because I have gotten a lot of requests for more details, plus, RD&T 9.5 comes with the UCD z/OS agent to facilitate this scenario. Note that RDz and RTC z/OS agents have always been packaged with RD&T.

In this series, I demonstrate how users can prime an zDT Environment using Rational Team Concert (RTC) and Urban Code Deploy (UCD). Once the system is primed developers can then use Rational Developer for z Systems (RDz) and RTC to make code changes and build those code changes on zDT. Once the developer is satisfied with their code changes they can then use RDz, RTC, and UCD to deploy those changes for formal Unit/Function level testing on zDT.

What is Rational Development and Test Environment for z Systems (RD&T)?

zDT is Linux based software that emulates z Hardware and allows users to run z Software stacks (z/OS, z/VM) on an Intel based platform.

The benefits of this is that it runs the same z Software stack that is running in a mainframe environment, allowing users to develop and test applications on zDT at a functional level and it will behave the same way as on real mainframe.

What it CAN’T do. zDT is an emulated hardware environment, so it does not have the capacity or durability of a real mainframe; thus it is not appropriate for doing things such as performance testing or stress testing. In addition zDT is not licensed for production compiles or production workloads.

Workflows and Impacts to Mainframe Environments

Looking at traditional development workflow vs a development workflow with zDT, we can see where zDT minimizes development impact to mainframe environments. In a traditional workflow typically development processes do not have priority, and are usually superseded by production workloads. Therefore development efforts are usually quite slow, and most of it is idle time waiting on environment resources to become available.



Now if we compare this to a development workflow using zDT, we see that the development efforts have been offloaded from a mainframe environment to a zDT environment. This allows for development to be able to perform much more quickly without having to wait for mainframe resources.



System Topology

So what does the system topology look like when using zDT? For this demo/video series the following topology is used.



When doing development with zDT, it is good practice to configure zDT so it is setup like an existing development/test LPAR. Therefore, for this demo zDT has the same z/OS level and the z/OS subsystems (CICS and DB/2) are configured with the same setup as on the mainframe. Then, to facilitate development scenarios, both the mainframe and zDT are configured with RTC, RDz, and UCD z/OS agents.

In addition there is a developer workstation with an Integrated Development Environment consisting of RTC and RDz. This workbench is configured to be able to communicate with the RTC server, the mainframe, and RD&T. However for most development tasks the developer workstation should be using RD&T and not the mainframe.

Demo Scenario used for Video Series

There is a CICS application on our real mainframe system that is used for calculating and listing mortgages. This application currently uses VSAM to store the application data for the CICS Application. In this scenario we are going to have a request for enhancement to change the application to use a DB2 database instead of VSAM for its application data.



Video Series
Today’s installment of this video series will show priming a RD&T environment from an existing mainframe environment using UCD. This will set up the environment to allow for our development scenario. Please view the video here.

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

• Part 2 of this video series will show a developer implementing a development change set based on an enhancement request. The developer will use RDz + RTC to check out code, implement a change set, compile to RD&T, and run a debug session on the change code.

• 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, an 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.