Mainframe development teams are relying on DevOps
practices more extensively, bringing the need to incorporate Db2 for z/OS
database changes into the toolset that is supporting their software development
lifecycle (SDLC).
But most mainframe
professionals have only heard a little about DevOps and are not really savvy as
to what it entails. DevOps is an amalgamation of Development and Operations.
The goal of DevOps is to increase collaboration between developers and
operational support and management professionals, with the desired outcome of
faster, more accurate software delivery.
DevOps typically relies
on agile development, coupled with a collaborative approach between development
and operations personnel during all stages of the application development
lifecycle. The DevOps approach results in small and frequent code changes and it
can significantly reduce the lead time for changes, lower the rate of failure,
and reduce the mean time to recovery when errors are encountered. These are all
desirable qualities, especially as organizations are embracing digital
transformation driven by the 24/7 expectations of users and customers to access
data and apps at any time from any device.
The need to be able to
survive and thrive in the new digital economy has caused organizations to adopt
new and faster methods of developing, testing and delivering application
software. Moving from a waterfall software development methodology to an agile
methodology is one way that organizations are speeding the time-to-delivery of
their software development. Incorporating a DevOps approach is another.
Instead of long software
development projects that may not deliver value for months, or perhaps even
years (common using the Waterfall development methodology) an agile DevOps
approach delivers value quickly, and then incrementally over time. DevOps
enables the continuous delivery of new functionality demanded by customers in
the digital economy.
Succeeding with DevOps,
however, requires a cultural shift in which all groups within IT work in
collaboration with one another, and where management endorses and cultivates
this cultural change. Because DevOps relies upon incremental development and
rapid software delivery, your IT department can only thrive if there is a
culture of accountability, collaboration, and team responsibility for desired
business outcomes. Furthermore, it requires solid, integrated automated tooling
to facilitate the SDLC from development, through testing, to delivery. Creating
such an environment and culture can be challenging.
With DevOps the result
will be a constantly repeating cycle of continuous development, continuous
integration and continuous deployment. This is typically depicted graphically
as the infinity symbol such as in Figure 1 (below).
Note, however, that this particular iteration of the DevOps infinity graphic calls out the participation of both the application and the database. This is an important, though often lacking, detail that should be stressed when adopting DevOps practices.
The
Mainframe and DevOps
The adoption of DevOps has,
until now, been much slower within mainframe development teams than for
distributed and cloud application development. The staid nature of mainframe
development and support, coupled with a glass house mentality, and a rigid
production turnover process contribute to the delayed adoption of DevOps on the
mainframe. This is not surprising as mainframes mostly are used by large
organizations running mission critical workloads with an aversion to any kind
of change and risk-averse.
Additionally, the
traditional waterfall development methodology has been used by most mainframe
software developers for multiple decades, whereas DevOps is closely aligned
with an agile approach, which differs significantly from waterfall.
Notwithstanding all of
these barriers to acceptance of DevOps on the mainframe, mainframe developers can,
and in some cases already do successfully utilize a DevOps approach.
Technically speaking, the mainframe is just another platform and there is
nothing inherent in its design or usage that obviates the ability to
participate in a DevOps approach to application development and delivery.
What about
Db2 for z/OS?
Integrating database
change into the application delivery lifecycle can be a stumbling block on the
road to DevOps success. Development teams focus on application code, as they
should, and typically view database structure changes as ancillary to their coding
efforts. In most application development projects, it is not the programmer’s
responsibility to administer the database and modify database structures. But
applications rely on the database being designed, implemented, and changed in
accordance with the needs of the business and the code.
This means that many
development projects have automated their SDLC tool chain to speed up the
delivery of applications. This is the “Dev” portion of DevOps. But the
requisite automation and tooling has not been as pervasively implemented to
speed up the delivery of database changes. This is the “Ops” portion of DevOps.
And this is changing.
A big consideration is
that the manner in which change is applied to applications differs from how
database changes are applied. That means each must be managed using different
techniques and probably different tools. When an application program changes,
the code is compiled, and the load module is migrated from test to production.
The old load module is saved for posterity in case the change needs to be
backed out, but the change is a wholesale replacement of the executable code.
Database changes are
different. The database is an entire configuration in each environment and
changes get migrated. There is no wholesale replacement of the database
structures. DDL commands are issued to ALTER, DROP, and CREATE the changes to
the database structures as needed.
From the perspective of
database changes on Db2 for z/OS, DBAs need the ability to modify all the
database objects supported by Db2 for z/OS. Supporting Db2 for z/OS using
DevOps requires tooling that understands both Db2 for z/OS and the DevOps
methodology and toolchain. And the tooling must understand how changes are
made, as well as any underlying changes that may be required to effectively
implement the database change. Some types of database changes are intrusive,
requiring a complicated series of unloads, metadata captures, drops, creates,
loads, and additional steps to implement. The tooling must be capable of making
any of these changes in an automated way that the DBA trusts.
Fortunately, for
organizations adopting DevOps on the mainframe with Db2, there is a solution
for integrating Db2 database change into the DevOps toolchain: BMC
AMI DevOps for Db2. BMC AMI DevOps for Db2 integrates with Jenkins, an
application development orchestration tool, to automatically research and
determine database schema change requirements, to streamline the review and
approval process, and to safely implement the database schema changes making
development and operations teams more efficient and agile.
