What's new in IBM Wazi Deploy

Interim fix 3.0.7.1

Version 3.0.7

• To generate the package file, you can use the Package task that is provided with the zBuilder in IBM Dependency Based Build 3.0.4 and later. This task also generates a Wazi Deploy application manifest file that includes the details of the artifacts to be deployed and the list of the artifacts to be deleted. This solution is highly recommended if you use DBB as the build framework.
• The GitLab package registry is now supported by The Wazi Deploy packager command and The Wazi Deploy generation command.
• If a deployment fails for a building block that is related to artifacts, you can restart the same deployment but for the step that failed, only the artifacts that were not deployed will be processed. In this version, this capability is available only with the member_copy, member_archive, member_restore, member_delete building blocks. For more information, see how to restart the deployment in The Python deployment command or The Ansible deployment command.
• The retry instruction can now be entered on a step of the deployment method to condition the deployment. Use it to run the step again if its previous result was Failed. The maximum number of retries and the interval between retries are specified. For more information, see The deployment method and Syntax of the conditional deployment.
• New predefined variables such as current_activity_name or deploy_timestamp can be called from a Jinja2 template or a building block to fetch information about the current deployment. For more information, see The deployment variables.
• Variables such as artifacts or deployment_plan can be called from a Jinja2 template that you create and call from some building blocks (job_submit or tso_command for example). For more information, see Variables available in Jinja2 templates.
• An attribute named target is available upon deployment on the artifacts for which a spec variable is specified. The value of this target depends on the artifact type. For more information, see the target attribute.
• The Wazi Deploy building blocks have been enhanced:
  • A new create_backup_pds variable can be used in the member_archive building block. If this variable is set to False, the creation of the backup PDS is skipped. The default value is True.
  • A new wait_time_s variable can be used for Python in the system_command building block. This variable sets the maximum time in seconds to wait for the commands to run.
  • The Jinja2 template that is used in the db2_bind_package, db2_bind_package, ims_mfsutl, and ims_olcutl are identical for an Ansible or a Python deployment.
  • Migrated data sets are managed in the member_archive, member_copy, member_delete, and member_restore building blocks. Before the data set is accessed to archive, copy, delete, or restore some artifacts, a control is done to check whether the PDS that the building block applies to has been migrated.
    If such is the case, then an HRECALL TSO command is run to make the PDS available.
    To run the HRECALL command, you must indicate the following variables in the artifact type of your environment variables file:

    • recall and its embedded variables for the PDS
    • recall_back and its embedded variables for the backup PDS for member_archive and member_restore

    If these variables are not set in the environment variables file, then the HRECALL command is not run.
  • A new wd_deploy_annotations environment variable can be declared. The value (or values) of this variable is displayed in the annotations of the evidence file, under a new deploy sublevel. For more information, see wd_deploy_annotations.
  • Shortcuts are now available in the conditional deployment to create simple queries that directly reference the structure of the evidence files. For more information, see evidences in the conditional deployment.
  • Wazi Deploy MCP tools have been added to support listing deployments, environments, and artifacts, including their corresponding query definitions. These tools provide detailed metadata such as timestamps, evidence file paths, application names and versions, environments, package paths, deployed artifacts, and status. Overall, they enhance the visibility and traceability of deployments. To know how to configure and use the tools with your AI agent, see Agent Mode in the IBM Developer for z/OS on VS Code documentation.

Interim fix 3.0.6.1

Version 3.0.6

• The rescue deployment instruction can be inserted at the root level of the deployment method. For more information, see The deployment method.
• A new beginAt argument can be specified on the deployment command to begin the deployment at a specific activity, action, or step. For more information, see The Ansible deployment command or The Python deployment command.
• For a Python deployment, you can add your own Jinja2 filters and use them in Jinja2 templates or in the z/OS environment. By default, filters are searched for in the filters folder of the current working folder but you can change this default by setting the DEPLOY_FILTERS_PATH environment variable just before the invocation of the wazideploy-deploy command. For more information, see The Python deployment command.
• In The Wazi Deploy packager command and The Wazi Deploy generation command commands, if you specify the --workingFolder argument without entering the --logConfigFile argument, the log file (message.log by default) is generated to the path indicated in --workingFolder instead of the current folder.
• The --configFile argument of the Wazi Deploy commands is no longer required in the following cases:
  • It is not required in The Wazi Deploy generation command if the path that is indicated in the --packageInputFiles argument represents a network URI that does not require authentication.
  • If the artifact repository requires authentication, you can enter the credentials in environment variables instead of entering them in a configuration file that you pass as an argument to the The Wazi Deploy packager command or The Wazi Deploy generation command.
