Chapter 5: Source Control For Agile Software Delivery I (Modern Software Delivery Support)

Chapter 5: Source Control For Agile Software Delivery I (Modern Software Delivery Support)

The Modern Mainframe ·
Send Us Feedback

Listen on Itunes

Listen to Stitcher

Matt: Hello, I’m Matt DeLaere. Thank for joining us for the latest installment in our series, Building a Better Software Delivery Platform, where we discuss how you can build a world-class delivery system by leveraging DevOps and Agile methodologies. We have a new podcast every Monday, followed by Office Hour with Rick Slade, a live online Q&A session, each Friday. And we have that very same Rick Slade with us now. Hi, Rick, how are you?

Rick: I’m good, Matt, I hope you are, man.

Matt: I am, thanks. So, joining us today is Compuware ISPW Product Manager, Mark Schettenhelm. If you read the Compuware blog, and I highly recommend that you do—there’s a lot of good stuff on there—you may recognize Mark’s name. He can take virtually any subject from Fonzie on skis, to Baby Yoda, to Charlotte’s Web and relate it to DevOps and the mainframe. He has a wealth of information and experience, and a lot of passion. So, it’s a good to have you, thanks for joining us, Mark.

Mark: Thanks, Matt, I’m looking forward to our conversation today.

Matt: Great, so am I, so let’s get started. Rick, we’ve been at this a few weeks now, and we’re moving from a concentration on management of the SDS to drill down into more specific components of SDS architecture. Today we’re talking about software configuration management, specifically in support of Agile software delivery. Over the past several weeks, you’ve mentioned the SCM in a number of conversations. Can you give us a quick overview of the SCM? And for a novice, like me, I notice that SCM is sometimes used to stand for “source control management” and sometimes for “software configuration management.” So, is there a differentiation there? What’s the story?

Rick: It’s a great question, Matt. To be honest, I think it actually resulted… back in the old days, back when I was writing code in the late ’70s and early ’80s there were very primitive SCMs, and they were referred to as “source control management,” because that’s all they did. There were no abilities back then to support the build or the compile/link-edit process as well as the deploy process, along with all the other things that a modern SCM provides today.

And so, it was called source control management for a long time, “software configuration management” popped up as a term to describe essentially the same thing, but with more capabilities. And so, configuration management—and Mark can correct me on is if I’m wrong—is more about the ability to configure activities for build, activities for deploy, to automate those, so that everyone’s leveraging, using the same capability, same functionality for those specific processes that are a part of managing source.

So, I think that’s where some of the confusion comes. If you look SCM, I see it as source control, I see it as software configuration, I see it as software control and configuration management. So, I think it typically all means the same thing. It’s about tracking change within your application set. And so, that’s what we want to talk to Mark about today.

Just one word of introduction with regard to Mark. Mark has been here since I’ve been here, and he’s a wonderful communicator, easy to understand, and is able to define or communicate complex topics in a way that even I can understand. So, it’s been a pleasure to work with him. So, with that, Mark, is there anything else you want to say with regard to your role and what you do?

Mark: Yeah, I was here when you got here because I’ve been here coming up on 32 years with Compuware. Before that, I was a developer at a few different sites. In those years, I’ve worked with many of the different Compuware products, so that does give me a nice, broad spectrum of the development lifecycle, which helps me in my current role of product owner for ISPW.


Why the SCM Is So Critical

Rick: You do a lot of different things for our company, and we all appreciate it. Let me just start with the first question, and it’s about why software configuration management is so critical to modern software delivery.

Mark: That’s an excellent start. Really, SCM is the core of everything a developer does, so it manages the code they work on and it really… I think a lot of people think that, well, it prevents chaos. As I mentioned, I worked at some places before Compuware, and we didn’t have these tools. And it was always this, “What version do I have?” And we occasionally make mistakes, and it was hard. So, people think of it, okay, it prevents that chaos, but it can really be a lot more than that. We look at it as what we can do to go beyond that to eliminate friction, so the developer can focus on producing good code to solve user problems.

Rick: Mark, let me interrupt you, there. What do you mean by a friction?

Mark: Well, some of the friction is things where, with Agile, we’re now having two people or more working on the code at the same time. Because you’ve got a two-week sprint,  you’ve got to work on it and I have to make sure that I can pull off and work on mine in one leg and the other person can work on there. And to manage that process of having multiple people working and know where the other versions are, and then be able to easily handle that and keep everything still within the same source code management. I mean, that’s one example.

The other is to do things that could be manual tests like code review or testing, to automate those and hook that right into the system.

Rick: It is like eliminating anything that slows you down, or minimizing those things that slow you down.

Mark: Right! To eliminate those things so you can focus on the important things of coming up with new ideas to solve.

