Mainframe CI/CD with Rational Team Concert ( Engineering Lifecycle Management)
Rational Team Concert(IBM Engineering Lifecycle Management) is as a software development tool that enables development teams to manage all aspects of their work including iteration planning, process definition, task & defect tracking, source & revision control, build automation/management and reporting.
In this blog will explore SCM(Source Code Management) and Build features of RTC tool from Mainframe prespective and how it helps to achieve Continuous Development, Integration and Build [1] ( Basically how it fits into Mainframe Devops Story).
Topic 1 : RTC as SCM
One of the RTC’s best-kept secret is its SCM feature, RTC supports versioning, build and deployment of zOS/Mainframe artifacts. RTC is counted along with Endevor, Changeman, ISPW, Git etc. as SCM for Mainframe artifacts.
Below are the features of RTC as SCM(More from Mainframe Perspective):
1. Centralized SCM
2. Support for Mainframe artifacts and Mainframe build
3. Integration with Eclipse based IDE tools like IBM IDz
4. Co-existence with other host based SCMs
5. Deployment support for z/OS
6. Security to control access to code based on project, team, or components[2]
6. Full code page support (EBCIDIC <-> ASCII)
7. Streams[5] and workspaces for parallel development with merging
Topic 2 : Continuous Build and Integration
Automated builds have become a cornerstone of agile development and Build definition feature of RTC allows to schedule build real-time to scan Stream(branch) and trigger automated builds. RTC hence plays the role of orchestrator (Like Jenkins, Diff between Jenkins and RTC is that RTC builds are time triggered, Jenkins is code check-in based)
Below image(Pic 1 — Source Jazz.net) shows Build Definition of RTC. Here build is scheduled to run every minute(It can be every second also) of the day(almost real time). Every time a developer checks in change, RTC checks out all the sources, builds everything, runs unit tests, code coverage and reports back with feedback.
Below image(Pic 2 — Source Jazz.net) shows output of RTC build , where you can get details around artifacts built, compilation results, unit tests results along with other useful metrics. RTC allows to embed Unit Test cases as part of build, the ‘Tests’ field in below image shows it ran 46 test cases against new code and they were successful.
Topic 3 : Code Merge
Code Merge/Retrofit is one challenge faced during development of projects in green screen(TN3270 Emulators). If two developers are working on same code, then it would require coordination to merge code manually line by line before staging it to next environment.
To address code merge issue RTC has built-in feature which provides real-time intimation to all developers connected to Stream(Branch) when any change is made to the Stream. Change/Modification to any of the artifacts of the Stream in RTC is referred to as Changeset[3].
Here is an example on how RTC helps to perform real-time Code merge. In this scenario Developer1(Dev1) and Devloper2(Dev2) are connected to Stream ‘RTC-Stream-RH’. When Dev1 performs any change to the code RTC in ‘Pending Change view’ shows there is an outgoing change(Black Arrow-Pic 3) which means Dev1 has some changes which are not delivered to Stream yet. Once Dev1 delivers changes to stream, Dev2 is notified of change by Pop-up , alternatively ‘Pending Change view’ also shows that there is some incoming change(Blue Arrow-Pic 4).
With this feature the code merge/retrofit will be real-time and every developer connected to stream will be in sync with the latest version available in stream.
Topic 4 : Package and Continuous Deployment
On the similar lines of Build Definition , RTC provides feature to package and deploy zOS artifacts with Package and Deployment Definitions. Package definition instructs RTC how to package zOS artifacts(Ex: Which PDS artifacts it should pick, Package to be created at project level or at work-item level) and Deployment definition takes packaged artifacts and deploys them to target environments. The packaging and deployment can also be scheduled to run real-time.
Topic 5 : Devops Pipeline
As seen, with Build, Package and Deployment definitions of RTC, we can create a Devops Pipeline to automatically trigger build at regular intervals and if its per sec its eventually per check-in(With unit test cases, code coverage embedded).
Upon successful build, it triggers package followed by deployment, which will deploy artifacts to target environments. RTC as a single tool performs all these tasks and IDE tools like IBM IDz and Deployment tools like UCD(Urban Code Deploy) seamlessly integrate with RTC, which enable to create end-to-end Devops pipeline.
Will to conclude this topic with quote ‘ Mainframe on DevOps in not myth , its real!’
Happy Learning!
Glossary:
[1] Build: Build in RTC refers to compilation, link-edit process of Mainframe artifacts. Ex : Build of Cobol program will produce load module (Executable).
[2] Component: A component is a collection of related artifacts, such as a set of zOS Artifacts like Cobol Program, JCL, Control Card, DBRM, etc.
[3] Changeset: The changeset is the most basic unit of change in RTC SCM. A change set can include changes to the individual files’ content and changes to a component.
[4] Deliver: Deliver will deliver changesets from private workspace(Developers workspace) to a stream which is a mechanism for sharing those changesets with the team.
[5] Stream: A stream is a repository object that includes one or more components. Streams are like the branches seen in other source control management systems.