DB2 Continuous Delivery – Safely managing change
DB2 12 for z/OS became Generally Available in October of 2016. This two-part article will introduce Continuous Delivery, the problems with traditional delivery and how Continuous Delivery helps address those problems in Part One. In Part Two, we will delve deeper into the mechanisms of DB2 12 Continuous Delivery.
With the announcement of DB2 12, IBM indicated that DB2 12 would be a Continuous Delivery (CD) release. With DB2 12, IBM will ship new function, preventive service, and prescriptive service in the same stream. This is not new – DB2 has always shipped some new function in the service stream (IDAA support in the DB2 10 timeframe, and JSON support in DB2 11 are both examples of new function that DB2 has recently shipped).
What is new is that IBM has announced its intention to deliver significant, mainline enhancements in the service stream. Generally, in the past, DB2 development has tried to limit enhancements in the service stream to the periphery of DB2 when possible. Balancing the need to bring new function to market, and maintain product stability has always been a challenge to DB2.
To help customers control the rate of change in their shops, IBM announced the introduction of Function Levels in DB2 12, and the extension of Application Compatibility (APPLCOMPAT) covering DDL and Authorization in addition to SQL and XML function. With the addition of DDL and Authorization, customers can now leverage APPLCOMPAT to test and deploy applications at a specific Function Level, and stabilize the environment for that application at that Function Level, while still allowing the other applications to take advantage of recently introduced features at higher function levels.
DB2 has traditionally delivered a new version approximately every 3 years. This method of delivery has numerous downsides:
· Adoption of a new version by customers can be time consuming and costly. Some large customers say that it takes a full year to adopt a new DB2 release. With three years between releases, customers typically would adopt a new release of DB2 in year one, exploit new function in year two, and only have a year of stability before they needed to start over. If a customer fell behind in this cadence, it was difficult to catch up.
· DB2 development was delivering on 3 year cycles but many customers were migrating on ~4 year cycles. This resulted in frequent requests for skip release migration. DB2 has offered skip release migration roughly once every decade to help customers catch up, but customers needed skip release migration more often than that. Lack of skip release migration for every version upgrade lead some customers to adopt risky migration strategies such as migrating DB2 9 to DB2 11 in one weekend. Even when DB2 supported skip release migration, it was riskier for a customer to migrate from say DB2 8 -> DB2 10, than it was to migrate from DB2 8 -> DB2 9 or DB2 9 -> DB2 10. This was because there are two Versions of changes to absorb in a single migration.
· Some changes are so fundamental that migration to the new version of DB2 was disruptive to customers’ practices, procedures, and tools. DB2 8, with the adoption of a Unicode Catalog, and Long name support is one example. DB2 10 with the change to UTS Single Table tablespaces for many catalog tables, the dropping of links in the catalog, and the introduction of 64 bit execution structures is another. The nature and amount of change in DB2 8 and DB2 10 made it difficult for some customers to easily absorb safely. This slows adoption and increases costs for migration for customers. Additionally, both DB2 8 and DB2 10 are examples of releases where skip release migration (skipping over DB2 8 or DB2 10) would have been nearly impossible to provide given the large changes made to the catalog.
· Many customers want or need function that is either in development or has already been delivered in a newer DB2 release. This results in (constant) requests to retrofit function to older releases of DB2. Retrofitting code reduces the ability of the development organization to deliver new function, and can be risky because a function that was developed and tested for a newer release can have hidden dependencies on function in that newer release. Retrofitting function to previous releases also dilutes the value of the newer release. This can lead to slower adoption of a new release, or increased requests for skip release migration.
· The Waterfall Development Process relied on a long release cycle to develop and stabilize code. Risky items would deliver late in the cycle and a long test cycle was required to stabilize the code. Agile Development and Continuous Integration were adopted in DB2 11 to help improve quality and code stability. However, the time to value for the customer has not changed.
Continuous Delivery is a natural progression of Agile Development and Continuous Integration used in DB2 11. The introduction of APPLCOMPAT in DB2 11, and Function Levels in DB2 12 will provide the basis for controlling when a function or capability is exposed to the DB2 system, or a specific application.
Continuous delivery in DB2 12 solves many of the problems listed above by:
· Reducing the time to adopt new functionality.
o Customers will be running with the code that contains the new function, as part of their normal maintenance process before they adopt the new function.
o Enable only applications that need new function to be exposed to that function via APPLCOMPAT.
o Increases the likelihood that customers have the function that they need, already installed on their systems, when then need to activated it for an application.
· Increasing the time between Versions, increases the time that customers have stable systems. This will enable more value to be delivered by IT organizations and less money spent on just continuously migrating to new versions of Software.
In our next segment, we will discuss how Function Levels and APPLCOMPAT can be used together safely manage the Continuous Delivery journey we are embarking
IBM Distinguished Engineer