Solution-level release testing
Catch the cross-product break before GA, on a schedule, without hand-writing a pipeline.
A value-stream product/QA engineer whose PTF just passed product tests
The trigger. “My change passed product tests. Prove it doesn’t break the whole solution before it ships.”
The old way
Testing happens only at the product level. There is no repeatable, consistent way to test the integrated solution, so defects escape as PTFs-in-Error and reach customers. Building the solution test by hand means authoring a Jenkins pipeline along with ART CLI/REST calls, provisioning a zVDT, applying the day’s HOLDDATA, running the e2e suite, reading results off a portal, and tearing the instance down. Then you repeat all of it for each ESM (RACF/TSS/ACF2). The know-how lives in one person’s Groovy.
The Flow way
The ART loop becomes one visual flow that runs on a nightly schedule.
Cron (6pm EST) → Provision zVDT (Action: ART CLI/REST) → fork per ESM
[RACF / TSS / ACF2] → Apply HOLDDATA + post-provision config (Zowe / Action) →
Run solution e2e suite (Action / Jenkins) → Publish results (Action: portal API)
→ on pass: Delete zVDT; on fail: Snapshot zVDT + Notify VS (Google Chat) +
Raise defect (Rally)
The ESM fork is a set of parallel branches. Every branch posts its results to the same dashboard. The instance deletes itself when the run passes, and it is snapshotted when the run fails so you can find the root cause. To test the next solution, you clone the flow instead of copy-pasting a pipeline.
Payoff
| Old way | Flow way | |
|---|---|---|
| Defect caught at | Customer (PTF-in-Error) | Solution test, pre-GA |
| Building the test | Hand-rolled Jenkins + CLI | Clone a visual flow |
| Per-ESM coverage | Repeat by hand | One fork, runs in parallel |
| Teardown / RCA | Manual | Auto-delete on pass; snapshot on fail |