Use CI/CD Pipelines for Deployment
VB Studio gives you the option to use CI/CD pipelines to deploy an extension to your Oracle Cloud Applications environments, whether it's to your DEV or PROD instance.
- By default, the changes made in an Oracle Cloud Application (through the Edit Page in Visual Builder Studio link) are set up to deploy directly to your target instance—typically a DEV instance—when you click Publish in the Designer.
You can deploy an extension to additional instances, also with a click of a button, from the Manage Lifecycle Extension page.
- CI/CD pipelines, meanwhile, let you decide how an extension is deployed. When clicking Publish, for example, maybe you'd like to deploy that extension to multiple instances at once—not just to a DEV instance, but perhaps to a TEST instance as well. And, maybe you'd also like to automatically kick off a deployment process whenever a code change is pushed to any arbitrary branch (instead of just to the default
mainbranch).You can set this up by enabling CI/CD pipelines for the extension and then configuring the supplied pipeline's out-of-the-box configuration to suit your organization's needs.
Use a combination of whichever deployment options work best. For example, in your organization, maybe it's most efficient to publish extensions directly using the Publish button, and to use the Manage Extension Lifecycle page for additional deployments, as needed. At the same time, you can leverage the use of CI/CD pipelines to automate certain lifecycle operations tasks.
Here's a brief rundown of a few key differences between the two publishing options:
| Publishing Aspect | Publish Directly | Publish via CI/CD Pipelines |
|---|---|---|
| Deployment flexibility | The key benefits of publishing an extension directly to Oracle Cloud Applications instances—using both the Designer's Publish button as well as the Manage Extension Lifecycle page—are speed and simplicity. The deployment process is straightforward, but not flexible. | Flexibility is the main reason to use CI/CD pipelines. When clicking Publish, maybe you'd like your extension to be deployed not just to a DEV instance, but to other instances as well.
You can also do things like configure a pipeline to download archived artifacts or discard old builds and artifacts, for example, or run builds on a specified schedule. |
| Speed | Publishing an extension directly to an Oracle Cloud Applications instance is fast. Deployment happens immediately, so end users can quickly view the changes. | When publishing an extension using a CI/CD pipeline, the deployment process isn’t immediate. You might need to wait for the entire process to complete before others can see the changes. |
| Multiple branch development environment | When published directly to your DEV instance via the Publish button, the extension is deployed from the main branch and you can't change it.
You can't pick the branch to deploy from when using the Manage Extension Lifecycle page, either. This is because deployments from this page reuse the build artifact that was already packaged and published to your DEV instance when the Publish button was clicked. |
CI/CD pipelines let you select the branch to deploy from. This means that, to deploy changes from a new feature branch or production branch, for example, you must use a CI/CD pipeline. |
| Merge requests | Since deployment is immediate, you can't include merge requests as part of the publishing process. To get changes reviewed, therefore, merge requests must be created before clicking Publish. | When publishing an extension using a CI/CD pipeline, you do have the option to build in merge requests. |
| Approval workflow | When publishing directly to an Oracle Cloud Applications instance, there aren't any built-in approval workflow capabilities. If you have access to an environment, you can deploy to it. | With CI/CD pipelines, you can add an approval item that requires one or more authorized users to manually approve a step before executing the rest of its run.
For example, a pipeline can automatically deploy an extension to your DEV and TEST instances, but require a manager's approval before deploying to your PROD instance. |
| Logs and build history | Publishing directly to an Oracle Cloud Applications instance doesn't provide a record of build details, log reports, and build history. | If you've used a CI/CD pipeline to deploy an extension, prior logs and build history are available for review. |
| Support for rolling back extensions to a previous version | If an extension was published directly to an Oracle Cloud Applications instance, that extension can't be redeployed at a later time. | If an extension was deployed using a pipeline and its build artifacts were archived, it can be redeployed at a later time, if needed. |
| Delete capability | If you need to delete an extension, the best practice is to click  on the Manage Extension Lifecycle page.
|
You can configure a job to delete an extension and include that job in a pipeline, but deleting an extension using a job doesn't delete the whole extension, only a specific version.
It's cleaner and therefore a better practice to use the Manage Extension Lifecycle page to delete extensions. |
If you decide you'd like to use CI/CD pipelines for the initial deployment of an extension, you'll need to enable the CI/CD Pipeline setting in the Designer; this setting is OFF by default. See Enable or Disable the CI/CD Pipeline for Publishing in Extending Oracle Cloud Applications with Visual Builder Studio. You can then configure the supplied pipeline's out-of-the-box configuration as needed.
You can also create and configure the build jobs and pipelines for each additional Oracle Cloud Applications instance you want to deploy to, as needed: