Configuration Management¶

Configuration is one of the ways to tailor an IFS Cloud solution (Refer to the Tailoring Lifecycle of the Technical Documentation for IFS Cloud). While this page discusses the lifecycle management of configurations in particular, there is also the General Guidance on Lifecycle Management of Tailorings mentioned in the Technical Documentation.

Configurations have an inner and an outer lifecycle:

The inner lifecycle is how a configuration is managed within a single environment. How it is created (often in a draft state) and then made active (published) for all users or a group of users depending on the configuration context.
The outer lifecycle is about how a configuration moves between environments, on its own or together with other tailorings such as customizations.

This page is about the outer lifecycle for configurations. The inner lifecycle is described for each configuration type individually.

Overview¶

The configuration outer lifecycle flow is based on these principles:

Configurations are done (created, updated) in DEV (build place) or CFG (use place) environments
Configurations are stored in the customer solution repository for safekeeping so that the repository will always contain the latest and correct version of configurations and thus there is no need to store configurations separately anywhere else.
Configurations are promoted to UAT and PROD by manually importing them into those environments after the delivery (containing update to core or customizations) on which they depend as been applied to UAT and PROD respectively.

The configuration outer lifecycle flow is illustrated in the below picture.

Configuration Lifecycle Flow

Configurations are recommended to be created in the CFG use place environment (1a), but it is also possible to create them in a DEV environment in the build place (1b). Which one to choose depends on the type of configurations. While some configurations such as custom entities and custom attributes are easily created and tested in either location, other configurations such as Workflows, Queries and Lobbies may be difficult to design and test/validate without having a full copy of the data from PROD.
Configurations are exported and committed as individual exported items, or exploded Application Configuration Packages to the /nobuild/appconfig/<acp name> folder on a topic branch in the customer solution repository. This applies also to configurations (e.g. lobby elements and pages) that are not part of ACPs. Make sure you know which component and folder to use for storing them.

If multiple configurations and/or customizations are needed together to implement a wanted feature in the customer solution, then they are done on the same topic branch, and then merged into the master branch with a single pull request. That way all the things that are need for this feature of the customer solution are promoted through the lifecycle together.

(optional) Manually import the configuration into UAT if needed for final testing/approval. Not shown in the illustration above.
Promote the configurations along with any other work done on the topic branch to master using the pull request process.
Order and apply a delivery which includes the target commit that contains the new/changed configurations and/or other items you want to promote into UAT and the PROD. This step can be skipped if the target commit only includes configuration changes (i.e. no code changes).
Manually import (Refer to Import Application Configuration Packages in Technical Documentation) the configurations into UAT after you have installed the delivery, so that any configurations that depend on customizations or other changes in the customization or core layers will work.
Do the same (apply the delivery and then manually import configurations) into PROD once testing in UAT is completed.

If for some reason at any time a configuration change is done directly in UAT or PROD, then export that configuration and commit to the customer solution repository, just like you would have done if it was created in CFG.

Handling Configurations in Release Updates¶

When applying release updates, which contain new and changed functionality, configurations will likely be impacted to some extent. Some release updates may also contain upgrade scripts for configuration metadata. This means that configuration metadata is upgraded by the installer in the same way and at the same installation step as application data.

- Make sure that the correct versions of configurations are deployed to the CFG** environment before the environment is updated.

- The delivery/deliveries used to update the environment should not contain configurations for “auto-installation” that could overwrite updated configurations.

*** The CFG environment is recommended for configuration handling. If the 'build place' or any other environment is used for this purpose, it is the environment.*

### Recommended Process

Make sure that the configuration handling environment contains the correct versions, i.e., the current version in the customer solution repository.
Follow the release update studio process to the point where the delivery containing the release update is applied in the CFG environment.
Analyze and resolve any impact on configurations in the CFG environment using provided tools and capabilities such as configuration impact analyzer, rebasing of page designs, and lobby impact analysis.
Export all configurations that have been changed because of the upgrade and store the changes in the customer solution repository.
Continue from step 2 in the overview process above, note that in step 5 the delivery in question is the delivery that contains the release update.

Including Configurations in Deliveries for automated application to DEV, UAT and PROD¶

The recommended approach described above relies on the manual import of configurations to UAT and PROD (and any other use place environments). It is also possible to place exported configurations in the server/appconfig folder to have them automatically imported as part of the application of a delivery to an environment. A benefit of this is that configurations will be automatically imported to new DEV environments created for topic branches, or to new environments used in the Release Update Studio. The downside of this approach is that you need to create and apply a delivery to promote configurations (e.g., to UAT and PROD environments), which takes longer (and requires a scheduled downtime window) than promoting configurations through manual import.

Consider this option for automated application of configurations when you have a lot of configurations that are "done" in the way that you are not actively changing them anymore.

A delivery that contains a “release update” and is requested for updating configuration handling environments, e.g., CFG, build place, should typically not include configurations. As explained in “Handling configurations in release updates”, release updates can include upgrade scripts for configuration metadata. This requires that the configurations to be upgraded is present in the environment before the environment is updated. Configurations part of the delivery is deployed in steps after that, the data has been upgraded and may overwrite previously upgraded configurations.

Analyze Impact on Configurations¶

It is highly recommended to maintain all the configurations in the customer solution repository in the Build Place and perform the impact analysis via Configuration Analyzer (Refer to Configuration Analyzer in Technical Documentation), Lobby Analyzer (Refer to IFS Lobby Analyzer in Technical Documentation), and Page Rebase Designer (Refer to Rebase Client Configuration in Technical Documentation).

In a delivery that includes changes from core and/or custom layers (e.g., Feature Updates / Service updates), in addition to configurations, configuration impact analysis is recommended to be performed at the build place before delivering to the Use Place.

But, when there are no other layer changes except configurations, impact analysis may be performed at the Use Place itself.

Nobuild or Server Folders¶

For configurations which are kept inside the customer solution repository but are not intended to be delivered via Build Place, the extracted content of ACPs should be committed to: <component>/nobuild/appconfig/<acp name>

Configurations such as Lobby pages and elements that are not part of ACPs and that you also want to manually promot/import to environments should be placed in their respective folders under <component>/nobuild folder.

For configurations which are to be included in deliveries (they become part of the delivery and are applied together with the delivery), the extracted content of ACPs should be committed to: <component>/server/appconfig

Configurations such as Lobby pages and elements that are not part of ACPs and that you also want to include in deliveries should be placed in their respective folders under <component>/nobuild folder.