Create a Workspace

To work on a visual application, you must have a workspace; it's your ticket into the Designer.

You can create workspaces in projects where you've been added as a team member. A workspace requires an environment against which you develop your application and deploy to. All your workspaces will probably use the same development environment because a project typically has only one. This environment must support the type of project you are working on, so to create a workspace for a visual application, your project must be associated with a Visual Builder instance. If the development environment isn't defined, you won't be able to create a workspace; ask the project owner or an administrator to create one for you before you try to create a workspace.

Note:

Typically, the Visual Builder instance added to your visual application's environment uses the same identity domain as your Visual Builder Studio instance. If you choose a Visual Builder instance from a different identity domain as your deployment environment, you'll see a warning about setting up the Allowed Origins configuration. Talk to your administrator to make sure your instance's domain is added to its list of allowed origins, as described in Allow Other Domains Access to Services.

A workspace is typically associated with a Git repository—either one you create from scratch or, if you plan to collaborate with someone who has already started developing an application, a copy of the Git repo they've been working in. Because Git repos store your source files, it's helpful to familiarize yourself with some concepts underlying Git.

How to Use Git Branches to Isolate Changes

Your visual application's Git repository is automatically created when your project is first set up. In most cases, this project repository includes the default branch (usually, main) and an associated branch where your changes are stored. The default branch is typically the source from which your visual application is built.

Because the default branch represents the source of truth—code that is tested and ready to be pushed to production—it is usually protected and any changes to this branch will require approval. If you want to make changes to the default branch (main, for example) but don't have permission to push to it, you'll make your changes in a separate branch based on main, then create a merge request to get your changes reviewed. After your changes are approved, you'll merge the changes in your branch to the main branch and make your updates public. Even if a public branch isn't protected, it's good practice to always work on a private branch and merge your changes to a public branch only after review.

You create a separate branch based on the main branch when you create a workspace. You can have separate branches for each new feature or change to your visual application. You can even use separate branches to create two different versions of one feature. For example, you might want to work on two different versions of a table. By creating a branch for each version, you can work on one version in one branch with (say) Workspace A mapped to it, then switch to another branch using Workspace B to work on the other version. This way, you can use workspaces to isolate the branches with your changes. After you decide which version you want to use, you can share the branch with others and delete the branches you no longer need.

Watch this video to learn the basics, like remote and local repositories, as well as how they tie in to workspaces:

What's a Scratch Repository?

When you create a workspace, you have the option to create a scratch repository, rather than a new repository (which is based on the main branch of the project's repository). It's helpful to create a scratch repository when you're experimenting and you're pretty sure you'll never want to merge your changes into an existing repository.

A scratch repository is a private repository that only exists in your workspace. Only you can use the scratch repository, and it's deleted when you delete the workspace. If you want to let your team members use your scratch repository, you'll need to push the scratch repository to a new remote repository so your teammates can clone it.

When you create a Git repository for your workspace, VB Studio automatically sets up packaging and deploy jobs and adds them to a CI/CD pipeline, allowing you to build and publish your artifacts simply by clicking Publish. If you opt for a scratch repository, however, these jobs are not initially set up for you, unless you decide you want to publish the changes in your scratch repo. To do this, you'll need to first push your changes to a remote repository, at which time VB Studio asks you to identify the target repository, then creates the required package and deploy jobs for you as part of a build pipeline. (You have the option to not create these builds and pipeline, if that's what you want.) See Push a Scratch Repository to a Remote Repository for more information.