Before You Configure CSM Build Jobs and Pipelines

Here are some best practices to follow before you configure and run CSM build jobs and pipelines:

General Considerations

• Synchronize the source and target environments to ensure successful configuration migration:
• Always ensure that the source and target instances are of the same release, with the same standard and one-off patches applied to both instances.
• In the source instance, register the target instance. See Overview of Migration in Configuring and Extending Applications.
• Make sure that both the source and target instances are synchronized. To sync them, make application changes to the source instance, test the changes, then migrate them to the target instance.
• Create all configurations in the source instance, then migrate them to the target instance. Never create configurations directly on the target instance.
• Test all application changes and configurations that were made in the source instance before starting with the migration process.

• Ensure that the target instance doesn’t have any re-keyed configurations or ones that come from another source. If the source and target instances differ, re-provision the target instance from same common ancestor that provisioned the source instance.

  Note: If these guidelines aren’t closely adhered to, CSM Migration-related issues and Import/Export-related errors will be encountered. Also, in some instances, your source and target environments will be out of sync and you have to perform a P2T (Production-to-Test) operation to restore order to your environments.

• Always create new and unverified configurations in a sandbox. The migration process will only migrate configurations that have been created in a published sandbox.
• If you make configuration changes on a sandbox and don’t publish to mainline, the configuration changes won’t be included in the migration package.
• You should use CSM to migrate lookups and menu configurations, instead of existing Functional Setup Manager (FSM) tasks.
• Functional security artifacts for standard objects are not migrated.
  • If you migrate any functional security associated with roles in the source to a target instance, and the corresponding role doesn’t exist in the target instance, an error will occur on import.
  • To avoid these errors, you can selectively create these roles in the target instance when you import your migration set. See Export and Import of HCM Custom Roles and Security Profiles in Securing Applications.
• After you apply configurations, Oracle Cloud Application end users won’t see any changes to the user interface until they log out and log back in.

Delta Migration

• A normal migration flow migrates everything. Because this type of migration contains everything, it can be time-consuming. Think of it as an all-or-nothing proposition. A Delta Migration, on the other hand, only migrates what you’ve changed since the last time you migrated. By only migrating the latest set of changes, you can potentially save considerable execution time during the migration.
• Note that you can’t selectively pick and choose which of your latest changes should get migrated. Delta migration takes all of the changes since last time. Yes, you can select which modules you want to migrate, but you have to take all changes within the module.
• To perform a delta migration, use the sandbox feature in both the source and target instances. See Configuration Life Cycle in Configuring and Extending Applications.

Roles Migration

• If you need to review and create roles on the target instance, don’t run the migration pipeline. Run the export configurations job manually, create the required roles on the target instance, and then manually run the import configurations job. See Migrate Your Configurations.
• Get the access credentials of an Oracle Cloud Applications user who can connect and deploy to the target instance.

Extensions Using Visual Builder Studio

• In VB Studio, create a project for extensions.
• In your VB Studio project, make sure you have environments that point to both source and target Oracle Cloud Applications instances. See Add an Oracle Cloud Application’s Instance to an Environment in Administering Visual Builder Studio.
• If you want to import the configuration set into multiple target instances, create an import job for each target instance.
• When build jobs are running, don’t export configurations manually from the source instance or make security changes.
• After you have triggered the migration pipeline, do not cancel it or retry it if it seems slow. Check the build job’s log to monitor the migration status.

To deploy your extension to the Oracle Cloud Applications production instance’s sandbox, you’ll create these jobs and pipelines:

• A packaging job that packages the extension for the Oracle Cloud Applications production instance’s sandbox.
• A deployment job that deploys the extension to the Oracle Cloud Applications production instance’s sandbox.

Here are some tips that help you speed up your migration process:

• Perform a delta migration first, as it reduces the migration set size and reduces the time to migrate configurations. To do that, configure your export configurations job to move only the latest and incremental changes.
• To reduce failures, include only the required optional modules in the configuration data set and exclude the modules that have no application changes. The configuration set migration process involves migrating components, such as CRM, ADF, BI, SOA, as well as workspaces. If your base application has CRM and BI components, for example, but you don’t have any BI or Analytics related changes, exclude the BI component from the configuration set when you configure your export configurations job.