Configuration Management Improvements

Summary

Change packages support data governance by allowing configuration management across environments in a Development, Test, Acceptance, and Production (DTAP) environment, and can be used alone or in conjunction with an integration to Git for version control. With 2023.3 (11.3), both change packages and the Git integration have been updated to begin to provide a more holistic solution for managing configuration changes across environments. The improvements that have been made as part of the 2023.3 (11.3) release are outlined below and are described in the Details section that follows.

  • Support for additional types of objects in change packages lessens the manual configuration required in target systems. Additionally, security while creating users for processes is now improved with a system-generated user password.

  • Automated transfer functionality between systems and to an external version control system (VCS) reduces the manual work that was previously required. Change packages and their included objects now include text fields to communicate instructions for target system installation. This is especially useful in cases where the configuration is not fully supported in change packages to provide a single source of truth or 'checklist' for the full set of changes.

  • Change packages are now supported in the external VCS integration so administrators can segregate sets of changes in a dynamic folder structure using a template, supporting multiple deliveries within one branch instead of replacing everything in the branch with each update.

  • Improved usability when creating, analyzing, sealing, importing, and installing change packages minimizes errors and makes change packages easier and more reliable to work with. Dependent-object analysis is also optimized for relevancy, and a new default handling mode provides users with complete control of the configuration objects to be installed.

These improvements streamline the management of configurations across environments for STEP developers and administrators. Customers can expect additional improvements in the overall configuration management solution over the next several releases.

Explore further by clicking the video below. If it does not play as expected, it is also available in the Customer / Partner Communities and may also be accessible within Stibo Systems Service Portal. For details on this project, review the 'Details' section below the video.

 

Details

Additional types of objects supported in change packages

Creating a change package on a source system now supports many additional types of objects from both the System Setup and Tree tabs, including individual hierarchy nodes, import / export configurations, collections, and other data objects that often serve configuration functions. This improvement increases the number of configuration items that can be transferred via change packages and streamlines overall configuration management operations.

In addition, users created via change packages, for example, for integration endpoints or event processors being transferred, are assigned a system-generated password upon installation on the target system. When passwords are managed in STEP, the 'Forgot Password' option on the Web UI login page provides password reset, or an administrator can assist the password changes in workbench. If passwords are managed in an external identity provider, it is not necessary to reset the password in STEP.

For information on all types of objects available for change packages, refer to the Change Packages section in the Configuration Management documentation.

Automated transfer functionality

To reduce the manual work previously associated with change packages:

  • Sealing a change package (which indicates it is ready for export) now generates an event. The change package event provides a way to automate data exchange between a source system and a target system using event-based integration endpoints. Additionally, an OIEP can be set up to export the change package contents to a VCS in STEPXML format. Working with a VCS allows for the tracking and comparing of different versions of the same change package, the option to edit business rules externally from STEP, and provides a consistent way to define changes for automated system-to-system transfer.

  • Teams working on different projects or domains can use custom attributes on the change package to organize them within a repository branch, automatically using a directory template and macros for key aspects of the change package. For example, change package ID or the system where the change package was sealed and/or originated could be used to identify the data on the repository branch. Below the change package, the Primary and Secondary flipper grouping (visible in workbench) is maintained. Subfolders for different objects improve the organization of STEPXML files, grouping them by type. This allows administrators to avoid overwrites by exporting subsets of the configuration independently, without needing to export the entire configuration.

  • On a target system, change packages can be automatically imported via a REST-based integration endpoint (IIEP) to directly receive change packages from an upstream system, or to directly update objects from a VCS in STEPXML format.

  • The Change Package Git Delivery method allows integration with popular repositories, supporting the HTTPS (token-based) or the SSH (file-based) access methods for GitHub, GitLab, and Bitbucket. The delivery option now toggles access to the appropriate fields when either HTTPS or SSH is selected for the access method, making the required and irrelevant fields clear.

For information on the available automated transfer functionality, refer to the Configuration Management topic, the Version Control System Integration section, and the Change Packages topic, all in the Configuration Management documentation.

Change package usability improvements

These change package improvements allow users to control an installation by explicitly choosing which items to include, while using the remaining items for impact analysis. This full control ensures reliable transfers without unintended objects being installed.

  • Creating and modifying change packages include new ‘drag and drop,' multi-select, and filtering functionality.

  • The 'Items Required for Transfer' list and the 'Possibly Impacted Items' list have new functionality for promoting items to the ‘Primary Items’ list and show fewer distantly related objects.

  • Default handling now only includes objects explicitly selected by the user, with dependent objects noted for impact analysis but not installed when transferred.

  • The dependent-object analysis used to determine the items on the 'Items Required for Transfer' list and the 'Possibly Impacted Items' list now includes significantly fewer objects. This means that reviewing the list of dependencies requires less effort and that the file size for a new change package is smaller. Updating items in an existing change package recalculates the dependencies, which also results in a smaller file size.

  • On the target system, some items require manual configuration once installed. To communicate notes for installation, on the source system, each object added to the change package can now have a user-defined instruction attribute that is transferred with the change package. The ability to add objects without supported installation, along with the new instruction attribute eliminates the need for an external document to describe manual changes necessary to support the installation process.

  • User-defined description attributes can be added to change package object types to communicate information relevant to the entire change package, like general instructions or prerequisites. These description attributes can also be used when integrating with a version control system (VCS), like GitLab, GitHub or Bitbucket, to automate a consistent folder structure within a branch of a repository.

  • The STEPXML splitter post-processor used with an OIEP integration to a VCS has been changed. It no longer replaces the entire content of a repository branch with the current set of files where the objects were included from a collection. Instead, change packages are used to house configuration changes for a feature set and many change packages can be exported to the VCS branch over time. The branch can automatically have sub directories built using a template with macros to generate the organizational structure, with the change package ID at the end of the path template, storing all of the change packages. STEPXML and JSON files are contained within the change packages, and are grouped by the Primary and Secondary flippers, then by type of object. These files do not contain the context and workspace, however, they can be added manually for ad-hoc imports or can ideally be used with an IIEP where the context and workspace can be defined for imports. When using the new features in 2023.3, consider creating a new branch in the repository.

For more information, refer to the topics within the Change Packages section and the Version Control System Integration section in the Configuration Management documentation.