What's the Extension Lifecycle?

Whether you're configuring an Oracle Cloud Application or creating an App UI from scratch, the evolution of your extension follows a very similar path. Here's the typical process for creating and publishing an extension:

If you're customizing an Oracle Cloud Application:

In Oracle Cloud Applications, open the application you want to configure.
The changes you make are upgrade-safe, meaning that they will persist from one version of your Oracle Cloud Application to the next.
In the bottom right corner, click Edit Page in Visual Builder Studio to open the page in the Designer in VB Studio. (You should take care to make any necessary data model changes in your sandbox before you launch VB Studio.)

Description of the illustration editpagenew.png
To edit the page in VB Studio, you must belong to a project; that is, a project that has been set up to configure this particular Oracle Cloud Application in this environment. If this is your first time to VB Studio, decide how you want to proceed:
- When you don't have access to a project, you'll be prompted to create one. Optionally, you can add others who may work with you in this project. (Make sure someone has enabled these users to access VB Studio by following the instructions in Set Up VB Studio Users.)
  
  Note:
  Projects created this way use default settings to get you started right away. Once the project is created, you can access its properties to explore all the options available to you. As someone who creates the project, you automatically become the project owner, with rights to manage it. At this point, you may want to set merge restrictions on the main branch to control who pushes commits to it and how. See Set Merge Restrictions on the main Branch.
- When you have access to a project, select the project. If you belong to more than one project, you might have to choose. The projects that are based on the same Oracle Cloud Application you're looking to work with will be badged as . If a project is recommended but you're not a member, select the project and click Request Membership to contact the project owner and get yourself added. You'll be notified by email when your request is approved, at which point you can try editing the page again.
  
  You also have the option to create a new project, but that's not recommended. Best practice dictates that all team members work on a single extension dedicated to a particular Oracle Cloud Application.
Whether you create a new project or select an existing one, you'll need a workspace, which we'll create for you if you don't have one. Here's what you see when a workspace is created as part of the new project workflow:

Description of the illustration workflow.png

If you already have a workspace in that project, VB Studio will either automatically open that workspace for you or present you with options, as described in Configure an Oracle Cloud Application.

When accessing a workspace for the first time (something that is typical when you create an Application Extension project and are yet to open the workspace), your workspace will be set to your Oracle Cloud Application's active sandbox if one isn't associated with your workspace.
Once you access a project, you'll see your page open in the Designer with several editor tabs. In the canvas, you'll see the page you were just viewing, with the configurable components outlined in blue, both in the canvas and in the Properties pane:
Description of the illustration extendableareasingreen.png
In the Navigator on the left, you can see that your Oracle Cloud Application—in this case, Digital Sales—has automatically been added as a dependency for this extension (as has the Unified Application, which is considered a dependency for all extensions).

Your view of the Navigator may be different, depending on the base application you're configuring, but the extension lifecycle phases are the same.

Note:
If you're creating a new App UI, steps 1-3 don't apply. Instead, you'd create a new workspace, a new App UI, then start dropping components on the page. The remaining steps in this topic are common to both App UI creation and configuration.
When you click a component on the canvas, you'll see some of the component’s properties in the Properties pane:
Description of the illustration dyncompproperties.png
In this example, you can see details about the dynamic component defined in the dependency. To configure the component, you can use the Open Rule Set Editor link under Suggested Actions to open the editor.
View your changes with the preview tools.
For some components, you can also use the Layout Preview in the Properties pane when editing a page to check your layouts in the Page Designer:

Description of the illustration designer-layoutpreview.png

Or use Preview in the Designer header to see your changes as they'll appear in the browser page:

Description of the illustration preview.png
Share your changes to get feedback.
It's good practice to ask your team members to review the changes you make to an extension before you publish it. You can use the Share action in the upper right menu to generate a URL for the extension preview, which you can then give to team members so they can test your work. If you're working with a sandbox, be sure to give the testers the name of the sandbox along with this URL. If you're not working with a sandbox, simply share the URL.
Commit your changes to a branch.
You use the Git commands in the menu to commit and push the changes in your workspace to the remote branch. The Publish action automatically performs the commit and push for you through this dialog:

Description of the illustration publishchanges.png
Create a merge request asking team members to review your changes.
You team members can review the changes to the source files in the branch and approve the request if they look good. For some projects the merge requests might be optional, but a project owner can make merge requests and reviews mandatory.
Merge your branch into the main repository.
When your changes have been reviewed and approved, you can merge your branch into the main repository. The administrator can configure the project so that merging changes to the main branch will automatically trigger a packaging job, then a build job. The build job will create the build artifact that is deployed to the Oracle Cloud Applications test environment. After testing, a separate build job can publish the build artifact to the live (production) environment, assuming your administrator has set things up that way.
Check the status of your builds, which package up your extension and deploy it to the target Oracle Cloud Applications instance.

Note:
To ensure your changes will load successfully, the target instance must be running the same Oracle Cloud Application release version as your development instance. If you develop an extension on, say, 23D in your Test environment, then want to deploy the extension to your 23C Prod environment, you should wait until your Prod instance has been upgraded to 23D before you deploy the extension. In most cases there shouldn't be more than a two week gap between pod upgrades. See Oracle Applications Cloud – Fusion Applications Update Policy (Oracle account sign-in required).

You'll get messages in the Designer when the packaging and the build jobs start and stop. If you'd like to check the progress of the builds while they're running, you can go to the Environments page and get more details by clicking Open Job:
Description of the illustration buildstarted.png
View your published change.
After the build job completes, you'll be able see your work by going to your Oracle Cloud Applications instance and pointing your browser to the App UI you just created or configured. You may need to re-authenticate to see your latest changes.

What happens if someone else is working on an extension that modifies the same page that you're working on? See How Are Extensions Applied at Runtime? for answers.