Automation Script Test Harness · For operations

Four stages, one harness: build, merge, deploy, and the next upgrade.

One script. One lens list. One graded verdict. The same run answers a different question depending on when you ask it. Nothing below is a different product — it is the same CLI, pointed at a different moment.

This page is the DevOps side: gatekeeping what gets merged, across every lens the org runs. If you are one developer fixing one script against one version, that is the day-to-day case on the harness page — you do not need everything below for that.

Build time

Run the harness against your working copy before you commit. Same feedback loop unit tests give any other code. Today: mvn verify -P mas92 on a laptop, seconds, not a deployed Maximo.

Pre-merge (CI)

Gate the merge on every target lens your team supports. A script that only works on the lens the author tested never lands. Today: wire node bin/asz-harness.mjs script.js --lens mas91,mas92 into the CI step directly — real PASS/BLOCKING for JavaScript, exit code 1 on a block. mvn verify covers Jython too.

Deploy / promotion

Environments are not always the same Maximo/MAS release. Rerun against the target environment's own lens before a script crosses that boundary. It catches a break the source environment could never show you. Today: point the CLI at the target lens's dictionary; capture one with maximo-stub capture if it is site-specific.

Ongoing (upgrade watch)

IBM ships a new MAS release. Rerun the whole script library against the new lens before anyone plans the upgrade. An early-warning pass, not the full MXH system assessment. Today: add the new lens's dictionary and rerun the same suite.

Who owns what

Build-time and pre-merge runs belong to whoever wrote the script. Deploy-time and upgrade-watch runs belong to whoever owns the environment or the upgrade programme. Every grade is graded the same way regardless of who runs it — the same rule MXH's own operations page runs on.