RDz for DevOps Webcast Series: Implementing Continuous Integration with RDz

© 2015 IBM Corporation
IBM z Systems
Implementing Continuous Integration with RDz with a customer
case study
Keith Allen, Head of DevOps for Enterprise System z Europe
Luis Carlos Silva, EM Continuous Integration Lead and Product Line Manager
04/28/2015

IBM z Systems
Information is confidential and must not be shared or redistributed without permission
from IBM. Plans are based on best information available and may change in future.
DISCLAIMER
© Copyright IBM Corporation 2015. All rights reserved.
IBM’s statements regarding its plans, directions, and intent are subject to change or
withdrawal without notice at IBM’s sole discretion.
Information regarding potential future products is intended to outline our general product
direction and it should not be relied on in making a purchasing decision.
The information mentioned regarding potential future products is not a commitment,
promise, or legal obligation to deliver any material, code or functionality. Information about
potential future products may not be incorporated into any contract. The development,
release, and timing of any future features or functionality described for our products
remains at our sole discretion.
Performance is based on measurements and projections using standard IBM
benchmarks in a controlled environment. The actual throughput or performance that any
user will experience will vary depending upon many factors, including considerations
such as the amount of multiprogramming in the user’s job stream, the I/O configuration,
the storage configuration, and the workload processed. Therefore, no assurance can be
given that an individual user will achieve results similar to those stated here.

IBM z Systems
ALM Modernization
Pace layer approach and mainframe ALM modernization
DevOps
ITIL COBIT
CMMI
-
+
Governance
+
-
Change
Client Contact
Advice
Assessments
Communications
Clients
Contracts
Products
Sales
Suppliers
Financial
Transactions
Employees
Reporting
Funding
Systems of
Innovation
Systems of
Differentiation
Systems of
Record
Innovation ► Continuous Experimentation ► Fail Fast and Often ► Fix Errors ► MTTR
Core Business ► Optimization ► Stable and Predictable ► Prevent Errors ► MTBF
Mean Time To Repair
Mean Time Between Failures
Mainframe applications tend to be ‘systems of record’ – stability is a core consideration.
Stability and Agility should not be mutually exclusive

IBM z Systems
Common Vision for Development Practices
RATIONAL TEAM
CONCERT
Continuous Build Continuous Release Continuous Test
Fixed Artefact
Versions
Quality Reports
and Documentation
SCRIPT
EXECUTION
RESULTS
PUBLISH
SCRIPT
MAINTENANCE
SCRIPT
CONTROL
First Phase – Adoption of Continuous Integration (with DEV testing)
Defects directly in RTC (DEV)
RQM-RTC Link (TEST)
DEPLOYMENT TO
DEV AND TEST
ENVIRONMENTS
DEV-TEST-UAT

IBM z Systems
Why start with Continuous Integration?
 Instant feedback to developers on quality issues
 Aids unit test automation on every build
 Supports Agile development
 Pre-cursor to Continuous Delivery and DevOps
Improves Quality
Improves Productivity
* if done correctly
Successive practices build on each
other, with each practice adding
greater and greater business value
and having greater scope over the
software development process.
Phase 1 Vision
Future Vision

IBM z Systems
Continuous Integration for COBOL development
Developer IDE
Rational Developer for
System z (RDz)
Task Management
Rational Team Concert
(RTC)
Quality Dashboard
PPM and RTC
Linux z/OS environment
(physical)
Rational Developer and Test
(RD&T)
Linux z/OS environment
(virtual)
VM environment
z/OS mainframe
Source code repository
RTC and current z SCM
Environment mismatch:
High cost resource cost (DBA’s, sysprogs) greater
than lower cost resource saving (App programmer)
Achieve real time delta loads to APM and
Dashboard with RDz code coverage metrics
Retain current z SCM prior to migration as single
source of truth whilst exposing code via RTC.

IBM z Systems
Continuous Integration Process
Mainframe 3rd Part SCM Link
Developer Checks
Out Source
Code/Quick Edit.
1
Make code
change via RDz
editor.
2
Check In / Quick Edit
Save to Endevor
using CARMA.
3
Code Review
RUNCR
Debugging
RUNDB
Code Coverage
RUNCC
Automated Unit Testing
RUNZU
Compile and Link
By default Endevor runs
Compile and Link
(Optional) Developer can
additional select and run
Sub Processors
4
Automated tests
triggered in Endevor
via Sub Processors
provide feedback on
application quality to
developer.
5
Application Quality Feedback
From
Endevor

IBM z Systems
www.ibm.com/software/rational

IBM z Systems
What is Unit Testing?
Unit Testing is a software testing
method by which individual units of
source code, sets of one or more
computer program modules together
with associated control data, usage
procedures, and operating procedures
are tested to determine if they are fit
for use.
An individual unit of software is a
single test-able logic construct or
routine within a call-able program:
 Date validation
 Credit Card number look-up
 Tax computation
 Co-pay calculation
This method of testing is sometimes
called “White Box Testing”.

IBM z Systems
What is xUnit?
Frameworks that assist developers in writing code to perform repeatable, self-
checking unit tests are collectively known as xUnit. xUnit defines a light-weight
architecture for implementing unit testing frameworks
 Defines an architecture for unit testing frameworks that are code-driven
 Prescribes testing the fundamental units of software (functions, methods,
 classes)
 Distinguishes between failures and errors in a unit of software:
• A failure is an anticipated problem (e.g., actual output does not match
expected)
• An error is an unexpected, catastrophic problem (e.g., protection
exception, null pointer)
 Testing is automated: code, not people, determines pass, fail, or error
 JUnit is a popular instance of the xUnit architecture for Java
 Key element of Test-Driven Development (TDD) “red, green, refactor”

IBM z Systems
What is zUnit?
 An xUnit instance for Enterprise COBOL and PL/I on System z.
 Test cases can be written in either COBOL or PL/I.
 Provides generation of COBOL or PL/I test case templates.
 Can run a sequence of test cases, mixing COBOL and PL/I is OK.
 Test cases must be LE-enabled batch applications and built into PDSEs.
 Provides a simple fail-type assertion API for COBOL and PL/I.
 Simple test runner configuration XML specifies which test cases to run.
 Comprehensive test runner results XML provides detailed test results.
 Eclipse viewers/editors for the configuration and results XML formats
The zUnit feature of Rational Developer for System z provides a code-driven unit
testing framework for Enterprise COBOL and PL/I. zUnit provides an automated
solution for executing and verifying Enterprise COBOL and PL/I unit test cases that
are written using the zUnit framework

IBM z Systems
zUnit Architecture

IBM z Systems
zUnit Components and Terminology
The test runner is a z/OS® batch application that runs one or more test cases
based on an input configuration and generates a consolidated report of the
results after all test cases are run. The format of the test runner configuration
and test runner results report is UTF-8 XML. The test runner can be configured
to stop running tests or test cases if assertions or unexpected errors are
detected.
Test cases are Enterprise COBOL or PL/I programs that are structured
according to the expectations of the test runner. Each test case contains at
least one test that is a subprogram (COBOL) or procedure (PL/I). Tests are
expected to be independent of one another, therefore each test fixture is
expected to be created, used, and discarded before the next test is run.
The zUnit test runner exposes a set of APIs for use by Enterprise COBOL or
Enterprise PL/I test cases. The following APIs are provided:
• AZUTCINI: Initialize and register a test case.
• AZUTCADD: Add a subprogram or procedure as a test.
• AZUASTFM: Fail a test with a user-supplied message.
• AZUASTFA: Fail a test without a user-supplied message.
Test Runner
Test Case
Test Runner
API

IBM z Systems
Create a New zUnit Test Case using RDz

IBM z Systems
Define Tests in a zUnit Test Case using RDz

IBM z Systems
zUnit Test Case Structure Overview
zUnit Test Case Module
USER.ZUNIT.LOAD(TESTCASE)
TESTCASE(…)
ADDTESTS(…)
SETUP(…)
TEARDOWN(…)
TEST001(…)
. . . . . .
TESTnnn(…)
zUnit Test Runner APIs
RDZ.SFEKSAMP(AZUTSTRX)
AZUTCINI(...)
AZUTCADD(...)
AZUASTFA(...)
AZUASTFM(...)
Invoking the assertion APIs, AZUASTFA or
AZUASTFM, in the SETUP, TEARDOWN or
active TEST entry will fail the current test

IBM z Systems
zUnit Test Case Structure Walkthrough – Initialization
USER.ZUNIT.LOAD(UNIT0001)
UNIT0001(…)
ADDTESTS(…)
SETUP(…)
TEARDOWN(…)
TEST001(…)
. . . . . .
TESTnnn(…)

IBM z Systems
zUnit Test Case Structure Walkthrough – ADDTESTS
UNIT0001(…)
ADDTESTS(…)
SETUP(…)
TEARDOWN(…)
TEST001(…)
. . . . . .
TESTnnn(…)

IBM z Systems
zUnit Test Case Structure Walkthrough – SETUP
UNIT0001(…)
ADDTESTS(…)
SETUP(…)
TEARDOWN(…)
TEST001(…)
. . . . . .
TESTnnn(…)

IBM z Systems
zUnit Test Case Structure Walkthrough – TEARDOWN
UNIT0001(…)
ADDTESTS(…)
SETUP(…)
TEARDOWN(…)
TEST001(…)
. . . . . .
TESTnnn(…)

