You've developed a great extension for your Fusion Application and your'e ready to get it out to your users. Visual Builder makes it as simple as pushing the publish button! But what happens when this button is pressed? This blog will give you the inside scoop. If you'd rather not read, you can watch a video.
What does the Publish button do?
In the following examples, changes to the extension were made on a git branch called 'a3'.
Don't worry, you don't need to be a git expert to understand what's happening.
When you push the button, you'll be given two choices.
Both options will do the following automatically:
- Make sure the backend is ready to publish a new build.
- Save the changes to the git branch 'a3'.
- Fetch any changes from the Visual Builder Studio remote repository into your workspace repository.
- If someone else had published changes after you started this branch, those changes would be merged into the 'a3' branch.
The "recommended practice" option is
Merge After Review
Having another set of eyes review your changes is always a good idea. It will help you avoid bugs and other issues. Even if you're working alone, it's a good idea to take a second look at your changes.
Enter a detailed message and choose a person to review your changes. If you're using the Issue tracking feature in Visual Builder Studio you have the option to link to the issue your changes are resolving.
In addition to the above steps, this option will create a Merge Request in Visual Builder Studio. Once your changes have been reviewed and accepted, they will be merged into the main branch.
The other option is
Merge Now
Enter a detailed message and click Publish Changes.
In addition to the above steps, this option will:
- Merge your changes into the main branch in your workspace repository. The workspace 'main' branch now contains any external changes which have been merged with your new changes.
- Push the merged changes back to the remote repository main branch in Visual Builder Studio.
You will receive notifications similar to these. (The example project is named 'blaine-blog'.)
From the perspective of Visual Builder, you are done and your changes have been deployed.
CICD Pipeline
When you created your project a CICD Pipeline was created for you.
Whenever there is a change commited to the main branch the CICD pipeline is triggered.
The pipeline has two steps:
- An artifact that can be deployed will be created.
- The artifact will be deployed to your environment.
Once deployed, you can find the URL for your extension in the Oracle Visual Builder Studio Environments section under the Deployments tab.
To dig a little deeper, you need to look into the build jobs. The build jobs are located in Oracle's Visual Builder Studio.
Switch to Visual Builder Studio
Switch to Visual Builder Studio by clicking the arrow in the upper left corner next to your workspace name.
Once you're in Visual Builder Studio open the Builds section.
Open the Pipelines tab to see the how the build jobs are connected.
Clicking on a job's name will open it's details page.
The Package Job
The first job in the pipeline 'blaine-blog-package' is triggered whenever there is a commit to the main branch in the git repository. Open the job by clicking on the name, then click the Configure button to see how it is setup.
The Git tab
This tab contains the settings for connecting the build job to a git repository.
The repository select list allows you to select one of the git repositories in your VBS project.
The checkbox labeled "Automatically perform build on SCM commit" sets this job to execute anytime a change is committed to the repository.
The "Auto Branch" settings will limit the job to only execute when commits are made on the defined branches. This job will only trigger when changes are made to the "main" branch.
When this job runs, the selected git repository will be cloned into the build job workspace before any build steps are executed.
The Steps Tab
This is where the majority of the work is performed for the build job.
Multiple steps can be added to a build job as needed.
This job only uses the "Application Extension Packaging" step. This step is included in VBS. It is preconfigured to collect the VB Extension components from the cloned git repository and package them for deployment.
The generated Build Artifact will be named "extension.vx". You could change the name of the artifact and/or manually assign a version number, everything else is take care of automatically.
The After Build tab
Once all of the build steps are finished the selected actions on this tab will be executed. Multiple actions can be executed. Available actions include passing parameters to future jobs, storing artifacts and integrating with other tools such as test reporting.
The "Artifact Archiver" action will store the extension.vx file created by the previous job step. Other jobs can copy the artifacts from this archive as needed.
Once artifacts have been archived, they can be manually downloaded. The artifacts button on the job details page will show the artifacts of most recent job.
To download the artifacts from a previous build, click the build number in the Build History section.
Then you can use the artifact button on the details page to download artifacts from that specific build.
After running the "package" job, the artifact file will be stored and is ready to be deployed by the "deploy" job.
The Deploy Job
The next job in the pipeline, 'blaine-blog-deploy', is triggered once the 'blaine-blog-package' job successfully completes. Open the job by clicking on the name, then push the Configure button to see how it is setup.
This job does not connect to a git repository. Instead, it copies the artifact from the "package" job.
The Before Build Tab
The Copy Artifacts action is used to copy the build artifacts from the selected job.
The artifacts are copied from the "Last successful build" build of the "blaine-blog-package" job.
If the selected build job has multiple artifacts, you could choose a specific artifact by populating the "Artifacts to copy" field. Leaving it blank will copy all artifacts.
The Steps Tab
The "Oracle Deployment" step will deploy the packaged artifact to the selected instance.
"extension.vx" is the Build Artifact copied from the previous job.
The Target Instance field is used to select a Service Instance "Oracle Applications Cloud (Fusion)" from an Environment "(Development)". This is where the artifact will be deployed. Username and Password are both required. The user account must have permission to deploy to the selected instance.
Once this job completes your extension has been deployed.
Environments
You can find details about the deployed extension in the Environments section of Visual Builder Studio.
Under the Deployments tab, locate the version of your Extension with the Active check-mark.
The "Box/Arrow" icon under App UIs will open your extension in a new browser tab.
To undeploy an extension use the Delete option in the "…" menu.
That's it, your extension has been modified, built, packaged and deployed.
Now that you understand what happens when you publish an application, you might wonder how can you revert the publishing action and return to an older version if you publish an application by mistake. Here are a couple posts to help.
Rollback a Fusion Application Extension to a Previous Build
Rollback a Fusion Application Extension to a Previous git branch