Business growth depends on a company’s ability to innovate in line with changing customer needs and market realities. Innovation requires fast and reliable software delivery. And great software is a result of integrating development with IT operations and functions in a manner that enables better communication and co-operation, resulting in greater speed and enhanced quality.

What is a DevOps platform and how are they used?

The term “DevOps” refers to the coming together of developers and operations personnel in order to achieve automation, continuous integration, and more frequent software deployment. Successful DevOps practitioners combine advanced skills in automation technology with the ability to broadly collaborate across an enterprise in order to facilitate software deployment at optimum levels.

A DevOps platform is essentially an automation tool for any of number of functions ranging from provisioning, source-code management, or monitoring to deployment. It’s no surprise that some of the most in-demand DevOps skills today are in the automation and configuration management areas. Popular DevOps tools include Ansible, Jenkins, Chef, Vagrant, Puppet, and KornShell, all of which are open-source.

Let’s take a quick look at each tool and some of their advantages.

Ansible

Ansible is an easy-to-operate automation engine that is used for configuration management, task execution, continuous integration and deployment. A gentle learning curve and relatively simple manageability make Ansible a popular open-source platform.  Another significant advantage is that Ansible doesn’t require third-party software to configure remote servers. It can be run using an SSH connection or APIs.

Ansible also makes writing and maintaining automation code simple because its “playbooks” are scripted in easily accessible YAML code. Suitable for multi-tier implementation, Ansible enables a definition of infrastructure design, including interrelation of servers — thus doing away with the need to script each path individually.

The key advantage of using Ansible is that its simplicity makes it suitable for both small businesses and complex multi-vendor enterprise environments. Ansible is used by government departments as well as numerous enterprises in different verticals. Red Hat acquired Ansible in October of 2015.

Jenkins

Jenkins is a continuous-integration (CI) and continuous-delivery (CD) tool used primarily by developers to concurrently detect and address bugs. Jenkins enables continuous merging of source code from any number of individual developers into the mainline, simultaneous testing, and continuous delivery of production-ready code.

With more than 1,000 available plug-ins, Jenkins is a plug-in friendly platform that enables customers to integrate with most tools. A server-based automation system, it supports Software Configuration Management (SCM) software and is suitable for shell scripts, sbt projects and Windows batch commands. Developers have the ability to use a range of tools for different functions, leaving it to Jenkins to manage the entire workflow from source code to software delivery.

Widely in use across the world, Jenkins is considered one of the top open-source CI and CD automation engines and is widely used around the world. Multinationals that use Jenkins include Verizon, Cisco and General Electric.

Chef

A configuration management tool, Chef is suitable for the operations end of DevOps. Powerful server configuration and maintenance capabilities have made Chef popular with system administrators. It’s compatible with many platforms, including Azure and EC2.

This tool automates the configuration, deployment and management of physical and virtual servers on premise as well as in the cloud by using scripts called “recipes” that are compiled in “cookbooks.” Though ‘recipes are written in Ruby, Chef uses a domain-specific language that everyone can read and write.

In Chef, the server configuration is described in a recipe, which enables testing and does away with the need to make manual changes. Its Analytics feature enables real-time visibility, making administrators aware of a glitch as soon as it occurs.

Being scalable, Chef is suitable for small and large organizations. Some of the major companies that use Chef include Facebook, Indiegogo and Disney.

Vagrant

Vagrant is an open-source automation tool that enables developers to manage virtual machines (VM), with an accessible command-line approach. All it takes are a few commands to build an entire DevOps environment. Launched in 2010, it has been adopted by thousands of businesses across the world. Vagrant is written in Ruby.

Vagrant simplifies and speeds up the virtualization process enabling developers to create virtual development environments in minutes, using a simple, declarative script. It also makes it easy to use virtual machine solutions like VirtualBox from Oracle. There’s no need to configure each machine separately; Vagrant sets up a VM based on the preconfigured base box.

It helps to enhance both development and operations, thereby streamlining the entire workflow. And, once the project is complete, an environment can be demolished in minutes if required. Enterprises using Vagrant include Disqus, Expedia, Yammer and BBC.

Puppet

Puppet is a versatile configuration management and software deployment platform that enables developers to define the state and function of their infrastructure and applications using a common accessible script. With Puppet, you can automatically provision, configure and manage servers, networks and most IP-connected devices across your organization, achieving standard automation at scale. Simultaneous visibility and reporting help to enhance decision-making and ensure security and compliance.

Automation of the entire infrastructure enables organizations to boost speed and consistency of deployment and achieve auditability. Your changes can be pushed through Quality Analysis and made production-ready in minutes if needed. Puppet also enables developers and systems managers to share, test and orchestrate changes across the databank.

KornShell

KornShell, developed over 30 years ago, is a UNIX shell based on the Bourne shell, but with some key differences. It is widely used on legacy systems. This interactive command language was developed at AT&T Bell Laboratories by David Korn. It enables users to gain access to UNIX and some other systems.

Bourne, Korn and C are the three commonly used shells in the UNIX environment. KornShell or ksh combines useful functions of Bourne and C and has some unique features as well. Used by both programmers and non-programmers, ksh can improve overall quality, thereby boosting productivity.

Though many UNIX systems default to KornShell, some Linux and other systems default to different shells. Using KornShell across different systems is a great way to standardize the operations of each system, making interaction easier and less prone to errors. KornShell is used by large enterprises, universities as well as by home users.

What Is Continuous Delivery?