• The Wazi Deploy building blocks have been enhanced:
  • Two new restore building blocks are available. For more information, see sequential_restore and uss_restore.
  • The new group and owner variables can be used to specify who owns the objects of the z/OS UNIX System Service directory. For more information, see uss_archive and uss_copy.
  • For the Ansible and Python deployments, the performances of the use_native_copy copy option have been greatly improved in the member_archive, member_copy, and member_restore building blocks.
  • For a Python deployment, the force_lock variable can be used in conjunction with the is_asa_text variable in the member_archive, member_copy, and member_restore building blocks.
  • For a Python deployment, the new is_record variable is available to manage the artifact type that corresponds to a record generated by the IPVLANGX program. For more information, see the Python variables in the member_archive, member_copy, and member_restore building blocks.
  • For a Python deployment, you can include Jinja2 templates in Jinja2 templates by entering {% include "myj2tobeincluded.j2" %} in some building blocks. You must then use the new search_paths variable to specify the paths where the included Jinja2 templates are stored. For more information, see db2_bind_package, db2_bind_plan, ims_mfsutl, ims_olcutl, job_submit, shell_command, template, and tso_command.
• A tutorial is available to show you how to use Wazi Deploy to deploy z/OS Connect APIs on z/OS. For more information, see Deploying z/OS Connect APIs with Wazi Deploy.

Interim fix 3.0.5.2

• For a Python deployment, the use_native_copy copy option can be used in conjunction with force_lock in the member_archive, member_copy, and member_restore building blocks.

Version 3.0.5

• A new wd_evidence_filename argument is available on the Ansible deployment command to specify the evidence file name or path. For more information, see The Ansible deployment command.
• A new --archiveName argument is available on the packager command to specify the name of the archive file, only if the upload type (--uploadType) is set to archive. For more information, see The Wazi Deploy packager command.
• You now have access to the Wazi Deploy YAML schemas to validate the structure of the configuration files, deployment method files, and manifest files. For more information, see Wazi Deploy YAML schemas.
• New building blocks related to the management of Generation Data Group (GDG) files are now available:
  • The gdg_archive building block copies artifacts from a GDG file to a backup GDG file. For more information, see gdg_archive.
  • The gdg_copy building block copies artifacts to a GDG file. For more information, see gdg_copy.
  • The gdg_delete building block deletes Generation Data Group (GDG) files and their active Generation Data Sets (GDS). For more information, see gdg_delete.
  • The gdg_restore building block copies artifacts from a backup GDG file to a GDG file. For more information, see gdg_restore.
• A new ims_ddl building block is available. It submits Data Definition Language (DDL) SQL statements. For more information, see ims_ddl.
• The existing Wazi Deploy building blocks have been enhanced:
  • The shell_command building block can now also run shell commands that are written in a Jinja2 template or a .sh file. For more information, see shell_command.
  • The tso_command building blocks can now also run TSO commands that are written in a Jinja2 template or a file. For more information, see tso_command.
  • The template building block has a new delegate variable in Ansible. This variable is related to the dest variable. It indicates whether the path in the dest variable refers to the Ansible controller or the z/OS environment. For more information, see template.
  • The http_request building block has a new delegate variable, which indicates whether the shell command is to run on the local host or on the z/OS environment. For more information, see http_request.
  • A new create_pds variable can be used in the member_copy building block. If this variable is set to False, the PDS creation is skipped. The default value is True.

Version 3.0.4

• In the wazideploy-package command, the static value of --uploadType is renamed folder. Now, the default value for --uploadType is archive. If you use this default value to upload to Artifactory, you can omit the --buildName and --buildNumber arguments. In this case, no Artifactory Build Info is created. For more information, see The Wazi Deploy packager command.
• Controls are automatically run before the deployment starts. If some controls fail, the deployment is not triggered. For more information, see Checks before the deployment for a deployment with the Ansible translator and see Check before the deployment for a deployment with the Python translator.
• The Python deployment command has been enhanced:
  • You can pass extraVars in a YAML file. For more information, see extraVars.
  • You can add your own Jinja2 filters to the command. For more information, see Create custom Jinja2 filters.
