Continuous Integration on System z

Transcription

1 Continuous Integration on System z A Proof of Concept at Generali Deutschland Informatik Services GmbH Enterprise Modernization GSE Frankfurt, 14th October 2013 Markus Holzem, GDIS-AS mailto: [email protected]

2 Agenda Why change anything? What is Continuous Integration? The Continuous Integration Process Continuous Integration Tools System z Setup Status Quo and Next Steps 1

3 The goal is a shorter Time-to-Market: Continuous Delivery Why change anything? Release multiple times per day! Continuous Integration Automated Testing Continuous Deployment 2

4 Blue-Green-Deployment expects a full install on a clean runtime system Why change anything? Continuous Delivery Patterns expect full installs instead of patches 3

5 Changing the Code is Taking a Risk Continuous Integration: Theory Integrate Code Base Working Copy Long cycle: Incompatibility to other changes Huge amount of merge effort to integrate with other changes Long delays due to pessimistic locking Short cycle: Test Develop Incompatibilities show up immediately Merging of changes happens very infrequently Build 4

6 The Technical Solution for the problem is Continuous Integration Continuous Integration: Definition Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. 5

7 Continuous Integration comprises a set of practices Continuous Integration: Principles Maintain a Single Source Repository Automate the Build Make Your Build Self-Testing Everyone Commits To the Mainline Every Day Every Commit Should Build the Mainline on an Integration Machine Main Focus of PoC Keep the Build Fast Test in a Clone of the Production Environment Make it Easy for Anyone to Get the Latest Executable Everyone can see what s happening Automate Deployment 6

8 Regular and Incremental Changes need a Safety Net Continuous Integration: Build Dashboard Build of the entire code base of a software component after each commit to the mainline Measuring the quality of the build Unit tests Complexity (e.g. McCabe) Compliance to style guides Static Code Analysis Duplicate Code etc. 7

9 Each commit to the source control repository triggers a build on the Continuous Integration server Continuous Integration: Process 8

10 Tools are available for Java Development Continuous Integration: Tools CI Server Build Tool Source Repository and adaptable for z/os Code Inspection Artefact Repository 9

11 A Continuous Integration Build for System z software is quite complex Continuous Integration: System z Build Compile and link the entire software component Setup test environment create DB2 databases configure IMS or CICS transactions load DB2 test data initialize datasets provide mock-ups Run unit test suite Run code quality checks Report all results to a dashboard system Ł Each development team needs a separate development and test environment. 10

12 It is to expensive to use a Standard System z for Continuous Integration Cost Drivers System z LPAR costs for development Hardware Software System management Automation Backup which are only partially needed and add up to massive costs, when replicated for development teams Managed LPAR usage is often to restrictive Capping to reduce licence costs Overflow of production jobs Authorisation limitations Ł The solution to the problem is the Rational Development and Test Environment for System z 11

13 Most Java world tools can be adapted to RD&T PoC Setup at Generali: Apache Tomcat, JGit Apache Tomcat as Web Container jgit Command Line Interface for Git/Gerrit Repository Access 12

14 Source Repository Access needs Java Implementation (or a persistent ANSI C developer to port the tools) Git Java implementation running in RD&T 9.0 USS git clone works J ISO encoding 13

15 Most Java world tools can be adapted to RD&T PoC Setup at Generali: Hudson Hudson as CI Server 14

16 Most Java world tools without JNI can run on System z; File and System encoding IBM-1047 can sometimes need some work Hudson running in RD&T 9.0 USS YES, it is z/os 15

17 The next steps Running ANT on RD&T 9.0 Create a Hudson Job triggered by a code change in Git/Gerrit Create a build procedure for a COBOL program Run unit tests on the COBOL program 16

18 Anyone set out on the same track? 17