This chapter introduces the new development and operations (DevOps) features that are available in IBM Customer Information Control System (CICS) Transaction Server V5.3. These new capabilities, including the IBM CICS Transaction Server build toolkit (CICS build toolkit) and a new CICS plug-in for IBM UrbanCode Deploy, enable IT departments to release new applications faster than before by breaking down the traditional walls between the development and operations teams.

Of course, with CICS handling transactions for some of the world’s biggest banks and other enterprises, some IT managers are reluctant to adopt the new DevOps features for fear of impacting vital applications. However, the new features can be introduced slowly. You can even adopt a bi-modal approach so that you can use DevOps capabilities to release new Java business or interface logic in rapid cycles while retaining your existing development methods for less frequent updates to mission-critical, back-end applications.

This chapter covers the following topics:

CICS Transaction Server is the transactional workhorse that keeps many of the world’s biggest banks and other large enterprises running smoothly. Its flexibility, adaptability, and underlying components, such as IBM z Systems products, have kept it the dominant force in the industry for years.

But the IT world is changing.

Traditionally, there was a clear line between development and operations. The development team wrote code and created applications. The operations team then built, packaged, and deployed those applications for use. Unfortunately, this approach is linear. Each stage of the process depended on the previous stage. This led to several problems:

Worse, with the teams operating in their own silos, communication was often ineffective and business goals were sometimes not achieved. New software releases were frequently delayed and the overall process was subject to sudden disruption.

Such was the state of application development for years. It was acceptable (at least somewhat) because customer expectations were still low. If your software did not work perfectly today, a fix would arrive in the next release. So, you waited six months to a year and everything would be corrected.

But, that situation was before the advent of today’s app economy. With the emergence of smartphones and other devices, there is an explosion in apps that can do such varied tasks as ordering pizza to managing a warehouse. Through the Internet of Things, companies can better monitor remote equipment and gain new insight into customer behavior (even at the most minute level), so the pressure to make full and immediate use of this data grows by the day.

So, waiting six months for a software update is unrealistic. Your customers will ask you why their smartphone manufacturer can push out new operating system updates every week, but they must wait months for the improvements they requested.

To speed the release of new applications and updates, the IT industry works to apply agile and lean principles to development and deployment. At the core of these principles is eliminating wasted effort, breaking down artificial barriers between related functional teams, and adopting continuous release cycles that push improvements out to users faster than ever before.

One such artificial barrier is the line (thicker in some companies than in others) between development and operations teams. However, this line is being eliminated and a new, more aggressive, and business-driven approach that is called DevOps has emerged. Applications are built, deployed, rebuilt, and redeployed in rapid cycles aimed at delivering continuous, incremental improvements.

So can CICS continue to thrive in a DevOps world? The clear answer is yes.

In this publication, you see that tools such as the CICS build toolkit and the DFHDPLOY utility are removing the walls between CICS developers and operations staff. Apps and updates can move more rapidly from raw code to deployable artifacts. You can even enable automatic deployment of approved apps, configurations, and other artifacts by integrating CICS with IBM UrbanCode Deploy.

In a DevOps shop, the business owner, the developers, and the operations team work collaboratively. The plan-develop-build-deploy-feedback process is continuous (see Figure 1-1). When possible, human actions are minimized in favor of autonomous tools, including software builds that start on their own when eligible code updates become available. Applications reach their full potential faster, often by using fewer resources than in the past.

There is a strong focus on continuous integration, continuous collaboration, and continuous improvement. These are the core principles of the DevOps approach. Together, they provide numerous advantages:

New features and functions are pushed out to users faster than before. As each new feature is released, you get user feedback that can be used to improve the next release.

Teams can work on small, incremental updates rather than holding everything for a master release, which means more time for innovation, which in turn becomes an ongoing, repeatable process.

By releasing more frequent but smaller updates and generating new customer feedback each time, applications are improved faster and the end state of the application is achieved more rapidly.

The DevOps approach is multi-platform. The principles are the same whether the application runs on a mainframe, in a distributed environment, or in the cloud. It can be applied to any development effort, from enterprise applications such as back-end banking systems to more customer-facing products such as smartphone tools. It is customer-neutral. Whether you are working with an external client or an internal line of business, DevOps can help you meet your commitments faster and with better results.

So, the benefits of DevOps are clear. But, adopting a DevOps approach can be daunting. Breaking down the walls is the easy part. It is more difficult to determine where within your IT operation to apply DevOps principles. Where is the rapid release, rebuild, and rerelease aspect of DevOps most beneficial? Where might such frequent changes create problems? How can you be both fast and stable at the same time?

One answer is to adopt a bi-modal approach to IT. Use the rapid development-release methodology for user interface updates, for example, which today’s users expect, but retain your typical, longer development calendars for core business applications. Or, use DevOps teams to build quickly new applications that are aimed at winning new business, but keep traditional methods in place to assure the quality of existing business applications.

CICS Transaction Server V5.3 is well-suited to bi-modal IT because it contains the best of both worlds: traditional application development and application development through the DevOps approach.

Table 1-1 describes how CICS work can be split up in a bi-modal fashion.

Another way to look at bi-modal DevOps is to consider where your updates are targeted. Where rapid changes are beneficial because of user expectations or a changing business environment, use the DevOps approach that is possible in CICS Transaction Server V5.3. Where a stable base is your priority, use more traditional methods with typical regression testing.

Table 1-2 provides examples of where the different modes are preferably applied.

