Manage Extensions on Multiple VB Studio Instances

Oracle is in the process of provisioning multiple instances of Visual Builder Studio for each Oracle Cloud Applications customer. New customers will see this configuration as soon as they are provisioned with Oracle Cloud Applications; existing customers are being migrated to the new landscape over the next several months.

In this new configuration, every TEST and DEV instance in your Oracle Cloud Application environment family receives its own instance of VB Studio, which in turn are tied together by a single VB Studio organization:

Description of the illustration shell-instances.png

By sharing a common organization, users working in VB Studio associated with a TEST instance, for example, are able to access the same projects, repositories, and extensions as users working in a completely different instance—say a DEV instance tied to a different VB Studio instance, or another TEST instance. They can see each other's changes, review and approve each other's merge requests, and collaborate on the same wikis, all as though they were in the same VB Studio instance. This arrangement also underpins and facilitates the use of a single project and Git repository for all extensions to your Oracle Cloud Applications—no matter if they're from HCM, CRM or another App—which just so happens to be Oracle's recommended best practice. (See Extension Best Practices for more extension-related best practices.)

Here are some important considerations to keep in mind when using multiple VB Studio instances:

• You can use different VB Studio instances for different purposes. For example, you might maintain one or more extensions using VB Studio in your PROD instance, while simultaneously evaluating new functionality in an upcoming Oracle Cloud Applications version using a different VB Studio (likely one associated with a DEV instance running the newer version).
• Having multiple VB Studio instances gives you flexibility in case the instance where you normally work is unavailable for some reason. For example, suppose you usually work in Project A on the DEV1 instance, but DEV1 is down for some reason. As long as your identity on DEV2 is also a member of Project A—and assuming that you've pushed your latest changes to Git—you can access the project through the VB Studio associated with DEV2 and pick with your work from there. (See How Are Users Impacted by Multiple VB Studio Instances? for more about user identities.) Note that both DEV1 and DEV2 must be running the same release of Oracle Cloud Applications in order for this scenario to work properly.
• You don't have to have a VB Studio instance associated with an Oracle Cloud Application instance in order to deploy to it. That is, you can deploy an extension to a PROD instance from any DEV or TEST instance in your environment family, despite the fact that PROD is not associated with a VB Studio instance. See Set Up the Project to Deploy to Production for more.
• If you are developing an extension in one instance and want to test it in another, follow the instructions in Set Up the Project to Deploy to Other DEV and TEST Instances. After you press the Publish button in the Designer to commit the changes you made in the extension to the Git repository in VB Studio, you'll need to do the following:
  • Define a new environment and map it to an Oracle Cloud Applications instance, providing the URL to the instance and the credentials for a user that can deploy extensions there. These credentials must be those of a local user, not a federated identity, and must not require multi-factor authentication.
  • Create a new deployment job that is based on the built-in deployment job that was created for your extension then, in the configuration for the new job, switch the environment used for the deploy step and update the user credentials, as needed.
  • Optionally, include the new build job in your pipelines.
  After the job runs successfully you can see your extension deployed on the new instance. You can track the existing deployments through the Deployment tab for your environment in VB Studio.
• Although you can use the VB Studio instance that was provisioned alongside your Oracle Cloud Applications account to create visual applications, you’ll need an instance of Visual Builder to deploy them to. By default this instance is in a different identity domain than VB Studio, so you'll need to follow the procedures described in Create and Set Up a Project for Development (Different Identity Domain). If you decide to create this instance in the same domain as your VB Studio and Oracle Cloud Applications instance, see Create and Set Up the Project for Development (Same Identity Domain).
• Your organization may have multiple environment families, each with its own TEST instance. If you need to determine which TEST instance VB Studio is associated with, contact your Oracle Cloud account administrator, who has access to your organization's cloud account and can retrieve this information.

Note:

If you don't yet have multiple instances of VB Studio available, you can still move your instance of VB Studio to a different Oracle Cloud Applications instance. By default your VB Studio was provisioned with your first Oracle Cloud Applications TEST instance. To use VB Studio with a different Oracle Cloud Applications TEST instance—or a DEV instance—file a service request so the VB Studio instance associated with your current TEST instance can be terminated, then a new one can be created and associated to your preferred instance. Provisioning VB Studio for PROD instances isn't supported. When you file the service request, please ask for instructions to backup your VB Studio projects so you don’t lose any data. For details about what else to include in the service request, see Move the VB Studio Instance. Only one move between pods is allowed, unless a pod must be terminated for some reason and therefore requires another association.