Skip to content

Development Workflow

  1. A code change has been identified as a task in an agile planning tool. This drives the creation of a simple package in ZMF.

  2. Source members can then be checked out from the base line into a specific package. This could be driven from an IDE task initiated by a developer or as part of an automated process.

  3. For any given package there is a need to:

    1. Get a member list of the package with filters on source type as an option.

    2. Get the actual source member or members from the package.

    3. Get build meta-data for a particular member or members.

  4. When any components from a package are committed back to ZMF (Check in) an event is triggered which could be used by any tool which is part of a distributed orchestration.

  5. For coding standards or security rules analysis when a component has been checked into ZMF then a workflow requests a component and all dependencies from a package. Source code would be delivered as part of the request and this could then be passed by an orchestration engine to a separate process for analysis.

  6. As part of a workflow or process initiated by a developer a component build can be requested. This will build the component on the mainframe based on the build metadata for the component. When the build has completed this triggers an event.

    1. The build status from a component build needs to available so that any errors in the build step can be returned to an IDE or to a distributed orchestration tool.

    2. This build process could be iterative based on the number of components in a package.

  7. On successful build the contents of a package can then be promoted which could then trigger automated testing.

    ...

  8. When a code change as part of a package has been tested then this can be associated to an existing ERO release.

...