The segregation of build and deployment is a crucial principle in today’s DevSecOps practices. This puts the deployment tool on the spot to maintain the inventory of deployed artifacts in the runtime environments and document any past deployment activities.

To support these new workflows, the deployment tool must provide the capability to generate reports for  different type of queries, like the following examples

• A tester or release manager wants to understand and verify which version of an application is currently deployed to the test environment,
• A developer wants to understand the current released version in a troubleshooting situation of an application module that is not behaving correctly in either a test or a production runtime,
• An operations specialist requires information about the last deployment timestamp of a specific module, which terminated in the batch processing window.
• An auditor needs to know which version of a given application was deployed in production a year ago

Many more situations can occur that require information about what was deployed, when it was deployed and by whom.

In this blog post, we are demonstrating the traceability of deployed artifacts using the Wazi Deploy inventory analysis. Let’s get started.

First, we need to add the breadcrumbs into the deployment package to know where the contents of the package are originating from. Wazi Deploy provides a standard manifest file schema for this: the application manifest file. You can find more information in the Wazi Deploy documentation. Don’t panic! You don’t have to handcraft the application manifest file for each package.

We have enabled the PackageBuildOutputs script to automatically generate the wazideploy_manifest.yml file for you. It adds information about the Git repository, the application, the package name and the Git commit. For COBOL load modules, it is also collecting information about the included dependencies.

artifacts:
- name: "EBUD0RUN"
  description: "retirementCalculator/cobol/EBUD0RUN.cbl"
  properties:
  - key: "path"
    value: "bin/LOAD/EBUD0RUN.LOAD"
  - key: "githash"
    value: "29db761deaf8b7a7f9e7fccd6ce23e906e04786c"
  - key: "giturl"
    value: "git@ssh.dev.azure.com:v3/IBM-DAT/retirementCalculator/retirementCalculator"
  - key: "dependency_set"
    value:
    - lname: "LINPUT"
      library: "SYSLIB"
      category: "COPY"
      collection: null
      sourceDir: "/u/ado/workspace/retirementCalculator/feature/13-enable-artifactory-upload/build-20240909.17/retirementCalculator/"
      file: "retirementCalculator/copy/LINPUT.cpy"
      archive: null
      resolved: true
      excluded: false
    - lname: "EBUD0RUN"
      library: "ADO.RETIREME.F13.OBJ"
      category: "LINK"
      collection: null
      sourceDir: null
      file: "ADO.RETIREME.F13.OBJ(EBUD0RUN)"
      archive: null
      resolved: true
      excluded: false
  type: "LOAD"
  hash: "29db761deaf8b7a7f9e7fccd6ce23e906e04786c"

During the deployment of the package, IBM Wazi Deploy collects this information and persists it in the Evidence file. What is the Evidence file? This file is documenting all the actions performed during deployment and their results, such as the extraction and the copy of package contents to the target libraries, and the performed activation steps (like CICS NEWCOPY and DB2 binds) - including the application manifest metadata. 

We have enabled our pipeline to store these files to an external filesystem. In our demo system with GitLab and a distributed shell runner, we not only pull the Evidence files to attach them to the build run, but we also copy the Evidence file to a specific location on a Linux machine, where a collection of Wazi Deploy Evidence files is built up. Checkout our published GitLab template at the public DBB Community repository to get a grasp of it capabilities.

With our pipelines building up this inventory of the YAML files, we also index the information across all applications and runtime environments, to create a knowledge base that can be easily queried using Wazi Deploy queries. We have chosen the this directory structure for persisting the Wazi Deploy Evidence files: <application>/<environment> /evidence-<buildId>.yaml and enabled our pipelines to build up a single Wazi Deploy Evidence index automatically.

The pipeline submits a query against the Wazi Deploy Evidence index and generates a report with the supplied query criteria. The report includes important traceability information like the date of the deployment, the deployed revision and information about the Git Commit and the performed actions. In the below table you find all the references for the INQACC part - a CICS and a DBRM module.

To understand the implemented changes for a given element, the user then switches to git and checks the Git repository of the application. In our demo environment using GitLab, we search for all references for the commit, or as an even better approach the version reference (“rel-1.2.0” in the above screenshot). We find the corresponding Git tags and pipeline references which include this commit, the author of the commit and many more information.

Curious about how the data is retrieved from the Wazi Deploy Evidence Index?

Here are some pointers the Wazi Deploy deployment analysis. The Wazi Deploy evidence command is used for both indexing and querying. The query template is described in YAML (see below sample) and allows to look up and select the data that can be rendered into the report. The HTML report is then provided by the renderer capability of Wazi Deploy and can be customised to your corporate standards including logos, stylesheets etc.

select:
  name: '{{module}}'
  ymli_category~: ^ activities:[0-9]* actions:[0-9]* steps:[0-9]* artifacts:[0-9]* $
  ymli_parent:
    metadata:
        annotations:
            environment_name: '{{env}}' 
    manifests:
        name: '{{app}}'
  properties:
    key: type
    value: '{{type}}'
output:
  #limit: 1
  format: 
    sort_keys: true
  fields:
    # element name is the third sort criteria
    name: 3
    properties:
      key: true
      value:
        lname: true
        library: true
        category: true
        file: true
        resolved: true
        excluded: true
    ymli_parent:
      name: true
      step_result:
        status: true
      ymli_parent:
        ymli_parent:
          ymli_parent:
                manifests: 
                    # application name is the second sort criteria
                    name: 2
                    description: true
                    version: true
                    annotations:
                        scmInfo:
                            uri: true
                            shortCommit: true
                metadata:
                    annotations: 
                        creation_timestamp : true
                        # environment is the firt sort criteria
                        environment_name: 1
                        # last sort criteria. Reverse sort of timestamps
                        deploy_timestamp: -4
renderer: {{renderer}}

This article showcased the capabilities of the Wazi Deploy Evidence command and it's deployment analysis capabilities, including how users can execute queries from the GitLab DevOps platform.