In this blog we'll demonstrate how to get started with developing extensions for Oracle Fusion Cloud Apps, and how to set your project to use the recommended development flow. Specifically, we are addressing using the express mode in Visual Builder Studio to customize Redwood pages. We are following the best practices recommendation documented for extension development. The end result should be a single project, with a single git repository to host your Fusion Apps extensions. This along with a single workspace per developer and the use of multiple branches should allow you to more efficiently manage your extension development process.
Below is a quick video showing the full process, followed by a more detailed explanation.
Project Setup
The easiest way to properly get started with customizing pages in Fusion Apps is to use the "Edit in Visual Builder Studio" menu option from the page you want to modify. This will create the project and the artifacts properly. The artifacts created include: an environment mapped to the Fusion Apps instance, a CI/CD pipeline with two build jobs to package and deploy extensions, a Git repository for managing customization code, a branch of the code and a workspace associated with it. The project creation dialog also allows you to add additional team members to the project.
Once completed, VB Studio will then open the workspace and the specific page in the visual editor in Visual Builder Studio. You'll see the express mode editing experience, if this is enabled on the specific Fusion module.
Additional Project Settings
An important best practice is to introduce a review step for changes, before they are merged into the main code branch. To enforce this, switch to the advanced mode and navigate to the Visual Builder Studio project home page. Under the Project Administrations -> Branch Protection section add a rule that requires review for changes going into the git's main branch. Add here the users that should conduct such a review and provide approval.
Another update should be done to the default deploy job. Go into the Build Job for deploying the extension and update the user credentials in the deploy step to the user which is responsible for deployment to the specific Fusion Apps instance.
If there are additional team members that should be able to create extensions add them as team members in the project home page on the right. They will need to have the right roles to be listed in the drop down list.
Isolating Page Changes
Many customers prefer to have a fine-grained isolation of which changes get deployed to which environment and at what point of time. To achieve better management you'll leverage Git branches.
We recommend creating branches to isolate changes of independent units you are planning to deploy. A branch lets you manage changes without impacting other pages. When a workspace is created for you, it is created with a new branch automatically so you are all set for your first set of changes.
When you switch to editing another page, by default these changes will be done in the same branch that was created for you. This means that the previous changes and the new ones are in a single bundle and will be merged into the main code line together. If you'd rather have isolation of these changes from the previous changes you did, use the switch branch option at the top-right side of Visual Builder to create a new branch before doing any changes to the new page.
Note that the same workspace can be used to edit multiple branches, and you can switch between them from the same menu option.
Getting Ready to Publish Changes
While you are developing your extension you can use the preview button to see how it behaves. When you are ready for others to review the extension before they get deployed, you should use the Share option for your extension. Share creates a deployed copy of your extensions that others can access and see the runtime behavior of. Copy the URL to the shared application as you'll want to share this in your merge request notes.
Now you are ready for others to review your code changes, click the Publish button. The publish will try to merge your changes into the project's main line of code which contains all the other extensions that are ready to be deployed. But we setup our project to require a review before such merge is completed. So, you'll be prompted to provide a description of the changes you did, and you'll see the name of the default reviewer. In addition, you can paste the URL to the shared app here to allow the reviewer to see the extension in action. You can add additional reviewers for the specific change.
Approving Changes
The default reviewer can see your code changes requests in their merge-requests queue. They'll see your comments and the content of files that were changed. They can click the URL to access the shared version and see if the behavior is according to the requirements. If they are happy with the changes, they can click Approve. When all the approval conditions are met, the Merge button can be pressed.
The merge will incorporate the changes from the specific branch into the main line of code. The main line of code includes all the approved extensions, and once it is changed with the new extension it will start the deployment pipeline that will deploy the new changes to the Fusion Apps instance specified in the deploy step.
Another advantage of this approach is that it is relatively easy to rollback a change you did. You can use the revert merge request button to revert changes you merged into main.
Summary
With the approach outlined above you should be able to manage the lifecycle of your extension/customization while working in the express mode of Visual Builder Studio.
For those who feel more comfortable with Git concepts, Visual Builder Studio offers further advanced options for managing the work including the ability to create deployments from specific branches rather than the main branch – allowing you to deploy specific changes to your test environment.
One recommendation, mentioned in our documentation, is to create a release branch when you are ready to deploy to production.
Advanced mode in Visual Builder Studio also includes additional git capabilities such as cherry pick, stash, and other options that help manage your extension life cycle.
A related blog entry you might be interested in shows how to pick specific extensions that will be deployed to the production instance.