Guidelines on configuration data movement

The basic guidelines and rules to follow for configuration data movement while working with multiple cloud and developer toolkit environments.

• The Master-Config cloud environment acts as the configuration source of truth for all environments. Configuration is authored here and must be moved by using the Configuration Deployment Tool (CDT) only from here to other cloud environments, and not vice-versa.
• After upgrading the application, do not import the CDT on the authoring environment (MC) from the older version.
• If any adhoc configuration needs to be made live on Production environment, it must first be made on Master-Config environment, verified on Pre-Production environment, and only then made live on Production environment. Such configurations must be manually reconciled into lower cloud environments.
• Developer toolkit environments are local environments extracted from cloud environments which an SI can setup. They are mainly extracted from (but not restricted to) Integration cloud environment.
  • They do not author configurations. For them, their parent cloud environment must be the authoring environment for configurations.
  • Configuration data must never be moved from developer toolkit environments to cloud (only exception is for customers using BOPIS Deployment Accelerator for first time when they are loading the BOPIS Deployment Accelerator onto the cloud).
• If a customer has enhanced development/testing needs (simultaneous parallel development on multiple versions, different POC projects, and so on) which are not being satisfied by a single set of Integration/QA cloud environments, they can choose to buy additional cloud sandbox environments.
  • Whenever delta configurations are made on such environments, they must be manually merged on the Master-Config environment.
• An Order Management implementer (SI) should not modify the application-provided configurations like Agent Criteria, Flows and Conditions.
  • The application-provided Agent criteria is a sample configuration, it belongs to the product and it may change across releases. The sample configuration is a way to expose the new parameters added for the agent.
  • The application-provided Services are published and their behaviour is documented. An SI should not modify these services. Additionally, their behaviour may be enhanced over the releases and documentation would be updated accordingly.
  • The application-provided Conditions are also published and their behaviour is documented. Their behaviour may be enhanced over the releases. Additionally, an application-provided Condition may be used in some application-provided Services and Event handlers. Therefore, altering a condition could fail such services and event handlers.

  Instead, an SI must create a new component by looking at the application-provided configuration. The Applications Manager provides a 'Save As' option as well. By using this option, the SI can easily duplicate a component and use it in the required configuration.