Deploy a Visual Application Without CI/CD Pipelines

Follow these steps when your visual application's CI/CD pipeline setting is disabled for the remote branch you're merging to, or when a pipeline doesn't exist for the branch. With this setting, your changes are deployed directly—without the use of a pipeline—to the Visual Builder instance in the environment associated with your workspace.

Note:

Visual applications are, by default, deployed using the CI/CD pipeline enabled for your project's main branch. If you don’t want to use a CI/CD pipeline for deployment, change the CI/CD pipeline setting in the Settings editor. See Enable or Disable the CI/CD Pipeline for Deployments.

When deploying changes without CI/CD pipelines, your visual application's sources are merged to the remote repo's target branch you select, then built and deployed directly to the environment associated with your workspace. Because deployment happens directly, you won't have a chance to create a merge request as part of the publishing process. So if you want to get your changes reviewed, create a merge request before publishing your changes. For details on how to work with merge requests, see Review Source Code with Merge Requests in Using Visual Builder Studio.

When you're ready to deploy your changes:

1. Click Publish in the header.

   Note:

   If the Publish option is not enabled, you're likely using a scratch repository instead of a real Git repo. If that's the case, and you do want to deploy your work, create a new repo, as described in Push a Scratch Repository to a Remote Repository.
2. If changes exist, enter a comment in the Commit Message area to describe your changes and commit them. A commit groups the changed files and provides a description to identify the group.
3. In the Target Branch field, select the branch in the remote repo to merge to.
   The first branch in this list is always the repository's default branch, main, conveniently followed by the last 10 branches you created merge requests for (if any). Any remaining branches follow in alphabetical order. This flexibility lets you more easily publish and test your new feature development work, if you're not yet ready to merge those changes into your repository's main branch.
4. The New Working Branch Name field displays with an automatically populated new name for your working branch. You can accept the default, but it's recommended to change to a name that's more meaningful.
   Once you publish a branch, you can no longer use it (or your local copy of it). Instead, VB Studio automatically creates a new working branch using the value in this field, and switches your workspace to it for any future changes.
5. Click Publish.

   Your changes are merged from your working branch to the selected target branch, then directly deployed to the Development environment associated with your workspace.

Once deployment is complete, you can view your changes deployed to the Visual Builder instance in your environment. See View Deployed Visual Applications.