What is new and noteworthy in IBM Dependency Based Build

Here you can find what is new and noteworthy for new releases of IBM Dependency Based Build (DBB) v2.0.x.

Version 2.0.2

Important notices

Upgrading the database

If you are upgrading to DBB 2.0.2 from a previous release of DBB, you must upgrade the DBB database before using DBB 2.0.2. For detailed instructions on how to upgrade the DBB database, see Upgrading the DBB Db2 or Db2 for z/OS database.

Toolkit deprecation notices

  • Beginning in DBB 2.0.2 the personal daemon has been deprecated and will be removed in a later release. You should use the updated shared daemon (described in "New features" below), which is now optimized to run on a development logical partition (LPAR).

  • Metadata store stand-alone collection Java APIs and command-line interfaces (CLIs) are deprecated now that Collections have been moved to a Build Group artifact (see "Metadata store changes" below). You should switch to the new BuildGroup Java APIs and CLIs when you create and access Collections.

  • The Metadata store legacy command-line interface (CLI) that was introduced in DBB 2.0.0 is deprecated and will be removed in a later release. DBB 2.0.2 introduces a new redesigned, easier-to-use CLI (described in "New features" below) that you should begin to use.

New features

  • The shared daemon can now be deployed to a development LPAR

The shared daemon that was originally introduced to improve DBB build performance on IBM Z Systems Development and Test Environment (ZD&T) has been updated with additional security mechanisms and queuing enhancements for deployment to a development LPAR. In addition to increasing DBB build perfomance, the shared daemon can be used to limit the number of Java Virtual Machines (JVMs) that run concurrently on an LPAR. For information on how to configure the shared daemon for deployment to a development LPAR, see Configuring the shared and personal daemons.

  • Introducing build maps

A build map is a new metadata store object that stores information about how a program was built, including Git repository information (URL, branch, snapshot hash), as well as additional source files and binary inputs from previous builds. It also provides information about the output binary files that were generated when the program was built. For more information, see Build maps.

  • Executing z/OS UNIX commands

DBB now provides the UnixExec command to execute z/OS Unix commands and programs without having to create a Java process object. UNIX stdout and stderr messages can be captured and stored in a build output file. Similar to other DBB execute commands, a build report record for each UnixExec command executed is automatically created. For more information see the z/OS Command UnixExec.

  • Metadata store changes

Beginning in DBB v2.0.2 the Build Group becomes the high-level container for all metadata objects: Build Results, Collections, and Build Maps. New Java APIs and CLI commands have been added to support the new organization. This change primarily impacts the creation and access of Collections. Collections created before DBB v2.0.2 have been moved to the dbb_default build group. For more information about this change, see How to manage build dependencies.

  • Redesigned metadata command-line interface (CLI)

DBB v2.0.2 introduces a new metadata command-line interface (CLI) structure that is action centric rather than object centric. The focus on actions instead of objects provides a simpler, easier-to-use syntax. For more information, see Metadata store command-line interface.

Version 2.0.1

Important notice

Upgrading the database

If you are upgrading to DBB V2.0.1 from a previous release, you must upgrade the DBB database before using DBB v2.0.1. For detailed instructions, see Upgrading the DBB Db2 or Db2 for z/OS database.

Toolkit API Deprecation Notice

With the introduction of the new JobExec command for submitting JCL (described below in New Features), the existing JCLExec command is deprecated and will be removed in a later release. You should update your build scripts to use the new JobExec command instead.

New features

  • The JobExec command

The new JobExec command serves as a replacement to JCLExec and does not rely on the System Display and Search Facility (SDSF) to function. For more details, see The JobExec command.

  • RACF Group Configuration

The DBB Metadata Store uses RACF groups to define user access permissions. In DBB 2.0, DBB required that RACF groups that matched the role names were defined. In DBB 2.0.1 and later, a database mapping table can be used to map one or more existing RACF groups to a DBB role. For more information on configuring RACF groups see Mapping RACF groups to roles.

Version 2.0.0

Important notice

DBB v2.0 breaking changes

DBB 2.0 introduces some significant changes from previous DBB releases. These changes may require modifications to existing CI/CD pipeline scripts and existing DBB Groovy build scripts. Some changes of note are:

  • Removal of the DBB Server Liberty Web Application as a DBB component.
  • Replacing the Apache Log4J with a new logging framework.
  • Removal of previously deprecated DBB APIs.

For a complete list of changes and how to upgrade your existing pipeline and build scripts to address these issues, see Upgrading to DBB 2.0.

New features

  • The DBB toolkit installed on z/OS UNIX now connects to Db2 databases directly

New DBB toolkit APIs directly access the DBB build metadata that is stored in either Db2 for LUW (Linux®, UNIX, and Windows) databases, or in Db2 for z/OS databases. For more information, see Metadata Store.

  • The DBB toolkit now supports both Java™ 8 and Java 11

The IBM Dependency Based Build (DBB) v2.0.0 and later toolkit (installed in z/OS UNIX) can now run under both an IBM z/OS Java 8 64-bit Java Virtual Machine (JVM) and an IBM z/OS Java 11 64-bit. For more information, see DBB 2.0.0 Prerequisites.

  • DBB 2.0 toolkit has replaced Apache Log4J with SLF4J logging technology

The Apache Log4j logging technology is replaced by the Simple Logging Facade for Java (SLF4J) technology, which allows for different logging frameworks to be bound. By default, the SLF4J Simple Logger is used. For more information, see Configuring the logging framework.