Configuration Life Cycle

You must make all configurations and extensions, including the application extensions made using Visual Builder Studio, in a test environment. Then you migrate them to the production environment, which is the one you use for your everyday business.

You must never make these changes directly in the application instance you use for your business needs. This is very important because any incomplete, flawed, or invalidated configuration you make can disrupt your business.

You must create and enter a sandbox before you can start using configuration tools, such as Page Composer and Application Composer, to modify your application. Changes you make with these tools are stored in the sandbox as XML files. These changes are then merged with the mainline metadata when you publish your sandbox.

Note: Changes you make in one sandbox aren't available in the other sandbox. Also, if multiple users work on the same sandbox, then you must follow the prescribed guidelines to avoid conflicts within a sandbox.

A sandbox is optional if you're using Visual Builder Studio to modify your application. You should use a sandbox only if you require any changes to the underlying data model.

A flexfield sandbox is for testing only and can't be published. Instead, you can deploy a flexfield to the test environment using the flexfield UI. To test a flexfield configuration before you deploy it to the test environment, you must deploy it to a flexfield sandbox. The changes that you deploy to a sandbox are isolated from the test environment. Users who make the flexfield sandbox active in their session can only see your changes. After you're satisfied with the changes in the sandbox, you can deploy the changes to the test environment.

Here are a few typical configuration life cycle examples.

Application Configuration Using Configuration Tools

1. You configure the application in a sandbox.

2. You validate the changes in the sandbox.

3. The sandbox is published and deployed to a test environment.

4. Quality Assurance validates the whole environment after all configurations are completed and published.

5. Configurations are migrated from the test environment to the production environment.

Application Extension Using Visual Builder Studio

1. An application developer uses Visual Builder Studio to make application changes and shares the changes with other team members.

   Optionally, the application developer may use a sandbox to make changes to the underlying data model, which then need to be published along with the deployment of the application extension changes.

2. Team members review and approve the changes.

3. The reviewed and approved changes are merged with the mainline repository.

4. Once the application extension changes are merged, a build is triggered, and the changes are automatically deployed to a test environment.

5. Quality Assurance validates the whole environment after all extensions are deployed to a test environment.

6. Changes are migrated from the test environment to the production environment.