What Happens When You Share and Deploy Visual Applications?
When you're ready to share your work with others, you use the Share option to generate a URL for your application that you can share with your team and ask for feedback. Then when you're done making changes, you use the Publish option to deploy the application and make all your changes public.
The Share option, which you can find in the menu in the upper right corner, deploys a visual application to your environment's Visual Builder instance, but without pushing your code to the project’s Git repository. As project members, you and your teammates can directly access the shared visual application from the Deployments tab of the Environments page; other users need the shared application URL to access the application. See Share a Visual Application.
After the application has been tested thoroughly and you're ready to make your changes public, you use the Publish option in the header to deploy your visual application. A successful publish merges your changes to the workspace's target branch you specify (such as main
) and then:
- If a CI/CD pipeline is enabled for the target branch, the packaging and deploy jobs in the pipeline—set up when your visual application's project was initially created—are triggered. This pipeline deploys your visual application (with the web apps it contains) to the environment specified in the deployment job. See Deploy a Visual Application Through CI/CD Pipelines.
- If a CI/CD pipeline isn't enabled for the target branch, your visual application's sources are merged to the target branch, then built and deployed directly to the environment associated with your workspace. See Deploy a Visual Application Without CI/CD Pipelines.
Here's a brief rundown of the two options: Publishing your changes directly to an environment's Visual Builder instance allows you to quickly view your changes—but because deployment happens directly, you won't have a chance to create a merge request as part of the publishing process, so you'll need to do that before publishing your changes. Publishing as part of a CI/CD pipeline gives you the flexibility of attaching additional jobs to the out-of-the-box configuration, but you'll need to wait for the entire process to complete before you can see your changes. For details on when and why you may want to use one option over another, see Use CI/CD Pipelines for Deployment in Administering Visual Builder Studio.
For deployment to be successful, your organization must have purchased a separate Visual Builder instance that your organization administrator has set up for you to deploy applications from your VB Studio instance. When using pipelines, this includes entering authorization details in the Deploy step of your visual application's deployment job to permit access to the Visual Builder instance. See Configure the Deployment Job in Administering Visual Builder Studio. If you're not using CI/CD pipelines for deployment, your organization administrator will simply need to enter authorization details when they first set up the environment you're deploying to.
Tip:
If you're not sure how your visual application is set up for publishing, go to the Settings editor and look at the selected Target Branch in the Building and Publishing section. If the Enable CI/CD pipeline option is selected for the branch, it means your visual application's changes are published via a CI/CD pipeline; if the option is not selected (as shown here), the changes are published directly:- Undeploy an application that's been deployed
- Roll back to a previous version of an application that you deployed
- Display a version number in the URL of a deployed app (usually, during development) or display "live" in the URL (usually, when the app is deployed to production)
- Lock and unlock a deployed application for maintenance
- Specify a custom app URL (sometimes known as a vanity URL) when you don't want to use the default URL that VB Studio generates for your application.
Note:
Sharing or deploying a visual application generates corresponding "app clients" on the target Visual Builder runtime instance. An app client is needed for your application's services and IDCS roles to work. You can delete an app client when it is no longer needed, for example, when you no longer need a shared application, you can delete the shared app's app client.