IBM z Systems
zUnit Test Case Structure Walkthrough – TEST
UNIT0001(…)
ADDTESTS(…)
SETUP(…)
TEARDOWN(…)
TEST001(…)
. . . . . .
TESTnnn(…)

IBM z Systems
 Create and submit JCL to run the AZUZUNIT JCL procedure
• Example: MVS data set members for input and output
• Example: z/OS UNIX files for input and output
Running a Test Case from JCL

IBM z Systems
zUnit Test Runner Configuration & Results Viewers/Editors

IBM z Systems
Web UI consuming
services running on
z/OS is a typical
solution to modernize
mainframe application
GUI
Regression and
Performance Testing
Interactive and
Integration Testing
Automated Unit Testing
Test Driven Development
Rational Functional Tester
Rational Performance
Tester and IBM Application
Performance Analyzer
zUnit
RDz Integrated Debugger
and IBM Debug Tool
zUnit/Unit Testing is Not a “Silver Bullet”
IBM recognizes this - and provides multiple testing solutions, each optimized for
different problem areas within the software testing space

IBM z Systems
Continuous Integration: Time Versus Maintainability
 You most likely already have continuous integration capabilities in the
distributed languages.
 Pressures to deliver in an Agile manner against perceived slower pace in
mainframe development lead to screen driven development.
 Tactical code written within the sprint to meet delivery dates whilst
minimizing impact on the system of record.
 Screen based design can lead to earlier delivery.
 True end to end architecture, design and development leads to more
easily maintained services.
 By providing continuous integration capabilities to mainframe developers
we maximize the potential for true end to end delivery.
 Coupled with a definition of common API’s for global systems of record
we create the possibility of moving toward our future state aspirations.

IBM z Systems
Code Quality: Moving Quality to the left
The adoption of automated unit testing introduces fundamental new
opportunities:
 Enables a move to test driven development on the mainframe
 Developers build tests with expected results directly from the
requirements. zUnit supports this, the tests are mainframe artefacts
 Run the tests to validate they fail – (if they pass your code already
supports the business requirements!)
 Build code to fulfil the tests
 Use the quality dashboard to validate % successful tests over time -
progress reports are % of function delivered
 At the end of the project the tests and known results are an asset stored
in the SCM. Future regression tests are stored with the code
 The quality dashboard stores unit test line and branch coverage, and you
can click to individual lines
 All this capability is automated as part of deliverable

IBM z Systems
Resources of interest
 White-box testing
http://en.wikipedia.org/wiki/White-box_testing
 xUnit
http://en.wikipedia.org/wiki/XUnit
 Test-driven Development
http://en.wikipedia.org/wiki/Test-driven_development
 Unit Testing your Applications with zUnit
https://www.youtube.com/watch?v=g1tCohSp6nE
 z/OS Automated Unit Testing Framework (zUnit) Enterprise COBOL
test data sample
http://www.ibm.com/support/knowledgecenter/SSQ2R2_9.1.0/com.ibm
.etools.rdz.zunit.doc/topics/s_zunit_cobol_testdata_main.html

IBM z Systems
RDz Lunch and Learn Webcast Series
Ongoing throughout 2015 – here are just a few
DevOps topics explored with Venkat Balabhadrapatruni, IBM STSM Enterprise Modernization, and
other technical experts.
Date Topic Presenters Focus
April 23 Lunch and Learn: RDz for COBOL
Programmers – Tips and Techniques
Venkat
Balaphadrapatruni
RDz for COBOL application
development and maintenance
April 28 Webcast: Implementing Continuous Integration
with RDz with a customer case study
Keith Allen
Luis Carlos Silva
RDz, zUnit testing
May 7 Boost your Problem Analysis Capabilities with
RDz and PD Tools
Russell Courtney and
Bill Alexander
RDz and PD Tools
June tbd* Using RDz and RD&T to boost productivity and
save MIPS
Chris Trobridge, Alisa
Morse
RDz and RD&T
June tbd Automating Deployment with RDz, RTC and
UrbanCode
Chris Trobridge, Sean
Babineau
RDz, RTC UrbanCode
July tbd Using Optim with RDz and RD&T Joseph Taffe-Atkins,
Alan Johns
RDz, RD&T, Optim
July tbd Lunch and Learn: RDz – the right tools for an
agile environment
Rick Slade RDz, RTC, RAA
* Still confirming2

IBM z Systems

RDz for DevOps Webcast Series: Implementing Continuous Integration with RDz

Recommended

More Related Content

What's hot (20)

Viewers also liked (17)

Similar to RDz for DevOps Webcast Series: Implementing Continuous Integration with RDz (20)

Recently uploaded (20)

RDz for DevOps Webcast Series: Implementing Continuous Integration with RDz