Mainframe SCM vs. Non-Mainframe

Rick: Are there really any differences for software configuration management on the mainframe versus non-mainframe platforms?

Mark: That’s an interesting question. First off, there are going to be platform differences, of course, in how programs are compiled—testing and deployment, certainly, because of the different environment. So, there are platform differences in those behind-the-scene things. Otherwise you always have to check out, you have to edit, you have to build—those things are always going to be the same in the way they work in an Agile environment, so that people can have their own legs that they’re working on. Those things will be the same, but I think you need a mainframe-based SCM to handle those mainframe-specific platform things and keep them away from the developer, so they don’t have to think of compiling. All they know is they do a build and it’s done.

Rick: Yeah, that’s one of the things that I talk to my clients about, and I think one of the real benefits of automation is if we can build an ecosystem for the developer to where they can work on business problems, writing code, quite honestly—and this may sound crazy—regardless of target platform, then our productivity numbers go through the roof and then we’re able to move people around from project to project a little more easily.

Now again, easier said than done, but the things that you’re talking about, and with regard to configuration and automating a lot of that build activity and subsequent deploy activity is critical. And the more that we can remove those skill requirements from the developers so that they can focus on what’s important to the organization, the more code that they can produce and I think the higher quality the code will be.

Mark: Exactly.


APIs & Webhooks

Rick: Can you talk a little bit about ISPW and how it inter-operates with a modern continuous integration/continuous delivery environment?

Mark: Sure, yeah. It is a mainframe-based tool, as I said, which is necessary because of all the things it has to do in the mainframe, which are unique—the compiles and the deploys are different. But the mainframe is not its own separate silo, it has to go in and work with others, and the way you do that is putting REST APIs in. For the past five years, we’ve been adding REST APIs. I think we’ve probably got at least 75 of them, maybe more. Every quarter, we add to them. It’s… I can’t count them all.

And we automate all the functions that you can do in ISPW. And so, that way we can partner with code quality checks or those who offer coordinated release management deploy. By putting in the API, anybody can go and hook into that and use it. And one of the things that always say is, “The best interface is no interface.” And if it’s something where, “Oh, I have to go in and do a right click to do it,” it might be better just to do that by API. And so, that’s why we have all our processes that way.

Rick: Yeah, I think that’s absolutely critical. And what that gives—when I talk to clients about building their pipes—those APIs give us the ability to provide mainframe services to our customers’ developers. And that’s so important from an automation standpoint because if I want to use Jenkins, or GitLab or Bamboo, from an orchestration standpoint, the ability to leverage these services—and we’ve made it easy to initiate through the APIs—that we can essentially automate a lot of the work and activity that’s occurring in that cycle in that complete cycle. And the more we can automate, the more productive, and I think the higher quality output that developers can produce. I think that’s incredibly important. I was looking earlier at the number of… there’s over 30 different operational APIs, just for ISPW. And so, I think that’s amazing.

Mark: Well, we have… it’s like 75, but it’s the APIs and it’s great because when I go out and talk to our users, and they talk about pipelines, “Well, we want to do this. I want to do an approval, I want to do a build, or generate.” I’m like, yeah, we can do it, here it is.

It’s also the webhooks. So, we have what we call a generic webhook notification, so that if someone does an ISPW activity, and whether they do it on the 3270, they do it in Topaz, or through an API… let’s say I do a compile—so we call that a generate, but it could also be a build—they do that. You can set it up so that you have a webhook notification. Well, that can go off in Jenkins and kick off the process. So, we have these notifications for many of the core features that people do with the product—that can help with the automation. So, it hits that, that goes the Jenkins, they can go in and kick off some APIs, they can kick off other things.

So, you can have a pipeline that does something if, “Okay, I want to do a compile, but maybe the first thing is, let’s do a code quality check. Oh okay, that looks good. Alright, do the compile.” Now, when I do the compile, the next step is, let’s run an automated test with Total Test and if that looks good, maybe then I’ll do a promotion or a deploy.

Rick: The SCM is just so central to essentially almost all the activity within that software delivery lifecycle, I think is why it’s so important with regard to modern software delivery.

So, Mark, we talked about the importance of the SCM. There’s a lot of organizations now are looking at Git. Do we integrate… is ISPW… can it be integrated with Git?

Mark: Yeah, and it’s through that same process of the APIs. Like I said, we’ve been working for… it’s been maybe more than five years now, and we’ve had customers working with Git for that timeframe. So, that’s part of it. When you open up your product through the webhooks and the APIs, many things are possible. One of those is Git, so that you could start with your code and Git and use all the different tools over there for code review, and the quality checks, everything. And then it will automatically be brought into ISPW, and there you get that important mainframe compile and all those things you need to do in the mainframe can be done through ISPW and automated, and brought all the way up through deploy. So, those those two can work together.

