Deploy a Visual Application

Deploying a visual application requires you to commit and push the changes in your workspace to a Git repository branch. Once you’ve pushed your changes from the workspace to the branch, a build pipeline that packages the content in the branch and deploys it to your environment's Visual Builder instance is triggered.

You can run a pipeline manually in the early stages of development, when you want to deploy the content of your working branch to the Visual Builder instance for review. Before you run the pipeline manually, you’ll need to verify that your working Git repository branch is specified in the pipeline job that packages your visual application (see Access Project Git Repositories). Once you've verified that the package job in your build pipeline is configured to use your branch, you can run the pipeline (see Run the Pipeline).

Alternatively, you can use the Publish option in the header. Given that Publish merges the content of your working branch to the default branch (main, for example) and runs a pipeline that deploys the content of the main branch to the Visual Builder instance, this option is probably something you’ll use when you’ve tested your visual application and are ready to make your changes public. Keep in mind that you'll need a production instance of Visual Builder to deploy your changes to production.

Note:

To deploy your visual application, the pipeline's deployment job must be configured with the credentials of a user who is authorized to connect and deploy to the Visual Builder instance. If your project owner hasn't provided these credentials, you'll be prompted to provide them when you click Publish the first time. If your credentials don't allow you to deploy to the Visual Builder instance, talk to your project owner or an administrator to get credentials that you can use. The credentials that you enter when prompted, if valid, will be permanently saved in the deployment job. Your administrator can also choose to enter the credentials directly in the build job, so you aren't prompted for them when you try to deploy your app. See Configure the Deployment Job in Administering Visual Builder Studio for details on how an admin can add the missing credentials.

When you're ready to publish your changes:

1. Click Publish in the header.

   Note:

   If the Publish option is not enabled, it's likely because you're using a scratch repository instead of a real Git repo. If that's the case, and you do want to publish your work, create a new repo, as described in Push a Scratch Repository to a Remote Repository.
2. If you land on the Merge Now tab, it means you have permission to push your changes directly to the main branch without getting it approved by other project team members. Simply enter a Commit Message describing your changes.

   As a best practice, you can request someone to review your changes by creating a Merge Request. Switch to the Merge After Review tab, enter a comment summarizing your changes, add at least one reviewer, and specify the issue you were working on.

   
   
   Description of the illustration vbs-publish-dialog.png
   

   If you don't see the Merge Now or the Merge After Review options, that means the project owner or an administrator has set things up so that all changes must be reviewed and approved via a Merge Request before they can be merged to the main branch. In this case, summarize your changes, add at least one reviewer (if no one is specified), and specify the related issue in order to create a merge request. (Once the request is created, you can look for it on the Merge Requests page. For details on how to work with merge requests, see Review Source Code with Merge Requests in Using Visual Builder Studio.)

3. Click Publish.

   Tip:

   Use the details in the Publish dialog to take note of the environment that your changes will be published to, which is typically the deployment target specified in the pipeline that's enabled for the main branch.

After VB Studio performs the Git actions necessary (commit, push, merge) to merge the changes in your local repository to the main branch (as shown here), it starts the pipeline to package and deploy your changes to the Visual Builder instance associated with your project.

Description of the illustration vbs-publish-git-actions-complete.png

Note:

Once you merge a branch into the main branch, you can no longer use it (or your local copy of it). A new branch is created automatically for you when you publish your changes, which you can use to make additional changes. Or you can create your own branch, if you prefer.

At this time, you'll see notifications in your workspace showing the progress of your application's package and deploy jobs.

Description of the illustration build-notifications.png

Click Open job to view a job's details or to take action if a job fails.

After the deployment job has successfully run, you can view your changes deployed to the Visual Builder instance in your environment. See View Deployed Visual Applications.