12. Agile and DevOps methodologies provide the backbone of
our new ways of working
PUBLIC
13. Endevor stands for Environment for Developers and Operations
ENDEVORDEVOPS
Wikipedia: “a clipped compound of development and operations”
Source Control : CA Endevor SCM
PUBLIC
15. What is DevOps then?
PUBLIC
• Because its newer DevOps as a term is harder than Agile to define and lots
of people have tried to do so:
See more: https://www.google.com.hk/search?q=what+is+devops
16. What is DevOps? Dev vs Ops
PUBLIC
Dev – Development:
• Developing/Creating/Maintaining the software
So development value and are rewarded for “delivering” early and continuously
Ops – Operations:
• Operating/Running/Mission Controlling the product
Change has the potential to introduce instability and stop system running
• Easiest way to prevent this is to slow down or stop change
• Therefore indirectly rewarded for slowing down or stopping delivery
17. Get to the point – What is DevOps?
PUBLIC
Lets see how those values and rewards differ traditionally:
Align, Break down the silos and make everyone value and be rewarded for both
Group/////// Values Primarily Rewarded For Less Concerned About
Dev Early & Continuous Delivery
of Software
Delivering new value to business Operation and stability of the existing
systems
Ops Keeping existing systems
operating and stable
Operation and Stability of the
existing systems (which are already
providing real value)
Delivering new value to business
18. So what at its heart is DevOps?
PUBLIC
The clue is in the name:
• Dev – Development: Developing/Creating/Maintaining software
• Ops – Operations: Operating/Running/Mission Controlling the product
DevOps is at its core about making these previously two separate things into one
Also three acronyms:
CI / CD / CT – I need (to understand) these to “do DevOps”
20. Continuous Integration Definition
PUBLIC
• Continuous Integration (CI) is a development practice that requires developers
to integrate code into a shared repository several times a day. Each check-in is then
verified by an automated build, allowing teams to detect problems early.
By integrating regularly, you can detect errors quickly, and locate them more easily.
• CA Endevor SCM – the vendor tool we have currently and what it does:
• Allows developers to integrate code into a shared repository,
also allows parallel development
(Separate Environments / Separate Systems)
• Each check-in is verified by an automated build.
If a COBOL program is saved into Endevor SCM an automated generate
(compile) job will be submitted. Majority of element types are generated.
See more: https://www.thoughtworks.com/continuous-integration
21. Continuous Integration
PROD
Long Term Projects Current Rel Release + 1 Release + 2 Release + 3
PREPROD
RQA
RITEST
RSTEST
RUTEST
RITESTA
RSTESTA
RUTESTA
RITESTB
RITEST1
RSTEST1
RUTEST1
RSTESTB
RUTESTB
RITESTC
RSTESTC
RUTESTC
RFIX
Allows developers to integrate code into a shared repository,
Multiple Environments allow parallel development which all link into the trunk / main arm.
22. Continuous Integration
PUBLIC
GENERATE USE THE MAP… OBTAIN THE INFRASTRUCTURE…
APPLY THE OPTIONAL FEATURES
DATABASE BINDS CICS PHASE-IN
LINK EDIT THE OBJECT
Copybook
Copybook
Copybook
Copybook
DCLGEN
DEVELOPER WRITES /
COMPLETES CODE AND
ADDS / UPDATES ELEMENT
INTO CA ENDEVOR SCM
USE QUICKEDIT / ISPF
PROCESS VIA BATCH SCL
OR RDz (GUI VERSION) AND
CARMA INTERFACE
Each check-in is verified by an automated build (Build Orchestration).
If a COBOL program is saved into CA Endevor SCM an automated generate (compile) job will be submitted.
23. Continuous Integration
PUBLIC
If Build Orchestration fails: (due to poor coding / space issue)
Original code output is NOT overwritten.
LL (List Listing) option in CA Endevor SCM allows you to see the issues with the code build. (you do not need to look at job output)
Failed elements do not mean “failed builds”
What else do we do?
Backfill:
Automatically fill in the previous environments
With the correct pieces of code (JCL / Cards)
Over 100 Years of zSeries Design and Capability Build
TestIDs:
Each Environment can have a testing ID specified
Against it allowing separation of testing
Existing CA Endevor SCM Quality Gates
Only successful builds may be moved forwards up the Map into higher environments for Testing and release to Production
Footprint checking between source and load modules ensure LMI (Load Module Integrity)
CI Trace information – CA Endevor SCM output of what has been captured and utilised is directly available to the developer in the Job Output
CI Transparency – BX command against the CA Endevor SCM elements lists the input and output components after a successful build
Build Orchestration, Quality Gates and additional features.
24. Continuous Integration
PUBLIC
• SpinUp z/OS CA Endevor SCM environments
• Advantages:
No space issues (dev. can resize their own libraries)
Parallel Development
Fastest possible on z/OS integration back with trunk code (true CI)
Power of full CA Endevor SCM processor support allowing compilations
(based on the main trunk)
CA Endevor SCM
UNITTEST /
UTEST / RUTEST
Developer SpinsUp own “Environment” based on existing setup
Developer ID
Own Named
Subsytem
Developer ID
Own Named
Files
Developer ID
Own Named CICS
Job (not STC)
Developer ID
Own Named DB2
TableSpace
Do you want / need more environments? (distributed term: Private Workspaces) ?
25. Continuous Integration
PUBLIC
• Integration points, what is the trigger ?
CA Endevor SCM
Generate
Process
TRIGGER
Email Results
to User
Automate
Environment
Move?
CA ENDEVOR
SCM
Code
Changes
Testing
Changes
Integration with testing / code quality tools
27. Continuous Deployment
PUBLIC
See more: https://en.wikipedia.org/wiki/Continuous_delivery
• “Our definition”:
“Continuous Deployment is closely related to Continuous Integration and refers to the
release into production of software that passes the automated tests.”
• Webopedia:
Continuous delivery is sometimes confused with continuous deployment. Continuous
deployment means that every change is automatically deployed to production.
Continuous delivery means that the team ensures every change can be deployed to
production but may choose not to do it, usually due to business reasons. In order to
do continuous deployment one must be doing continuous delivery.
• A straightforward and repeatable deployment process is important for
continuous delivery.
28. How does the CA Endevor SCM Deployment Process Work
PUBLIC
• Each CA Endevor SCM Environment can be attached to a testing infrastructure.
Eg: DB2 System, CICS System, TWS schedules (specific JCL batches)
• MOVEing up the environment map via CA Endevor SCM is a manual task but can be
automated and triggered to the higher environments.
• We currently have the process in place to provide Continuous Delivery from one
(testing) environment to the next. The move and shipment piece for productionising
the code is a manual task which requires planning and backout documentation
following the defined change procedure.
29. Delivery Pipeline
PUBLIC
Element Added/Updated to CA Endevor SCM
Automated Generate UNITTEST
CA Endevor SCM
Environment map
Automated
Deployment
SYSTESTCA Endevor SCM Move
Automated Deployment
INTTEST
QA / ACCTEST
PREPROD
PROD
CA Endevor SCM Multi-Move
UNIT TEST ENVIRONMENT
Production Release & Deployment
Change Management tool following
Release Management process
Elements / Components need to be in PREPROD
Shipped to Destination (eg production mainframe)
And DEPLOYED (automatically at a specific time
Or manually as defined by application team)
SYSTEM TEST ENVIRONMENT
DEPLOY
INTEGRATION TEST ENVIRONMENT
DEPLOY