Visual Builder Studio: Migration Steps and Best Practices

#oraclehcm #vbs #redwood

In the previous blog (Previous blog link is provided at the end of this blog.), we learned the basics of Visual Builder Studio, including how to create a project and manage repositories. Now that you have a good understanding of these concepts, it's time to look at some practical tips that can help you work more effectively.

In this blog, we'll go through some best practices, useful migration tips, and common things to watch out for when working with Visual Builder Studio.

Migration:

Create a new Branch:

In the left navigator, click Git.
Click the Refs view and then click Branches.
From the Repositories drop-down list, select the repository.
Click + Create Branch.
In the New Branch dialog box, in Name, enter the branch name. From the Base drop-down list, select the main branch as the base branch.
Click Create.

Configure Package:

Deploy Package:

Pipeline:

Things to Consider

Use the same VB Project and extension for all changes in HCM.
Enable Branch Protection on Main branch and optionally other branches.
Ensure that when working in multiple environments, the same Project is used.
Only merge changes to the main branch when they are ready for Production.
Use Share to provide the URL to a deployed version of your changes to reviewers.
No two developers should work on the same page at the same time.
Make sure that the source and target instances are of the same release, with the same standard and one-off patches applied to both environments.
Only use Dev POD for all the VBS changes and migrate your changes from
1. Dev pod to higher environments. 2.Developers should work in separate feature branches to avoid conflict.

Customization of Processes Using Page Properties in Oracle Visual Builder Studio (VB Studio):

Functional administrators use page properties to extend Redwood pages.

Page properties enable extensibility for:

Reordering tabs in Journeys.
Showing or hiding panels in Connections.
Configuring guided journeys.
Expressions can be written in Express mode to conditionally render elements (e.g., displaying person pronouns for specific roles only).

Accessing Page Properties:

Available page properties for a page are accessible via the Page Properties pane in the Designer.
If the pane shows "We didn't find any extendable page properties on this page," it means no page properties have been delivered for that page by HCM yet.

Additional Notes:

Many page properties have already been delivered across various Redwood pages.
These properties provide diverse options to tailor the application.

Common Uses of Page Properties Include:

Adding custom content to a page or region.
Configuring guided journeys.
Enabling nudges.
Controlling page elements such as sorting, tabs, and field display in some cases.

Recommended Project Structure:

Use one project for all HCM changes.
Use one Git repository.
Have one workspace (multiple workspaces are allowed).
Use multiple development/feature branches per developer/page.
Avoid multiple projects to prevent overwriting.
Use local branches for development and commit them in individual development/feature branches (example: cwk_branch, emp_branch)
Use release branches(main) for deployment.

VBS Branching Strategy:

Why do you need a branching strategy

Allows control over what is deployed to Production.
Allows users to create personalizations in isolation from others or in conjunction depending on the requirement.
Allows different sets of personalizations to be developed and deployed at different.

How do you decide what your branching strategy should be
What are your timelines?
• How is you team structured ?
• How streamlined do you need the development environment to be?
• How much complexity can you tolerate ?
NOTE: Managing branches can only be done in Advanced Mode.

Create a Blank Branch (Clean Code Reference)

Acts as a clean template with no custom code.
Serves as a reference point for any new feature branches created.
Ensures developers always branch from a consistent baseline.

Setup Branch Protection for Main branch(Production Release)

This is your release branch.
All code gets merged here through pull/merge requests
Include approval workflows to control what gets into higher environments and production. NOTE: Make the main branch private and setup some approval workflows before merging the code to main branch

Local Development Branch:

The local branch gets autocreated whenever we open the workspace
We do all our changes in the local development branch
Once all the changes are completed, we publish the changes to the working environment and also push the code to feature branch.

Feature Branch (Branch per Page or Developer)

Create a separate Feature branch for each UI page being modified or per Developer based on the feature being developed.
Promotes isolated development and avoids conflicts.

Development Flow: