Continuous Delivery Foundation cdCon 2021, 6 Jul 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Lightning Talk: Unlocking the Hidden Potential of Mainframe with... Mark Schettenhelm & Manoj Singh

Description

Sponsored Lightning Talk: Unlocking the Hidden Potential of Mainframe with DevOps: Automating the CI/CD Pipeline - Mark Schettenhelm & Manoj Singh, BMC Compuware

The mainframe is often overlooked when setting up pipelines. This misses a great opportunity to improve delivery speed and quality by aligning with DevOps. We will show how to benefit from pipelines leveraging open source tools.

For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/

A

Welcome this session is on locking the hidden potential of mainframe with devops automating, the ci cd pipeline. The mainframe is often overlooked when setting up pipelines. This misses a great opportunity to improve delivery, speed and quality. By aligning with devops. We will show you how to benefit from pipelines, leveraging open source tools, I'm mark shuttnell, a senior product manager at bmc and I'll be joined by mino xing devops software consultant bmc we'll be doing a live demo.

A

What we see is that the mainframe has the data and business logic that can be leveraged, but getting to it can be a challenge and it's because there's different cycles, different speeds of working, and so it's difficult for those who work on the front end to get the data and information from the back end. The mainframe.

A

What we found- and this is from our own experiences and working with a lot of different sites- is by aligning practices by adopting devops. You can tap the same potential.

A

So don't listen to those who say it can't be done on the mainframe you'll hear that, but it can be the tools that you work with can be used with the mainframe, and you can set up these pipelines and get the advantages. So minoge will show you how to do it briefly in our time limit. So let me turn it over to minoge.

B

Hi welcome to this demonstration of using devops, toolchain or leveraging devops tool chain in scicd pipeline uh to do mainframe development, so basically mainstream mainstreaming the mainframe.

B

um So I uh this use case is I'm a developer, a mainframe developer, who has been assigned to work on a feature in a sprint and I'm using computer tools or vm's computer bmc tools, as well as third-party open source devops tools to automate my development process.

B

So I'm look, I'm working in topaz workbench and um actually I will not be working in topaz workbench, but I would just want to show you the life cycle of my application, which is defined in ispw.

B

So it has a life cycle which has multiple parallel development paths, leading up to prod um I'm going to be using the dev1 path leading to qa1 eventually to the prod, because I belong to this team. So, having said that, let me switch over to github. My source is in github and it has a branch for me for each feature. The the the feature I'm working on is the feature one mks one uh feature branch which I have already cloned into my visual studio code. So, actually I'll be using visual studio code.

B

This is just a demonstration to show all the different tools that can be leveraged in in this process, so I'm going to be using visual studio code as my primary development ide and I've already cloned my repo here and I've also switched over to use the I'll be switching over to use my branch, which is feature 1, mks, one branch and as soon as it switches to that branch, then I'll go to my explorer and it will open my repository locally.

B

Okay, I'm ready to make my development. So I know that the feature I have to change involves changing a cobalt program which I have identified as t prog, one so I'll double click on it and in visual studio.

B

It automatically highlights that this is a cobalt program and gives me syntax help for cobalt by the color coding and and highlighting like that. So for the sake of this demo, I'm going to be making a very simple change to this I'll, just change the date to um this date, and then I will just save my change. Let's assume, that's the only change required for my for developing the feature, so I will save it as soon as I save it.

B

Github recognize or the local git um extension here within visual code or identifies that there has been a change and it shows me the differences what I changed, but yep that looks right. That's what I changed now, I'm ready to stage them, so I will stage them by pressing this plus icon and then I'm ready to commit, I'm going to say, made or rather updated date to today, or rather just say, updated date.

B

That's it I make the commit. I commit it and once I commit it, I can push my change which will push it to github server. So as soon as this, it's pushing I'll switch back to github now, and if I refresh my browser on that branch, I will see that a push was made and with with the uh um so, the push has already been made to the github server. And if I go here, it says updated date and the program I changed was dprog1 and there it is.

B

If I open this, it should have the date may 28th, so the push has been made. But what has also happened is that there you go. I have a jenkins job created a multi-branch pipeline job, which is already uh looking for changes to my repository, and it automatically detected that I made a change and it it recognized the change and it kicked off a jenkins pipeline, a ci cd pipeline, which I pre created, which will check out the code from github to jenkins.

B

Then it uses the git to ispw synchronization to actually synchronize the code between git and spw and task loaded into a level defined for for my next level of uh um after development and hold level. Then it also is going to build it at that level. Just to make sure that everything all my binaries are are built properly.

B

Then it's going to deploy it to testing using ispw, deploy rest apis. It can run the topaz for total test tests defined for that program or programs.

B

It's going to retrieve the code coverage from running the tests using expedited code coverage, jenkins, plugins and also it can use it feeds all that information to sonar cube for analysis of um of the quality analysis, and I have a if I have established a quality gate in there.

B

It's going to check against the gate if it passes it does the next thing I can add more stages to this pipeline, as you can imagine, I can add more stages so that it can be again deployed on some other using some other third-party tool like digital ai release, etc. So just goes to show everything you can do in distributed. Development can be leveraged for mainframe development, I'm just going to change the view to blue ocean because some people are more familiar with that.

B

So the same thing as you can see, it ran all the stages and let's focus on the get to ispw synchronization step for a second.

B

What it did is it actually download after downloading that change, I made that one cobalt program it automatically synchronized my program with ispw by automatically creating an assignment container and because I told it to load it at qa1 level of my lifecycle in ispw.

B

It did that automatically and then, as a next step, was to build it so just to make sure it's successfully built, which means it makes sure that the changes I applied I made in visual studio code when they got loaded into the next higher level. Everything was hunky-dory. Everything worked fine, so let's go back a final step to topaz workbench and remember when I started there was no assignment containers.

B

If I refresh now, there should be an assignment container created automatically by the jenkins pipeline, and it should have already the task sitting in there, the one I changed already loaded in a level qa1, because I told it to load it to that level and also generated successfully.

B

So this uh demonstrates how powerful it is we can so just to recap, I used visual studio code to clone the repository changed. The branch to my future branch made a change to the program which I'm working on and then I staged it. I committed it pushed it to github and github pushed it to github and the gita, and there was also a jenkins job which is pre-configured to which was uh which is triggered on commit and that got triggered and it ran checked out the code. Synchronized.

B

The changes between git and ispw did a build or generate compile the code deployed it to the testing. Environments, ran the tests on the testing environments, retrieved, the code coverage metrics and all of them got fed into cube for analysis. So that's pretty powerful. That concludes our demo.