Many IT experts predict that as new technologies emerge that require more interfaces to more channels, the DevOps approach will gain popularity for the speed with which it can generate releases and updates. Over time, as DevOps methods mature and more companies adopt them, the quality of the involved processes will improve and the rapid updates that are released will grow more stable and reliable.

Even if companies continue to maintain their critical applications by using old methods, it is anticipated that as their DevOps teams gain more experience and produce good results, these companies will be more willing to use DevOps even for their most vital applications. In this sense, as the industry gets better at DevOps, it is expected that the role of DevOps within the typical IT shop will expand even more.

In the traditional software delivery pipeline, developers write code in an integrated development environment (IDE), such as Eclipse. When they are ready, they deliver the new code into the company’s source code management (SCM) system. Then, the operations team builds the applications so that they are machine-ready; the resulting packages are put into a package repository. The application is deployed to the test environment, then a pre-production or staging environment, and finally the production environment.

The DevOps delivery pipeline has all the same phases. But, it adds automation and continuous feedback loops, so more things happen automatically, and the deliverable artifact can improve with each develop-build-deploy cycle.

Some traditional roles (and where they fit in the progression) are revised in the DevOps pipeline:

An integrated deployment solution is vital in a DevOps environment to bring together the deployment of all artifacts. The artifacts can be developed by different teams, written in different languages, originate from different platforms, and have different deployment solutions within a platform and across multiple platforms. The aim is to manage the artifacts within an integrated process. So, deployment of a Java bundle in a CICS Liberty environment, deployment of a COBOL load module into a CICS application environment, and deployment of a CICS cloud application can occur together.

CICS Transaction Server V5.3 includes a number of solutions to manage artifacts and assist organizations in adopting the DevOps approach.

The CICS build toolkit provides a command-line interface (CLI) to build your CICS projects that are created in CICS Explorer. This method is superior to the previous manual method of using a wizard to export the CICS projects to zFS because you can use a script to build projects in a reliable, repeatable manner. Using the build toolkit is one step toward a fully automated, continuous integration process (see Figure 1-2).

The CICS build toolkit can build these projects:

A significant feature of the CICS build toolkit is its ability to resolve variables within attributes by using values from a properties file, which means that CICS bundles can be redeployed to different target environments by using different variable settings, without any changes to the underlying source code. For example, a debug variable can be set in the development environment but not in the test or production environment.

The automation features of the CICS build toolkit apply within two specific processes. First, the build automation process uses the toolkit to build the project. Then, the deployment automation process uses the toolkit to resolve the variables into specific values for the target environment.

The CICS build toolkit is supported on IBM z/OS®, Linux, and Microsoft Windows, which makes it easy to integrate it with various SCM system tools. It can be used with CICS Transaction Server V4.1 and later versions, enabling organizations that are not yet using CICS Transaction Server V5.3 to still make the move toward DevOps.

Also introduced in CICS Transaction Server V5.3 is a new utility called DFHDPLOY. DFHDPLOY provides a set of commands that can be used in a script to deploy, undeploy, and set the state of CICS bundles and cloud-enabled CICS applications. The utility also can connect to a CICSplex.

When you use the utility’s Deploy command, the CICS bundle or CICS application can be defined and its state changed to Disabled, Enabled, or Available within a CICS system or group of CICS Systems.

For a cold start, the Deploy command can be used to add a bundle definition to a CSD group that is part of a startup list, or add it to a RESGROUP that is added to a RESDESC.

When you use the Undeploy command, the CICS bundle or CICS applications state can be changed to Unavailable, Disabled, or Discarded. The Unavailable state waits for the application workload to complete before performing any action.

When you use the SET command, a higher version of an OSGi bundle can be phased in without disrupting active tasks.

The DFHDPLOY utility is called by using JCL and can be easily integrated into existing deployment tools and automation procedures. DFHDPLOY can be used with the CICS build toolkit to automate the building and deployment of CICS bundles and cloud-enabled CICS applications. It can also be used to enhance a continuous delivery environment and help the move to DevOps.

The IBM UrbanCode Deploy tool automates the deployment of artifacts ranging from applications to middleware configurations to database changes. CICS Transaction Server V5.3 includes a plug-in that enables IBM UrbanCode Deploy to work with CICS resources.

For more information about IBM UrbanCode Deploy, including typical use cases and features or to download an evaluation version, go to the following website:

Organizations can use the new IBM UrbanCode Deploy plug-in in CICS Transaction Server V5.3 to improve workflow efficiency and wrap CICS deployments into their overall continuous delivery processes.

The plug-in can perform these actions:

The IBM UrbanCode Deploy plug-in and the new DevOps tools that are built into CICS (the CICS build toolkit and the DFHDPLOY utility) are described in greater detail in Chapter 4, “Release environment” on page 43.

When the new tools and utilities that are described in this chapter are considered together, it creates a new DevOps-style delivery pipeline.

Figure 1-3 on page 9 illustrates how IBM Rational® Team Concert™ can provide a framework for development and build activities. Developers can use the Rational Team Concert client and use IDE extensions with plug-ins such as CICS Explorer. Concurrently, they can use source control management practices for accurate versioning of the source code repository.

As you move into the build, continuous integration, and testing functions, Rational Team Concert can be extended with the CICS build toolkit for process integration and build automation. Built artifacts can then be stored in a separate repository where deployment tools such as DFHDPLOY (for CICS projects) and IBM UrbanCode Deploy inject environment-specific variables and definitions before finally deploying the artifacts to the target environments.