Historically SCM (Software Change Management) or ALM (Application Life Cycle Management) was driven by developers.
The first step was about library management or managing source code (program, copybooks, load modules,..) to finally standardizing and bringing compile procedures under control, together with deployments to test and production environments.
Next, especially in the distributed environments, we spoke about Agile Development, whereby open source versioning tools like CVS, Subversion and GIT play a major role. This together with issue tracking systems like Atlassian JIRA and Build tools like Hudson and Jenkins.
DevOps for Mainframe
Today we call this DevOps where the DEV part (versioning, build) is complemented by “agile” deployments to Test and Production environments. That is the OPS part.
For the OPS part, there has even been defined a new category: ARA or Application Release Automation.
There is no reason why mainframe DevOps or ARA shouldn’t work just like it works in the distributed world.
Challenge however is to manage and distributed, mobile and mainframe together in a consistent way. Consistency means a common process, skilled people and right tooling.
However you do this, it is a question of having the right business case, related functional requirements and technical implementation.
There can be good reasons to just handle the mainframe with TSO/ISPF as IDE and all DevOps tooling on the mainframe.
Just like you can have good reasons to move to an Eclipse based IDE and to store your code in Subversion or alike. What moves the DEV to the distributed world. This can include testing or some local testing to have finally deploy the code to z/OS.
As you can see there are different options here.
The main consequence of having a “mixed” DevOps environment is that you have to make sure you have the right skill set: how do you bridge distributed environments to the mainframe?
A mainframe person will talk about PDS’s and JCL and load modules, where the distributed people will talk about file directories, version control repositories on Windows and Linux, scripting and languages like ANT, Maven and Gradle.
Bottomline is that you will need to “generate” or have JCL coming out of these ANT, Maven or Gradle scripts or in any other way.
If you have people that master both skill sets (distributed tools) and mainframe tools, you’ll have it. But practice shows that this is not always evident!
Continue reading in our next post: Business case (Mainframes and DevOps)
Have a great weekend,
The BlueBridge team