• A new rescue deployment instruction is available. Use this instruction to go to a target activity, action, or step if an exception occurs during the current activity, action, or step. No condition is to be indicated. For more information, see Syntax of the conditional deployment. To understand how conditional deployment works, see Getting started with conditional deployment.
• Wazi Deploy comes with a set of predefined queries and renderers that you can use to quickly generate reports in an HTML or a YAML format. For more information, see The predefined queries in the product.
• The Wazi Deploy building blocks have been enhanced:
  • An http_request building block is available. It interacts with HTTP and HTTPS web services and supports Digest, Basic and WSSE HTTP authentication mechanisms. For more information, see http_request.
  • The force_lock variable in the member_archive, member_copy, and member_restore building blocks is now effective for Python.
• The evidence file has been enhanced:
  • A runtime_context level is generated in the metadata annotations. For Ansible, this level displays the IBM Z Open Automation Utilities (ZOAU) version, the versions of the Ansible collections, and the generic environment variables. For Python, it displays the IBM Z Open Automation Utilities (ZOAU) version. For more information, see runtime_context.
  • A filtered_artifacts level is generated inside the steps level of the evidence file if deployment filters have been indicated in the deployment method. For more information, see The artifacts and filtered_artifacts levels.
  • A jumps_to level and a jumped_from level are generated when a jumps_when instruction is indicated in the deployment method and when one of the conditions is True. The same information is generated when the rescue instruction is run during the deployment. For more information about conditional deployment, see Syntax of the conditional deployment.
  • The password defined by the cmci_password variable in a CICS® building block is masked and replaced with asterisks in the generated evidence file.
  For more information on the evidence file, see The evidence file.
• The deployment analysis has been simplified, as only the notion of query has been kept. The notion of template has been replaced with the notion of parameterized query. See the consequences of this evolution. To understand how the deployment analysis works, see Getting started with the analysis of the deployment results.

Version 3.0.3

• The installation process has been simplified. The distribution of the installation binary files includes all the prerequisites for running Wazi Deploy. No internet connection is required anymore.
• You can now create a package locally with the Wazi Deploy packager command (wazideploy-package). For an example of how to create a local package, see the example provided in the packager command.
• Some options of The Python deployment command command have changed. You must now indicate the absolute path to the package file and the environment file.
• This version introduces the conditional deployment. You can set the following conditions on an activity, an action, or a step of the deployment method:
  • loop to iteratively run the activity, action, or step
  • when to run the activity, action, or step only if the condition returns True
  • failed_when to set the status of the current activity, action, or step result to Failed or Successful if the condition is met
  • jumps_when to run a specified activity, action, or step after the current activity, action, or step if the condition is met
  For more information, see Syntax of the conditional deployment.
• You can indicate filters to include or exclude artifacts in the deployment phase. You indicate these filters on the deployment command or in the environment variables file. For more information, see Deployment filters.
• The Wazi Deploy API is available as Python functions or Ansible modules. This API constitutes an alternative to the Wazi Deploy command-line interface. You can use it to run the various phases of the Wazi Deploy deployment.
• The following enhancements are available on the building blocks:
  • When you create a building block, you can reference the content of the evidences. This content corresponds to the state of the evidences at the beginning of the building block execution. To reference the content of the evidences in the building block, use the following elements:
    • The wd_evidences variable in Ansible. For more information, see Creating an Ansible building block.
    • The evidences argument in the Python process method. For more information, see Creating a Python building block.
  • The include_vars building block is now available for Python.
  • A new timeout variable can be used in the cics_cmci_prog_create, cics_cmci_prog_delete, and cics_cmci_prog_update building blocks.
  • A new use_native_copy variable can be used in the member_archive, member_copy, and member_restore building blocks. If this variable is set to True, the copy step is faster because it uses the native UNIX System Services shell cp command instead of IBM Z Open Automation Utilities (ZOAU). However, it has fewer capabilities.
• The structure of The evidence file contains the following enhancements:
  • The status of an activity, an action, or a step is set to skipped if this activity, action, or step was excluded from the deployment or was not run because of a specified condition.
  • A loop_index field is generated if a loop condition is specified in the deployment method.
  • An args field lists the arguments of each step. It is always present in the Python evidence file. In the Ansible evidence file, it is present only if the step calls an Ansible module.
• Some structures of the environment variables file has changed for the include_vars building block. Deprecation messages are displayed but the upward compatibility is ensured.

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 environment.
  • 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