Rick: That’s pretty powerful. Now, there will be religious arguments, quite honestly, where the source code needs to be stored. There will be those that say that for the mainframe, it needs to be stored on the mainframe, and others will think it needs to all be in one place, and Git’s being used on the distributed side, so they want to use it there. It’s good to know that with ISPW, if Git is decided as a place to manage your source, then you’re still… We can integrate, we can leverage that capability with ISPW and still use the ISPW build and deploy capabilities for support of mainframe-targeted code.

Mark: Right, right, that’s all part of being open.

Rick: Yeah, yeah, exactly. And I think that’s important, being able to give customers that opportunity.

Alright, well Mark, I appreciate it. Anything else you want to say to our audience before we let it go?

Mark: The only thing I can think of is that the source control management is really key to everything that your developers do, and you really have to look at that and not just accept that, “Well, I’ve had this one forever,” or, “It’s already ingrained in that,” but really look to the future and is it the SCM that will support where you need to be in this environment? Because it is so important.

Rick: Yeah, I agree, and especially for those organizations that are trying to leverage Agile. There are certain capabilities that are a must in an SCM, and if Agile is the method by which you are managing this work… If you’re segmenting work into smaller units, you’re going to have opportunities where parallel development activities are occurring, and if your SCM can’t support that, then that’s an issue and that’s a problem—that’s going to prevent you from leveraging some of the benefits of Agile.

Mark: It’s all about eliminating friction.

Rick: That’s exactly right, that’s exactly right.

Matt: Where in the kind of hierarchy, when you’re rebuilding your software delivery system—and we’ve talked before about a modern IDE and where things, kind of starting points—I assume a new SCM would be, or modern SCM would be closer to the beginning of what you want to implement?

Rick: Yeah, I’ll take that. Mark, I’d be interested in your thoughts too. For me, I’ve helped organizations for 15 years, now. The starting points are going to be different with regard to implementing or evolving your software delivery system. But in a large part of the clients that I’ve worked with over the years, building or creating that initial IDE, modernizing that IDE, building what I call a converged IDE for developers, regardless of target platform—I think that’s a starting point. But, key to that is having access to your source code. And so, I like to manage, as we’ve talked about in prior episodes, I like to manage the implementation using Agile techniques, and defining work in a set of sprints to be accomplished over a period of time. To do what’s necessary to evolve and to build out, provision your software delivery system. Getting that IDE integrated with your SEM early is critical.

I have worked with clients where they have tried to continue to use legacy SCMs, and it always creates problems. Either problems with regard to supporting parallel application development activity or problems associated with not being able to leverage the SCM with regard to automated activities, like builds and testing and deploys, and it just creates problems. Typically, with older IDEs you may have to extract out of your SCM, move that into a PDS, and do your work. All of those, anything that slows that develop process down is the friction that Mark was talking about. And so, trying to minimize that is incredibly important to an efficient, highly-functioning software delivery environment. And with the SCM being so critical, getting it in early, having it as one of those initial activities with regard to the evolution process, I think it is very, very important.

Matt: Anything to add, Mark?

Mark: No, you know, I think Rick, you covered it. Well, I kept thinking, “What about this?” And no, you’ve got it. And so, nothing to add.

Rick: It’s old age, Mark, being around for a long time.

Mark: Yeah, maybe.

Matt: Thank you, and thanks, Mark, for joining us, that was a great conversation. And thank you to everyone listening. If you have any questions, or would like to learn more on any part of implementing a modern software delivery platform, please join us this Friday at 11 AM, Eastern Daylight Time for Office Hour with Rick Slade. Rick will answer your questions live. You can set a reminder for yourself at and while you’re there, you can listen to all the episodes in our series and watch past Office Hours with Rick Slade.

So, Rick, why don’t you take us out?

Rick: Thank you, Matt, and Mark thank you again, man. You are a wealth of information. I appreciate very much you coming and joining us today and I look forward to having you on again. But thank you for your insights with regard to the SCM and its importance in supporting a modern software delivery environment.

Folks, I hope you’ll join us Friday for the livestream Q&A. If you’ve got questions about anything that we talked about, or regarding the incorporation of the SCM into a modern software delivery environment, I hope you’ll join us on Friday and there will be opportunity to ask these questions. Hopefully, we’ll be able to answer them.

But again, thank you for joining us today, we appreciate this. I know it takes time. Hopefully, it’s been useful and beneficial and there’s been some learning that has happened. But again, thank you all. With that, we’ll close out this podcast and we’ll look forward to the next one. You guys take care, have a good week and good coding, everybody.