Oracle Cloud Infrastructure Documentation

Use CI/CD Pipelines for Deployment

Visual applications can be deployed to your development Visual Builder instance either directly or via continuous integration and delivery (CI/CD) pipelines.

  • Direct deployment means that, when you click Publish in the Designer, your visual application is merged to a target branch in the remote repo, such as the main branch, and then deployed directly to the environment associated with your workspace.

    This is the default deployment method for new workspaces you create.

  • CI/CD pipelines, meanwhile, provide flexibility—for example, you can configure a pipeline to deploy dependent artifacts to the target environment in parallel, run builds on a specified schedule, or discard old builds and artifacts.

    You can set this up by enabling a CI/CD pipeline for the target branch you want to merge to, and configuring that pipeline to suit your organization's needs.

Note

Use a combination of whichever deployment options work best. For example, in your organization, maybe it's most efficient to deploy a visual application directly to your development Visual Builder instance using the Publish button. At the same time, you can leverage the use of CI/CD pipelines for deployments to other Visual Builder instances, as well as 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 a visual application directly to a Visual Builder instance using the Designer's Publish button 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 visual application 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 a visual application directly to a Visual Builder instance is fast. Deployment happens immediately, so end users can quickly view the changes. When publishing a visual application 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.
Deploying to multiple instances

You can deploy your visual application to your DEV instance directly, without using a CI/CD pipeline.

To deploy that visual application to other instances, however, you must use CI/CD pipelines.

 You can configure CI/CD pipelines to deploy changes to any instance, not just to your DEV instance. You can also configure a pipeline to deploy to multiple instances simultaneously.
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 a visual application using a CI/CD pipeline, you do have the option to build in merge requests.
Approval workflow When publishing directly to a Visual Builder 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 a visual application 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 a Visual Builder instance doesn't provide a record of build details, log reports, and build history. If you've used a CI/CD pipeline to deploy a visual application, prior logs and build history are available for review.
Support for rolling back visual applications to a previous version If a visual application was published directly to a Visual Builder instance, that visual application can't be redeployed at a later time. If a visual application was deployed using a pipeline and its build artifacts were archived, it can be redeployed at a later time, if needed.