Extension Best Practices

For optimal behavior, there are a few best practices you should follow when setting up and working on your extensions:

• You should use one project for all of your Oracle Cloud Application extension work, with a different Git repository for each product family (known as a pillar in VB Studio)—one for HCM, one for SCM, and so on. In other words, you'll have one extension per pillar, with all the source code for that extension stored in its own repo.

  If, however, you have users that need to be isolated from each other's work—say, different consultant organizations doing implementation work for different pillars—you may opt to separate your work by pillar, and create one project for each.

  Whether you choose to use a single project with multiple repositories or multiple projects, the goal is to keep the work for each pillar separated in its own extension (repository).

  Note:

  If you already have more than one project created for a given Oracle Cloud Application, the best option is to simply consolidate all changes into a single project manually and continue from there.
• To access Visual Builder Studio, start on the Oracle Cloud Applications page you want to modify, then click Edit in Visual Builder Studio from the Settings and Action menu. Using this method directs you to the right project and workspace and avoids creating extra Git repos and extensions that aren't needed.
• After an Oracle Cloud Application release update, continue to use the same project and workspace for your extension work. VB Studio automatically updates your workspace to take advantage of any new functionality as soon as you open it. These changes are propagated to the associated Git repository (extension) when you click Publish.

  Note:

  Not all Oracle Cloud Application release updates will require updates to your extension source code.
• To ensure your changes load successfully when publishing your extension, the target instance must be running the same Oracle Cloud Application release version as your development instance. If you develop an extension on, say, 24D in your Test environment, then want to deploy the extension to your 24C Prod environment, you should wait until your Prod instance has been upgraded to 24D before you deploy the extension. In most cases there shouldn't be more than a two week gap between pod upgrades.