DevOps is all about bringing the principles of lean and agile together as part of a continuous improvement process. It's an end-to-end process that's iterative and never fully completed. It's all about removing waste from the system and continuing to improve. Combining agile and DevOps practices makes it easier to build open and hybrid applications. DevOps is the union of people, process, and tools to enable continuous integration and continuous delivery. We've seen an incredible adoption of DevOps over recent years. However, even with the best tools, DevOps is just another buzzword if you don't have the right culture behind it. The primary characteristic of DevOps culture is increased collaboration between the roles of development and operations. But what does all this mean for z and CICS applications? Well, it really doesn't matter what platform or environment you're building for, it's the same DevOps. You don't get the improvement you need by having multiple different ways of working with artificial boundaries in silos in between them. You need an enterprise-based and strategy. Key point here is that there's no technical reasons why traditional z/OS development, including CICS application development and delivery, cannot be part of an open distributed pipeline. You can transform your z/OS and CICS environments into a true modern DevOps practice by bridging the gap between mainframe and distributed by letting developers work in the mainframe and distributed worlds in the same way. What we at IBM want to do is to provide this pipeline as the automation framework for the DevOps transformation. Our approach to a cross-platform delivery pipeline solution is to integrate a variety of open source and third-party tools along with enterprise tooling so that you can choose a pipeline that is right for your organization based on your business needs. Some of the open source and third-party integrations we offer include GITs, Jira, Jenkins, and [inaudible] , just to name a few. We'll look at a few more of these later on. All parts of the pipeline are important. You can't just pick one area and say that you're DevOps is enabled. You should consider the entire pipeline and maybe focus on different areas at different times. But the entire picture is key to set the scope for each part. However, it's equally true that you can't do everything at once. Starting with deployment might be what many customers do as that lessens the set up to the new environments, which in turn also make testing easier. As you can see, the pipeline is not in one direction. It's in the form of a stack with continue analysis and feedback at various points along the way. It's also important to note that this chart includes many solution options in many boxes that all overlap with each other. This demonstrates that you can have significant choice in how you determine the DevOps pipeline that's right for you. There are a few key aspects to the DevOps pipeline that must be common. Let's think more about these aspects and how they specifically relate to CICS applications in a bit more detail. We saw in an earlier video in this series that there are now a number of IDEs that can be used for mainframe application development. These include the IBM Z Open Editor and Zowe, all based on developer choice. Along with these leading edge IDEs, productive application, debugging technologists for CICS such as IBM Debug for z/OS are also available. These provide a round-trip development experience. These modern IDEs all have integrations with Git.. Outside of mainframe development, Git has become the defective sound over source control in all areas of application development. Now, these integration capabilities enable developers to get the most out of a modern SEM like Git and assist with the standardization of true parallel development across the enterprise. Ideally, there should be one SEM and the resources can be shared, a single source of truth and a single place to integrate audit reports and automation. You could use RTC or Git for your SEM, for example. Customers usually choose one or the other, but not generally both. However, the important thing to note is that CICS applications, regardless of language, can fully participate in Git ecosystems. There will be many different build solutions generally based on language, such as Maven or Gradle for CICS Java applications or IBM Dependency Based Build, for additional CICS applications, for example, in COBOL or [inaudible]. Dependency Based Build, DBB, which includes a build tool kit, allows you to build your CICS applications to analyze the dependencies required for build. DBB also includes Groovy for automation and it actually helps you to bring your CICS applications and mainframe processes into the world of open source so you can hook up your mainframe processes to how CICS open-source tools like Jenkins. The CICS team have recently introduced powerful new support for CICS Java developers in CICS TS version 5.6, including supporting Maven and Gradle as two frameworks for building Java applications and the bundles that they're deployed through, as well as adding Libraries to Maven Central to make those DevOps CICD pipeline build chains much easier to create and manage. With this new release of CICS, we also wanted to see if we could come up with the way that Java developers could run their CICS applications directly in their development environments without having to deploy them at all. Importantly, we wanted these applications to still be able to link two programs running in CICS. Crucially, once they finish developing them, we wanted these applications to be deployed unchanged to real CICS regions. Hopefully, this rings a bell, and if you remember, this is the JCICSX API, which is a subset of the JCICSX, in terms of functionality. That means that Java developers, can now run their CICS Java applications locally on their laptops while they're still developing them. Another of the open source integrations I mentioned earlier is Jenkins, a CICD coordinator that provides a single point of order and a single place for integrations. Jenkins, is used as a common tool and to embrace DevOps principles, enabling the management of CI and CD workflows, that can encompass CICS applications. This may be the same Jenkins Master that is running your distributed workloads. Automated testing, is critical to making the DevOps part and possible. Without automated testing, you may just speed up the deployment, but still you'll have to wait on the overall process. In fact, in a recent survey, 52 percent of respondents rated unit testing, the Number 1 stage, for delays in the end to end process. Continuous testing, is a key part of DevOps, and it means testing earlier in the life cycle, which results in reduced costs, shortened testing cycles and continuous feedback on quality. This process of shift-left testing, stresses integrating development and testing activities, to ensure the quality is built in as early as the life cycle as possible. It's really important that the first step of the testing, is done in a clean and automated way, and very early on in the life cycle. So that you'll then feed in tested code into the rest of the life cycle. This process of shift-left testing, ensures quality is built in as early in the life cycle as possible. IBM solutions such as IBMZ open unit test, provide an advanced and flexible tool for writing, and executing automated unit tests of batch, and CICS programs on IBMZ. Stopping capabilities for CICS programs are available. Meaning, developers don't need to deploy CICS during unit testing, thereby enabling environment independence. Automated data capture and recording for batch, and CICS programs, allows for test scenarios to be integrated into any CICD process. You may have also heard of Galasa. Galasa, is a test automation framework that's available as an open source project. Galasa, originated after a number of times when we were discussing, how we did our DevOps pipeline within the CICS organization, and how we approach testing. Especially, the automated parts of testing in CICS. Galasa, allows you to write tests wherever you want. Whether it's using 3270 scripting, or preparing a batch job for execution. Or it can be used with web tools such as, Selenium, integrated within the same test and providing deep integration into Z. Tests can be runned locally on a workstation, but they are still connected to the mainframe without having to change the test code. Using Jenkins, a pipeline can be configured and request that Galasa runs a set of tests. You can specify to run a specific test if there's one that you particularly want to run. Alternatively, I could ask Galasa to run a set of tests, based on information about the change set that was delivered. As I mentioned, Galasa, is an open source project so absolutely join the community and contribute yourself. UrbanCode Deploy, is a tool for automating application deployments through your environments, from tests to production. It is designed to facilitate rapid feedback and continuous delivery in agile development, while providing the audit trails, versioning, and approvals needed in production. You can use IBM UrbanCode Deploy and the specific CICS TS plug-in to automate the deployment, and undeployment of CICS resources. Used in conjunction with other CICS tooling, UrbanCode Deploy can improve workflow efficiency, and contribute to a continuous delivery environment. The plugin includes steps that can automate the actions, such as the installation of CICS resources, pipelines funneling, opening of closing of resources and many more operations. The final thing we've been working on as Z team and the CICS team has contributed towards this, is that we've brought the Red Hat Ansible framework onto the platform. This means, we can write modules and playbooks into active ZOS. So the modules ran on ZOS, can do a variety of automation operations. We have some cool ones that just interact with ZOS concepts like jobs, JCL, data-sets. Of course, we've been adding new CICS specific bonds, that will help you to interact with CICS specific things. This initiative is another way that we can help build CICD pipelines and enable DevOps automation on the platform, in an open source, and standard way using standard Ansible engines that run elsewhere. But hooking into modules and playbooks that target ZOS to perform it's operations. To transmute the automation space towards a much more open source and standard model. Lastly, let's consider the analysis phase within our DevOps pipeline. Using discovery tools such as IBM application discovery, you can visualize application dependencies, automate the discovery effort with mainframe connectors in SEM integration. As well as, identify most essential test cases, redundant test cases, and get an understanding of your code coverage. Furthermore, a combination of IBM application discovery integrates with other CICS analysis tools, such as CICS interdependency Analyzer, allows for 360 degree view of both static applications and CICS code applications as well as, the full run time analysis picture. Breath. This has been a whistle-stop tour, showing some of the capabilities and features that allow CICS applications to fully participate in an automated DevOps pipeline. Hopefully, you can see some of the benefits already and you can go, and look into the ones that seem more useful to you.
