DevOps: tooling for the Gartner "Create" toolchain step

In this post we will cover the "Create" step from the Gartner Toolchain, which Gartner defines Create as follows:

"Create includes all activity associated with the creation of the code release candidate, including the environment configuration. Tools here must support required platforms and fit the associated practices (e.g., behavior-driven development, code review), and may include cycles to prototype user experience (UX). This also includes source change management systems and activities around managing defects and fixes."

Source: Choosing the Right Tools for Your DevOps Toolchain, Published: 10 April 2017 ID: G00322126, Analyst(s): David Paul Williams, Thomas E. Murphy

In another publication Gartner says the following:

"In some DevOps environments, the lines between the activities in Create and Verify are merged and overlapping, depending on the agile practices adopted, the skills and roles, the type of application, and the application architecture. For example, in DevOps, quality assurance (QA) is not a distinct team, but an activity that is an integral part of software development extending through Create and Verify. With DevOps, the objective is to proactively prevent errors, not find them."

Source: Avoid Failure by Developing a Toolchain That Enables DevOps, Published: 16 March 2016, ID: G00293223, Analyst(s): David Paul Williams | Thomas E. Murphy

The following list is a summary of the "Create" activities:

  • Design (software, configuration)
  • Code, code merge, code quality and performance
  • Build and build performance
  • Functional test
  • Release candidate"

Gartner's "Create tools" categories

The tools are subdivided in three categories: code, build and configure.

  • Code: Apple, Atlassian, Codenvy, GitHub, IBM, JetBrains, Microsoft, Parasoft , Perforce and Subversion
  • Build: Atlassian, CircleCI, Electric Cloud, IBM , JetBrains, Jenkins, Microsoft, OpenMake Software, ThoughtWorks and Travis CI
  • Configure: CFEngine, Chef, Puppet Labs, Red Hat (Ansible) and SaltStack

Code category

Let us start with the "Code" part. In this category, there are five types of tools: issue tracking, integrated development environment (IDE), versioning, build tools and configure.

Issue tracking: managing defects and fixes

Create can start with activities around managing defects and fixes. Possible tools are Atlassian (JIRA), Microsoft TFS with work items, Bugzilla, HPALM defects and many others.

Figure 1: Jira

The IDE or the Integrated Development Environment

As a next tool I would mention the IDE or the Integrated Development Environment. The primary function here is editing and writing code.

In the early days these where on dumb terminals and just text editors, not to forget the punch cards!

Today we have Visual Studio from Microsoft or a lot of eclipse based IDE’s. All of these IDE’s come with a lot of features. Eclipse by example works with perspectives and each perspective comes with his own view and features.

In mainframe land, several vendors have their own z/OS perspective. This allows you to define connections from Eclipse to z/OS and have a view on the z/OS files (called PDS or PDSE) and on the jobs that you run on the mainframe.

You also have Eclipse plugin’s like Slickedit that have fantastic source code and text editing features with time-saving programming features.

Some Eclipse based IDE’s will also help with code quality checking or unit testing. Or you can do local compiles for COBOL or PL/1 without having to access the mainframe.

Figure 2: Eclipse, z/OS perspective

Version Control Repositories

One key DevOps feature that should always be there is versioning. Most IDE’s have today a standard integration with CVS, Subversion, GIT or others. All of these Version Control repositories have their own features and benefits. We, for our package based Build and Deploy solution selected Subversion as here you can do partial tagging, what can’t be done in GIT.

Build Category

The probably most popular build tool is Jenkins, especially in the JAVA world. It comes with a lot of features and integrations, but one might say it is not very user friendly and requires good administration.

Figure 3: Jenkins


Puppet defines configuration management as follows:

"Configuration management is the process of standardizing resource configurations and enforcing their state across IT infrastructure in an automated yet agile manner.”

As a summary you could say that the create step is developer oriented. But when we look at the different categories Gartner defines we see that for some of these categories developers are just users of it, but are not responsible for setting up and maintaining these tools.

Issue tracking, version control repositories, build management can get so complex that you have separate responsibilities or stakeholders for these and that developers just use them.

Here's our approach

Each DevOps project is different. Each customer has his own existing way of working and tooling and in most cases they want, more or less, keep the good.

That is why with IKAN ALM we adapt ourselves to the way of working of the customer and allow the customer to reuse existing tooling and allow him to go step by step and enhance the DevOps toolchain by adding IKAN ALM Phases to deepen their Build and deploy processes.

We've made a video where you can see a sample toolchain for z/OS mainframe.

In the next post

Next we will cover the "Verify" step from the Gartner toolchain.

Picture of Rene De Vleeschauwer

About the author

Hello, my name is René De Vleeschauwer.

Throughout my career I've been responsible for the development of enterprise software. Since 12 years I've been leading the development of IKAN ALM, an open DevOps framework.

Form by ChronoForms - ChronoEngine.comDo you have any questions about this post? Just ask me!

Get free insight!

Let's analyze your current mainframe development -and release process, and show you how to make it much faster and 100% reliable.

Yes, I want insight