Extension Best Practices

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

• If your team plans to extend Oracle Cloud Applications from multiple product families, like HCM, SCM, and so on (known as pillars in VB Studio), the way you set up your projects depends on your organization’s specific needs:
  • In general, it’s easiest to use a single VB Studio project for all your extension work, with a different Git repository for each pillar. Using a single project keeps everything together in one place, limits the number of permissions each user requires, and generally makes sense if your team is on the smaller side.
  • If, on the other hand, you have users that need to be isolated from each other’s work—say, different consultant organizations doing implementation work for different pillars, or a larger team that uses a common Oracle Cloud Application environment family to develop, test, and host extensions from multiple pillars—you may opt to separate your work by creating one project for each pillar.

  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: Keep in mind that each project starts fresh with a clone of Oracle’s code for a given Oracle Cloud Application, so any customizations you’ve made using other projects won’t be automatically included. If you already have more than one project created for a 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 Page 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 to deploy the extension. If your instances are out of synch, you’ll see this message: "Dependent Extension with Extension id: xxxxand version >=xxxxx doesn’t exist". In most cases there shouldn’t be more than a two-week gap between pod upgrades. See What If Dev and Prod Instances Aren’t On the Same Release?
• Avoid deleting projects that contain active extensions—that is, extensions that are deployed to a live production instance. If you do delete such a project, the extensions will remain active, but you won’t be able to update them nor perform any lifecycle activities on them moving forward, unless you manually recover them. See How Do I Recover My Extension After Deleting the Project?
• As explained in Work With Multiple VB Studio Instances, every TEST and DEV instance in your Oracle Cloud Application environment family receives its own instance of VB Studio, and your identity is different on each VB Studio instance you’re working with. For example, in the development instance DEV1, your user name might be known as JoeSmith@<Oracle Cloud Applications-instance-name>-DEV1 to VB Studio, while on DEV2 your user ID is JoeSmith@<Oracle Cloud Applications-instance-name>-DEV2, and so on. Because workspaces operate on a per-user basis, you will likely end up with more than one workspace, one for each of your user identities. If you’re going to work on the same set of files from more than one instance (that is, from more than one workspace), it’s important to publish (or merge) your changes from one workspace before switching to another. This helps to avoid merge conflicts and ensures that you have the very latest changes before you resume your work.