Deploy a Visual Application Without CI/CD Pipelines

When deploying a Visual Application directly from VB Studio without a CI/CD pipeline, you can select the application profile and choose whether to deploy the application in the Stage or Live state.

When CI/CD is disabled, you can designate an application profile as the development, stage, or live default.

The Publish dialogs provide options for deploying the application as Stage or Live. Stage is the default and is typically used for testing. Select Live when the application is ready to be made available to users.

You can’t deploy the same application version as Live more than once. If the current version is already Live, increment the application version before deploying it again.

These options provide more control in the direct Publish and Deploy flows and reduce the need to configure a CI/CD pipeline for common deployment scenarios.

Follow these steps when your visual application’s Enable 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.

This is the default setting for new workspaces. If you’d rather use a pipeline for deployment, change the Enable 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.

    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.