Shift-left DevOps Database Operations With Db2 Schema Provisioning

Authors John Benbow (Sr Manager Product Owners Data Management Broadcom) and Sujay Solomon (Manager Product Management Broadcom)

The Broadcom Mainframe Software Division has an “Embrace Open” approach. Opening up the mainframe enables access to data and management of mainframe systems via contemporary development tools, such as Visual Studio Code (VS Code), along with the ability to integrate with CI/CD orchestration tools such as Jenkins and source management tools such as Git. See how you can integrate Broadcom’s Endevor platform with Git using Endevor Bridge for Git here.

In the last blog, we outlined Broadcom’s commitment to applying the “Embrace Open” approach to mainframe databases.

In this blog, we focus on Db2 for z/OS database administration, which needs to be a part of the shift-left effort to enable developers to quickly access the Db2 resources they need. Specifically, the DBA tasks to provision objects in a database need to be automated so the DBA role does not become a bottleneck. This automation can be enabled by scripting Zowe CLI commands and calling those scripts programmatically, or by calling RESTful APIs natively.

Broadcom will soon be releasing the dbm-db2 Zowe CLI plugin, which enables you to automate DBA functions and integrate them fully into your DevOps pipeline. You can register for validation here and download the pre-GA code to try at your site. The DBA can still maintain control of the schema changes pushed to production by reviewing comparison output before approving the change to move to the next level (eg. From Dev to Test and Test to Prod). Here is a list of some of the commands you can issue using the dbm-db2 Zowe cli plugin:

• zowe generate ddl retrieves the DDL for a list of specified Db2 objects (i.e. tables, indexes, etc.) from the selected Db2 subsystem (catalog). It can also change some of the DDL attributes during the retrieval (e.g. schema or buffer pool).
• zowe compare ddl analyzes what it would take to implement DDL statements to a specified Db2 subsystem. The command output includes the “update script” (“DDL delta”) and simplified report (ICL statements). Both are to be reviewed before the update-script is executed and the Db2 subsystem is updated.
• zowe deploy ddl implements the DDL from a file to a specified Db2 subsystem. It deploys the DDL in an optimized way with the least disruption possible.

These commands can be included in automation scripts and enable someone like Michelle, who is an Application Developer used to working with contemporary tools, to get access to DDL without making a request to Roger the DBA.

• Michelle initiates a script that runs a generate ddl command. The generate ddl command pulls the DDL for a list of objects from a Db2 subsystem.
• Michelle then makes changes to the DDL in her sandbox that are required to support her application change — for example, adding a new column to a table.
• Michelle then checks her changes into git. This check-in triggers Jenkins (or some other CI/CD orchestration tool of your choice, such as GitHub Actions, GitLab CI, etc.) to run another automation script to issue a compare ddl and notify Roger the DBA to review the compare output.
• Roger then performs the review to ensure the changes are good before the change moves to production.
• Once Roger approves the change, Jenkins can then run an automation script to issue the deploy ddl command and push the changes to production.

Automating object and schema provisioning enables the standard mode of interaction between the developer and the DBA to shift left and improve efficiencies — which in the end is what DevOps is all about. Getting new applications and application changes into production faster enables us to rapidly realize their benefits and improve business outcomes. Integrating the mainframe into the DevOps pipeline, and ensuring its integration has an efficient outcome, also means your organization has a greater opportunity to exploit the power of the mainframe in your applications.

It is also important to note that this move to automation does not diminish the value of the Db2 for z/OS DBA but instead enables the DBA to focus their time on less mundane tasks. For example, rather than relentlessly performing the low-skill task of running DDL to define objects and schemas for developers, DBAs can now focus on more nuanced and high-skill aspects of database administration — such as database performance tuning and database design.

Automating the provisioning of objects and schemas is one aspect of how Db2 for z/OS can be better integrated into DevOps. There are many other areas of provisioning that also need consideration, such as:

• Data and its obfuscation for testing, and granting access to data.
• How to manage SQL and DDL as source code in source control systems to ensure we can manage SQL and DDL as any other code enabling us to back out bad changes easily in production or test when needed.
• Empowering Site Reliability Engineers (SREs) to better manage SLAs across applications running in heterogeneous environments by enabling them to expose Db2 performance data into open source monitoring tools like Grafana.
• Running EXPLAINs to perform “before-change” and ‘after-change” access path comparisons to assure performance impacts are remedied prior to deployment to production.

There are many areas to consider to ensure Db2 for z/OS is enabled for DevOps. We will be sharing more information on these areas in our future articles.

The Broadcom Mainframe Software Division is focused on and invested in enabling customers to seamlessly integrate our powerful Db2 tools into these environments to support sophisticated Db2 management in enterprise-grade DevOps environments. We look forward to partnering with you on this journey.

You can learn more about our Broadcom Db2 DevOps story here.

Please reach out to our DB2 Experts using Db2-Experts.pdl@broadcom.com with any questions you may have specific to Db2 DevOps.

Hope you are well and staying safe!