Categories: DEVELOPER GUIDE CI CD DEV OPS ENTERPRISE

Automation Packages Multi-version support

Overview

Step allows deploying multiple versions of the same Automation Package on a single Step instance. This is particularly useful when your system under test (SUT) exists in several versions across different environments (e.g., TEST, QA, PROD), each requiring a matching version of the automation code.

Multi-version support enables:

  • several versions of the same package to coexist
  • automatic version selection at runtime
  • consistent usage of keywords and plans from the selected version
  • clear and predictable behavior across environments

Step determines the correct version using activation expressions associated with each deployment.

Package Identity

Each Automation Package is uniquely identified by the pair: (package name, versionName). This means you can deploy:

my-package v1.0
my-package v2.0
my-package v3.0-TEST

…all on the same Step instance, without conflict.

How Step Selects the Correct Version

  1. Self-contained execution

If the execution is triggered for a plan of a specific package, Step automatically uses the:

  • version of the package that the plan belongs to
  • all subplans and keywords from the same version

You do not need an activation expression for this scenario.

  1. Cross Automation Package execution

If the execution is triggered for a plan that calls entities part of another versioned Automation Package, Step must decide which version of the package to use.

In this scenario:

  • the activation expression is required
  • Step evaluates the expression using the execution context (e.g., execution parameters)
  • the version whose expression matches is selected

Version selection examples

The table below shows how Step selects a package version based on activation expressions and the execution context.

Package Version (packageName.versionName) Activation Expression Example Execution Context Selected?
my-ap.PROD env == "PROD" env = "PROD" ✔ Yes
env = "TEST" ✘ No
—————————————— —————————————— ———————————————– ———–
my-ap.TEST env == "TEST" env = "TEST" ✔ Yes
env = "PROD" ✘ No

Best Practices

✔ Keep version names meaningful: for instance use environment or release identifiers:

  • TEST, QA, PROD
  • v1, v2, v3
  • R2024.02, R2024.03

✔ Ensure activation expressions are mutually exclusive: if two versions match the same execution context, Step cannot determine which one to use and will select one of them arbitrarily.

✔ Use self-contained plans inside Automation Packages whenever possible: this guarantees version consistency automatically.

✔ Use automation parameters as drivers; E.g., env, sutVersion, release, etc.

✔ Use semantic version numbers only if needed: Domain-based names (e.g., “PROD”) are usually clearer.

Summary

Multi-version support allows Step to host and run multiple versions of the same Automation Package. Version selection happens automatically based on:

  • the execution context
  • activation expressions
  • the plan’s origin (inside/outside the package)

This makes it easy to test multiple SUT versions in parallel and maintain clean, predictable automation logic.

See Also