Using scripts and pipelines to adapt configurations means writing and maintaining code against IAM configurations. In particular, such code will rely on the format, IDs, property, and plugin type names to be stable.
- To support reliable automation, Airlock IAM makes the following commitments regarding the YAML configuration files:
- Limited backward compatibility
Breaking changes to the configuration format and structure between minor releases are minimized (but not completely eliminated). - Change documentation:
Any necessary modifications to the configuration when upgrading to an IAM minor version will be documented in the release notes. - Validation CLI tool:
We provide a CLI to validate configurations before deployment, reducing the risk of runtime errors.
The guarantees apply to the config format (YAML), plugin type names, property names, and property values.
- Limitations:
- The above-mentioned commitments only apply to the YAML config format and not to the XML config format.
- Manual changes to code manipulating the configuration may be required when upgrading to a minor release (e.g. 8.4 to 8.5).
- The above-mentioned commitments hold for minor releases but not for major releases. See also Semantic versioning scheme for Airlock Secure Access Hub components.
- Short plugin identifier names are available as of IAM 8.5. Fully-qualified plugin type identifiers - as required in IAM 8.4 - may have to be replaced by short ones to minimize the need for manual adaptations.
Upgrading without changing config code
If upgrading IAM to a minor version without using new features, the following upgrade path may eliminate the need to adapt config automation code:
- When upgrading from version
x.a
to x.b
: - Keep the config automation code that produces a configuration valid for version
x.a
. - Use the
iam upgrade
CLI command in the config automation code to upgrade the resulting configuration to x.b
before deploying it.
In most cases, the iam upgrade
command does not require interaction.