What's new in IBM® Wazi Deploy

Edit online

Version 3.0.2

  • This Wazi Deploy version supports Linux® x86 and Linux on Z for the Ansible translator.
    Moreover, it supports the following versions of the Ansible® collections:
    • IBM z/OS core collections 1.8.x and 1.9.x
    • IBM z/OS IMS collection 1.3.0
    • IBM z/OS CICS collection 1.0.5
  • Some enhancements are available on the Wazi Deploy CLI commands.
    • The following arguments have changed in the wazideploy-generate command:
      • manifestName is now deploymentPlanName.
      • manifestVersion is now deploymentPlanVersion.
      • manifestDescription is now deploymentPlanDescription.
      Note: The old argument names are still valid but a deprecation message is printed in the console.
    • The following arguments have been added to the wazideploy-package command:
      • manifestExtension
      • manifestExtensionOptions

      You can use these arguments to amend the generated manifest state with external information.

  • The following enhancements are available on the building blocks:
    • A new tso_command building block is available to run TSO commands on the target z/OS® system.
    • A new ims_olcutl building block is available to copy a source library with your new definitions to a target library.
    • The design and implementation of the ims_mfsutl building block have been improved.
    • You can rename artifacts for the deployment. Then, the building blocks process these artifacts under names that are different from the names in the application package.
    • Aliases are supported for the load module artifacts. Any aliases that are found in the PDS/E library or member can be preserved during the copy operation of the member_archive, member_copy, and member_restore building blocks.
    • The use of Jinja2 templates has been enhanced:
      • The job_submit building block accepts a Jinja2 template as the source file. This template is rendered before the generated JCL is submitted.
      • You can provide your own Jinja2 JCL template for the db2_bind_package, db2_bind_plan, ims_mfsutl, and ims_olcutl building blocks. The execution JCL that is submitted for the building block is generated from this template.
    • The ASA control characters can be recognized in the following building blocks: member_archive, member_copy, member_restore, sequential_archive, and sequential_copy.
  • You can create a deployment method fragment and reuse it in various deployment methods.
  • The https://www.ibm.com/support/pages/apar/PH59753 APAR is fixed.

Version 3.0.1

  • An evidence requester is available to audit the deployment process and result. It analyzes the contents of the evidence files that are created at the end of each deployment. The requester involves a query language and a command. You use the Wazi Deploy query language, which involves YAML or Jinja2 coding, to specify the extraction criteria and how you want to print the result. Then, you use the wazideploy-evidence command to start the analysis.
  • IMS applications can be deployed. So IMS building blocks, such as ims_acb_gen or ims_command are available. All their names start with ims.
  • Some of the existing building blocks have been enhanced.
    • You can now perform text substitution with the member_copy building block.
    • You can provide your own JCL template for the db2_bind_package and db2_bind_plan building blocks.
    • For the Ansible CICS® building blocks, you can reference a variable in the cmci_password variable to avoid printing the CMCI password in the console.
  • Nexus can be used as the artifact repository to upload the content of a local folder that contains the artifacts of an application.