The Wazi Deploy workflow

Edit online

Wazi Deploy creates the files that prepare the deployment of an application package that contains the artifacts of an application. To create these files, Wazi Deploy provides a packager command and a generation command. You can then deploy the application package to the z/OS® environment by using the Wazi Deploy Python or Ansible® translator, according to your deployment environment.

Wazi Deploy is constituted of the following parts:
  1. The core part, which contains the packager and the generation commands. They both must be run to produce the Wazi Deploy files that drive the deployment.
  2. The translators, which run Ansible or Python building blocks that deploy the application to the target z/OS deployment environment.
  3. The evidence requester, which analyzes the deployment process and result.

You can deploy an application to the target z/OS environment from a z/OS environment. You can also deploy an application from a distributed environment and transfer the deployment result to the target z/OS environment through the SSH protocol.

For a direct deployment from a z/OS environment, the input and output files are conveyed between the various deployment stages through the z/OS UNIX file system. For an indirect deployment from a distributed environment, the files are conveyed through the UNIX file system.

First steps in the workflow of a static deployment

The following diagram illustrates the Wazi Deploy workflow for a static deployment.

Figure 1. Wazi Deploy workflow for a static deployment
Wazi Deploy workflow for a static deployment
The workflow for a static deployment is as follows:
  1. Create a package (a .tar archive file) from a local folder that contains the artifacts of an application. To do so, complete the following steps:
    1. Create a local folder that represents your application.
    2. Run a z/OS build by using IBM® Dependency Based Build or any build process from your organization. This build populates the local folder with the application artifacts.
    3. Create a package file by running one of the following commands:
      • The Wazi Deploy packager command (with the uploadType argument set to archive). The package is then automatically created and uploaded to an artifact repository.

        This command also produces the application manifest file (a YAML file), which lists all the artifacts of the application with their names, types, paths, fingerprints, and hash codes. This file is optional for a static deployment.

      • An enterprise build framework. Make sure that the package contains the file extensions to be deployed. You can upload the package to an artifact repository.
      Note:

      To create a package .tar file, you can also use IBM Dependency Based Build (DBB) and zAppBuild as the build manager. In this case, you run the PackageBuildOutputs Groovy script and provide the --addExtension (-ae) argument.

  2. Create The deployment method (a YAML file), which must conform to a model provided. This method describes all the actions and steps that must be completed by the deployment. For example, the deployment of a CICS® Db2® application involves CopyToPDS, BIND, and NewCopy.
  3. Run The Wazi Deploy generation command with the package and the deployment method as input.
The generation command produces the following output files to prepare the deployment to the target z/OS environment:
  • The package file, which is the package file that you provided as input.
  • The deployment plan (a YAML file), which retrieves the actions and steps from the deployment method and applies them to the artifacts to be deployed. The deployment plan drives the deployment. Along with the deployment plan, a deployment report (an HTML file) is generated if you specify it in the generation command.

The next phase in the workflow is the deployment of the application to the target z/OS environment. See Deploying the application to the target z/OS environment.

Deploying the application to the target z/OS environment

The last step in the Wazi Deploy workflow is the deployment of the application to the target z/OS environment.

This step is run by a Wazi Deploy translator. Run the Python translator if you deploy to the target z/OS environment directly from a z/OS environment. Run the Ansible translator if you deploy from a distributed environment and use the SSH protocol to deploy to the target z/OS environment.

The translators run the steps of the generated deployment plan as a guide. Each step is implemented by a building block, which corresponds to a Python module or an Ansible playbook. You can use the standard building blocks. However, if you are an enterprise architect, you can also create building blocks to tailor the deployment to your company needs.

The building blocks use variables that are indicated in an environment variables file. The content of this file differs in a Python or an Ansible deployment.

For more information, see The Wazi Deploy Ansible and Python translators.

Analyzing what was deployed

When the steps of a deployment plan are run, the Ansible or Python building blocks that implement these steps collect the produced evidences. For example, the name of a new CICS program is collected when the step that creates a CICS program runs.

The building blocks collect the evidences in an evidence file, which you can use to query the deployment process and results.

When the deployment is complete, you can analyze the Wazi Deploy deployment process and target deployment environment to create reports.

See Getting started with the analysis of the deployment results.