Continuous Delivery (CD) is a software engineering discipline in which teams produce software in short cycles, ensuring that code can be reliably released at any time. The core idea is to replace the traditional, phase-gated release process — where code travels through isolated stages of development, testing, staging, and production over weeks or months — with an automated pipeline that moves changes toward production continuously and safely.

In a mature CD practice, every commit that passes automated tests is a candidate for release. Deployment becomes a low-risk, routine activity rather than a high-stakes event. The business benefit is faster delivery of value to users and quicker feedback loops for development teams.

Why Mainframes Are a Special Case

Mainframe systems — IBM z/OS environments being the most prevalent — power mission-critical workloads in banking, insurance, retail, and government. These platforms process enormous transaction volumes and are held to extremely high availability and auditability standards. That context shapes every decision about how software is developed and released on them.

The tooling, languages (COBOL, PL/I, Assembler, CICS, JCL), and operational models on mainframes evolved decades before Agile and DevOps became mainstream. As a result, several structural differences make applying standard CD practices non-trivial:

• Different version control conventions. Mainframe source code has historically lived in Partitioned Data Sets (PDS) rather than Git repositories, making integration with modern SCM tools a first hurdle.
• Compiled artifacts and load modules. Mainframe programs must be compiled and link-edited into load modules before they can run. Managing these binary artifacts through a pipeline requires tooling that understands z/OS object formats.
• Heavyweight change management. Regulated industries operating mainframes often require manual change advisory board (CAB) approvals, audit trails, and separation of duties — processes that must be encoded into, rather than bypassed by, a CD pipeline.
• Shared environments. Mainframe LPAR (Logical Partition) environments are expensive, so development, test, and pre-production stages often share resources. This complicates environment isolation strategies common in CD.
• Skill gaps. COBOL and JCL expertise is concentrated in experienced staff; DevOps and pipeline engineering skills are concentrated in younger teams. Bridging that knowledge gap is an organisational as much as a technical challenge.

Core Principles of CD Applied to Mainframes

Despite those differences, the fundamental CD principles still apply and can deliver measurable value on the mainframe:

1. Version Everything in a Modern SCM

Migrating mainframe source into Git (or another modern VCS) is the foundation. Tools and plugins exist to synchronise z/OS data sets with Git repositories, allowing mainframe code to participate in the same branching, pull-request, and code-review workflows used for distributed systems. This single change dramatically improves traceability and collaboration.

2. Automate the Build

Compile, link-edit, and package steps that were previously triggered manually via JCL jobs can be automated and invoked from a CI server such as Jenkins or Azure DevOps. Successful builds should produce versioned, immutable artifacts stored in an artifact repository — treating load modules the same way a Java pipeline treats a JAR file.

3. Shift Testing Left

Unit testing frameworks for COBOL (such as IBM’s zUnit/CBLTDAST or the open-source COBOL Check project) allow developers to write automated tests that run as part of the pipeline. Integration and regression test suites that previously ran only late in the cycle can be parallelised and triggered automatically on every commit.

4. Automate Deployment with Auditability

Deployment automation on z/OS typically involves IBM’s Software Delivery Pipeline tooling, Broadcom’s Compuware or ISPW, or open standards such as Ansible for z/OS. The goal is repeatable, scripted deployment that generates an auditable record — satisfying compliance requirements without manual steps that introduce delay and error.

5. Pipeline Visibility Across Platforms

Many organisations run hybrid applications where a mainframe back-end services distributed or cloud-based front-ends. A holistic CD pipeline should surface the status of mainframe builds and deployments in the same dashboard used for other components, giving teams a single view of system health before any release proceeds.

Organisational and Cultural Challenges

Technical tooling is only part of the story. Organisations pursuing mainframe CD typically encounter several cultural obstacles:

• Siloed teams. Mainframe and distributed development teams rarely share practices, stand-ups, or pipelines. Breaking down those silos requires deliberate organisational change as well as tooling integration.
• Risk aversion. The consequences of a production outage on a mainframe processing millions of financial transactions per hour are severe. CD adoption on mainframes must be incremental and demonstrate reliability improvements, not just speed.
• Knowledge transfer. As experienced mainframe engineers retire, capturing their implicit knowledge of system behaviour into automated tests and documented runbooks becomes urgent.

The Business Case

Organisations that successfully implement CD on mainframes report benefits consistent with those seen on distributed platforms: fewer defects reaching production, shorter lead times from code commit to deployment, and reduced toil for operations teams. In regulated industries where change windows are constrained, the ability to deploy smaller, better-tested changes more frequently also reduces the risk associated with each individual release.

The mainframe is not going away. An estimated proportion of the world’s commercial transaction volume still runs on IBM Z hardware, and organisations that treat mainframe delivery as a second-class concern relative to their cloud-native work create operational and competitive risk. Extending CD principles to the mainframe is no longer an exotic project — it is a mainstream DevOps priority.

Getting Started

A pragmatic starting point for teams new to mainframe CD:

1. Audit current source code management practices and identify the gap between PDS-based workflows and Git.
2. Select a pilot application — ideally one with a well-understood test suite and moderate change frequency.
3. Automate the build and a basic smoke-test suite, integrating with your existing CI server.
4. Instrument the deployment process to generate an audit log, and get sign-off from compliance stakeholders that the log satisfies their requirements.
5. Expand coverage iteratively, measuring lead time and defect escape rate as lagging indicators of progress.

Mainframe CD is a long journey, but each incremental step towards automation, visibility, and repeatability delivers value — and reduces the risk of the next release.