2 Migrate a Visual Builder Studio (VB Studio) Instance on OCI Classic to Visual Builder Studio on OCI
Migrating your projects from the source VB Studio instance to the target VB Studio instance involves migrating the source instance's build executors, build executor templates, and each project's data to the target instance.
In this documentation, the icon indicates either the source VB Studio instance or the source project. The
icon indicates either the target VB Studio instance or the target project.
Open the Source and the Target Instances
Open the source VB Studio instance in a browser and the target VB Studio instance in another browser. Note that you can't open both instances in the same session of a browser; however, you may open one instance in a tab and another instance in an incognito or a private tab in the same browser.
For example, in this image the source VB Studio instance on the left is open in Mozilla Firefox, and the target VB Studio instance on the right is open in Google Chrome.
![DevCS source and target instances in different browsers DevCS source and target instances in different browsers](img/devcs_source_target.png)
To open source and target instances as
described here, you must be assigned the
DEVCS_APP_ENTITLEMENT_ADMINISTRATOR
identity domain role for
both the source and target instances.
To open the source VB Studio instance:
- In a web browser, go to
https://www.oracle.com/cloud/sign-in.html
. - In Cloud Account Name, enter your tenant name or the identity domain name.
- Click Next.
- On the sign-in page, enter your Oracle Cloud account credentials, and click Sign In.
- On the OCI console, in the upper-left corner, click Navigation Menu
.
- Under More Oracle Cloud Services, select Platform Services, and then select Developer Classic.
- On the Instances tab, click Manage this
instance
and select Access service instance.
To open the target VB Studio instance:
- In a web browser, go to
https://cloud.oracle.com
. - On the Sign-In page, in Cloud Account Name, enter your Oracle Cloud account or tenancy name and click Next.
- On the Single Sign-On (SSO) panel, if required, select your identity provider and click Continue.
- Enter your Oracle Cloud account credentials and click
Sign In.
The Oracle Cloud Console, also called the OCI console, opens. If you've recently created your Oracle Cloud account, wait for some time to see your services in the Oracle Cloud Console.
- In the upper-left corner, click Navigation
Menu
.
- Select Developer Services and then select Visual Builder Studio.
- On the Visual Builder Studio Instances page, click the VB Studio instance's name.
- On the Instance Details page, click Service Console.
The VB Studio Organization page opens, which displays all the projects you're a member of, as well as your favorite projects, the projects you own, and all the shared projects in your organization.
Here's an example of the Organization page with some projects:
Migrate the Organization's Properties
To migrate the source VB Studio instance's organization properties, note its details and then configure the target VB Studio instance's Organization with the same properties.
Migrate VMs
To migrate build executors from the source VB Studio instance to the target VB Studio instance, create build executor templates with the same name and software on the target VB Studio instance, and then allocate the same number of build executors to each template.
Follow these steps to migrate build executor templates and build executors:
- Open the browser with the source VB Studio instance.
- In the
navigation menu, click
Organization
, and then click the Build Executor Templates tab.
- Repeat these steps for each build executor template in the source VB Studio instance:
- In the source VB Studio instance, get the details of the build executor template and number of build executors allocated to it.
- In the target VB Studio instance, create the build executor template and allocate the same number of build executors to the build executor template.
- After creating all build executor templates and build executors, with the Build Executor Templates tab open in both source VB Studio and target VB Studio instances, verify that the build executor templates in the target VB Studio instance match those in the source VB Studio instance.
- Open the Build Executors tab in both source and target instances and verify that number of build executors in the target VB Studio instance matches the number of build executors in the source VB Studio instance.
Gather Information About a Build Executor Template and Its Build Executors From the Source VB Studio Instance
Perform these steps in the source VB Studio instance.
Create a Build Executor Template and Its Build Executors in the Target VB Studio Instance
Perform these steps in the target VB Studio instance.
Migrate the Organization's Component Exchange
If teams in your organization develop custom components (web components, application templates, UI patterns, and actions) for visual applications, a Component Exchange may have been set up to make the components available to all VB Studio users.
To host the custom components, you can define either a VB Studio project or an external server as the Componengt Exchange. Although any VB Studio project can be used as the Component Exchange, you should create and set up a separate project to host components. If you have multiple VB Studio instances across multiple tenancies, you can specify an external server as the common Component Exchange for all VB Studio instances.
To use a project or a server as the Component Exchange, you specify its details on the Organization page. When set, the VB Studio Designer automatically shows the Component Exchange's hosted components in the Components tab.
To migrate the Component Exchange from the source VB Studio instance to the target VB Studio instance, configure the Component Exchange with the same project name or server on the target VB Studio instance.
- Open the browser with the source VB Studio instance.
- In the left navigator, click Organization
, then click the Component Exchange tab.
- In the source VB Studio instance, get the details of the Component Exchange's project or server.
- In the target VB Studio instance, create the Component Exchange using the source VB Studio instance's details (project or server).
- After creating the Component Exchange in the target VB Studio instance, with the Component Exchange tab open in both the source VB Studio and target VB Studio instances, verify that settings in the target instance match those in the source instance.
Gather Information About the Component Exchange From the Source VB Studio Instance
Perform these steps in the source VB Studio instance.
Create the Component Exchange in the Target VB Studio Instance
Perform these steps in the target VB Studio instance:
- Get the details of the Component Exchange from the source instance.
- Switch to the browser with the target VB Studio instance.
- Go to the Component Exchange tab, and select the Enable organization-wide component hosting check box.
- Select where the target instance's custom components will be
hosted:
- Select In a project and then
use the selector in the
Project field to select the
project that will host the custom components.
Note:
If you are going to use a project to host custom components, the project's security setting in the project's Properties must be set to Shared. - Select On a custom server and enter the Server URL shown in the source instance's Server URL field. If any credentials (username and password) were shown in their respective fields for the source instance, enter those in the Username and Passoord fields now..
- Select In a project and then
use the selector in the
Project field to select the
project that will host the custom components.
- Click the Test Connection button to make sure that the connection to the custom server works.
- Click Save.
Migrate Projects
To migrate projects from the source VB Studio instance, you will export each project's data to an OCI Object Storage bucket or an OCI Object Storage Classic container.
You'll then create projects in the target VB Studio instance using the exported data. Finally, you will copy any data or artifacts that were not part of the export from the source VB Studio instance to the target VB Studio instance.
Gather Information About a Project From the Source VB Studio Instance
Note the name, description, security, and the wiki markup language of the project in the source VB Studio instance.
To get the details, you must be assigned the project's Owner role. If the role is not assigned to you, sign in as the Organization Administrator and assign the Owner role to yourself.
Perform these steps in the source VB Studio instance.
Export Project Data From the Source VB Studio Instance
You can export a project’s data to an OCI Object Storage bucket or an OCI Object Storage Classic container.
There are no differences between exporting project data to an OCI Object Storage bucket or an OCI Object Storage Classic container, so the choice is yours. Do note that OCI offers better security and speed than OCI Classic. When you export project data, not all the artifacts are included. You'll have to manually export the remaining artifacts and data manually.
This table shows you which artifacts are exported and which are not:
Artifact | Exported? | Notes |
---|---|---|
Project users | No | When you export a project's data, its users are not exported. However, all the
data associated with the usernames (issue
ownership and reviewers of a merge request, for
example) will be preserved.
After you import the project's data to another project, all the data associated with the username will automatically be restored after you add a user with the same username to the project. |
User's favorite settings or personal preferences | No | |
Hosted Git repositories | Yes | |
Mirrored public external Git repositories | Yes | |
Mirrored private external Git repositories | No | Password-protected external Git repositories aren't exported.
After you import the project's data to another project, you must add each external private Git repository. |
Branch restrictions | Yes | |
Merge Requests | Yes | |
Default reviewers of a branch | Yes | After you import the project's data to another project, default reviewers are added automatically after the same users are added to the target project. |
Workspaces | No | Repositories that are associated
with your user's workspaces will be exported, but
the workspaces themselves will not be.
Users must push all workspace changes to their Git repository before those changes can be exported/imported. |
Maven artifacts | No | |
NPM artifacts | No | |
Linked Docker registries | No | |
Build jobs | Yes |
All builds of jobs are exported, along with their logs and artifacts. If a job retains an excessive number of builds, it will adversely affect the export process and will require a large amount of storage space in your bucket or container. Configure a job to retain a reasonable number of builds before you export the project. |
Build job's history and artifacts | Yes | |
Name of the build job's build executor template | No | |
Pipelines | Yes | |
Releases | Yes | |
Deployment configurations | No | |
Environments | No | |
Issues | Yes | |
Agile boards | Yes | |
Wiki pages | Yes | |
Snippets | Yes | |
Project template definition | No | |
Announcements | No | |
Webhooks | No | |
RSS/ATOM feeds | No | |
Link rules | No | |
Project tags | Yes | |
Issue products and components | Yes | |
Default owners of issue components | Yes | After you import the project's data to another project, owners are activated automatically after the same users are added to the target project. |
Issue custom fields | Yes | |
Named passwords/private keys | Yes |
Note: The passwords are securely exported and imported as keystore binary data. |
Export a Project's Data to an OCI Object Storage Bucket
To export a project's data to an OCI Object Storage bucket, you need the bucket's name, private key and fingerprint of a user who can write objects to the bucket, and details of the compartment that hosts the bucket.
Perform these steps for each project in the source VB Studio instance as the project's
Owner.
Export a Project's Data to an OCI Object Storage Classic Container
To export a project's data to an OCI Object Storage Classic container, you need the container's name, credentials of a user with the Storage_Administrator or the Storage_ReadWriteGroup identity domain role, and the service ID and the authorization URL of your OCI Object Storage Classic service.
Perform these steps for each project in the source VB Studio instance as the project's Owner.
Create a Project With an Exported Project's Data in the Target VB Studio Instance
While creating a project, you can import data from an exported project's archive file stored in an OCI Object Storage bucket or an OCI Object Storage Classic container.
To import project data, you need these details:
If you've exported to OCI Object Storage, you need: | If you've exported to OCI Object Storage Classic, you need: |
---|---|
Name of the target bucket | Name of the target container |
Name of the exported archive file | Name of the exported archive file |
Private key and fingerprint of a user who has the BUCKET_INSPECT (or BUCKET_READ ) and OBJECT_READ permissions of the bucket
|
Credentials of a user with the Storage_Administrator or Storage_ReadOnlyGroup identity domain role. |
Details of the compartment that hosts the bucket | Service ID and the authorization URL of OCI Object Storage Classic |
Note that if you've moved the exported file to an OCI Archive Storage bucket, you must restore the exported file object and move it to an OCI Object Storage bucket or an OCI Object Storage Classic container before creating the project. To restore objects in OCI Object Storage, see Managing Objects.
After you have the required input values, you can import the project.
Perform these steps in the target VB Studio instance.
In the created project, verify artifacts listed in the table of Export Project Data From the Source VB Studio Instance with Yes value in the Exported? column have been imported.
If the import fails, you can import the data again without creating the project. See Export and Import Project Data in Using Visual Builder Studio.Migrate Other Artifacts and Data
After exporting a project from the source VB Studio instance and creating a project of the same name with the exported project’s data in the target VB Studio instance, migrate the artifacts that weren't exported.
Before you begin, open the source project in a browser and the target project in another browser. Then, to migrate an artifact, note and copy its details from the source project and create or add it manually to the new project.
For example, in this image, the source project, on the left, is open in Mozilla Firefox and the target project, on the right, is open in Google Chrome.
![Source and Target Projects Source and Target Projects](img/devcs_source_target_project.png)
Project Users
To migrate users, you'll need to add them manually to the new project.
If you're switching to another identity domain, make sure that VB Studio users of the source identity domain are added to the target identity domain with the same usernames and roles. See Create Users and Assign Roles in Getting Started with Oracle Cloud.
Follow these steps to migrate project users:
- Open the source project. In the
navigation menu, click
Project Home
.
- Open the target project. In the
navigation menu, click
Project Home
.
- Click the Team tab.
- In the source project, gather information about the usernames and roles of project users.
- In the target project, add the users and assign them the same membership types.
- After adding users, with the Team tab open in both source and target projects, verify that users and roles in the target project match the source project.
Add Users in the Target Project
Perform these steps in the target project.
When you're done, verify that the users and roles in the target project match the source project.
Before you exported the source project's data, you noted whether you're a member or an owner in the source project. Don't delete that data. You'll need it after migrating all source project's artifacts to the target project.Mirrored Private Git Repositories
If the project users have been using private Git repositories on another platform, such as GitHub or Bitbucket, and have mirrored them to the project, note that they aren't exported to the archive file when you export project data.
Follow these steps to migrate a project's mirrored private Git repositories:
- Open the source project. In the
navigation menu, click
Project Administration
.
- Open the target project. In the
navigation menu, click
Project Administration
.
- In the source and target projects, follow these steps:
- Click Repositories.
- Expand External Repositories.
- Repeat these steps to migrate each mirrored private Git repository:
- In the source project, gather information about a mirrored private Git repository.
- In the target project, add a mirror to the private Git repository.
- After migrating all private Git repositories, with the Repositories page open in both source and target projects, verify that repositories in the target project match the source project.
Docker Registries
Follow these steps to migrate Docker registries:
- Open the source project. In the
navigation menu, click
Project Administration
.
- Open the target project. In the
navigation menu, click
Project Administration
.
- In the source and target projects, follow these steps:
- Click Repositories.
- Expand Docker Repositories.
- Repeat these steps to migrate each Docker registry:
- In the source project, gather information about a Docker registry.
- In the target project, add the Docker registry.
- After migrating all Docker registries, with the Repositories page open in both source and target projects, verify that registries in the target project match the source project.
Maven Artifacts
You might have several artifacts in the source project's Maven repository, such as dependencies and build artifacts. To migrate them, you'll need to note details of each artifact, download it, and then upload it again in the target project. You may choose not to migrate build artifacts stored in the Maven repository of the source project as you can generate and archive them by running a build in the target project.
Follow these steps to migrate Maven artifacts:
- Open the source project. In the
navigation menu, click
Maven
.
- Open the target project. In the
navigation menu, click
Maven
.
- Repeat these steps to migrate each Maven artifact:
- In the source project, gather information about a Maven artifact and download it to your computer.
- In the target project, upload the Maven artifact.
- After migrating all Maven artifacts, with the Maven page open in both source and target projects, verify that artifacts in the target project match the source project.
- Switch to the browser with the source project. In the
navigation menu, click
Project Administration
and then click Repositories.
- Switch to
the browser with the target project. In the
navigation menu, click
Project Administration
and then click Repositories.
- Note the Maven auto-cleanup and overwrite settings of the source project and make the same settings in the target project.
- After migrating all Maven settings, with the Repositories page open in both source and target projects, verify that Maven settings in the target project match the source project.
Gather Information About a Maven Artifact From the Source Project
Perform these steps in the source project.
Environments
Follow these steps to migrate environments and its service instances:
- Open the source project. In the
navigation menu, click
Environments
.
- Open the target project. In the
navigation menu, click
Environments
.
- Repeat these steps to migrate each environment:
- In the source project, gather information about an environment and its service instances.
- In the target project, create the environment and add its service instances.
- After migrating all environments, with the Environments page open in both source and target projects, verify that environments in the target project match the source project.
Gather Information About an Environment and Service Instances From the Source Project
Perform these steps in the source project.
Create an Environment and Add Service Instances in the Target Project
Perform these steps in the target project.
After you recreate Environments on the target instance, update the entries in the individual build jobs that reference the environments. In some cases, you may also need to provide updated user credentials for any jobs that deploy artifacts to the target Environments.
Build Job's VM Template
When you create a project with the exported project's data, the build jobs of the source project are migrated to the target project, but the job's Build VM template's name, its Java version, its Notifications setting isn't migrated.
Follow these steps to migrate the Build VM Template information of jobs:
- In the source and target projects, in the navigation bar, click Builds
.
- Repeat these steps to migrate each job:
- In the source project, gather information about a job's VM template, Java version, and notification settings.
- In the target project, configure the same job and specify its VM template, Java version, and notification setting.
- After specifying VM templates to all jobs of the target project, run a build of each job.
If a job's build fails, verify its configuration.
Note that if a job is part of a pipeline, a build of its dependent jobs would run automatically after the build of the job is complete. So, trigger a build of all pipelines. This would ensure that dependent jobs do not fail. After builds of all pipelines is complete, run a build of jobs that aren't part of a pipeline.
Webhooks
Follow these steps to migrate webhooks:
- Open the source project. In the
navigation menu, click
Project Administration
and click Webhooks.
- Open the target project. In the
navigation menu, click
Project Administration
and click Webhooks.
- Repeat these steps to migrate each webhook:
- In the source project, gather information about a webhook.
- In the target project, create and configure the webhook.
- After migrating all webhooks, with the Webhooks page open in both source and target projects, verify that webhooks in the target project match the source project.
Template Definition
If the source project is a template, then to migrate its template variables and rules, you'll need to add them manually to the new project.
Follow these steps to migrate a project's template definition:
- Open the source project. In the
navigation menu, click
Project Administration
.
- Open the target project. In the
navigation menu, click
Project Administration
.
- In both source and target projects, click Properties.
- In the source project, gather information about the project's template definition.
- In the target project, configure the template definition.
Announcements
Follow these steps to migrate announcements:
- Open the source project. In the
navigation menu, click
Project Administration
.
- Open the target project. In the
navigation menu, click
Project Administration
.
- In both source and target projects, click Announcements.
- Repeat these steps to migrate each announcement:
- In the source project, gather information about an announcement.
- In the target project, create and configure the announcement.
- After migrating all announcements, with the Announcements page open in both source and target projects, verify that announcements in the target project match the source project.
RSS/ATOM Feeds
Follow these steps to migrate RSS/ATOM feeds:
- Open the source project. In the
navigation menu, click
Project Administration
.
- Open the target project. In the
navigation menu, click
Project Administration
.
- In both source and target projects, click RSS/ATOM Feeds.
- Repeat these steps to migrate each RSS/ATOM feed:
- In the source project, gather information about a feed.
- In the target project, create and configure the feed.
- After migrating all feeds, with the RSS/ATOM Feeds page open in both source and target projects, verify that feeds in the target project match the source project.
Custom Link Rules
You don't need to migrate the default link rules as they are available in the target project.
Follow these steps to migrate link rules:
- Open the source project. In the
navigation menu, click
Project Administration
.
- Open the target project. In the
navigation menu, click
Project Administration
.
- In both source and target projects, click Links.
- Repeat these steps to migrate each link rule:
- In the source project, gather information about a rule.
- In the target project, create and configure the link rule.
- After migrating all link rules, with the Links page open in both source and target projects, verify that link rules in the target project match the source project.
Remove Your Membership or Ownership
After migrating all artifacts of the source project to the target project, if you were not a member or an owner of the source project, you should remove your membership or ownership of the target project.
Perform these steps in the target project.
Migrate User Preferences
After migrating a project's artifacts and adding team members, ask each user to sign in to VB Studio and set their user preferences and project preferences.
User Preferences
To migrate your user preferences, note them in the source VB Studio instance and set them again in the target VB Studio instance.
User preferences include your display name, email address, and email notification preferences.
- In the source VB Studio instances, click the user avatar, and select Preferences.
- Gather information about your preferences.
- In the target instance, set them.
- After setting preferences, with the User Preferences tab open in both source and target instances, verify that your preferences in the target instance match the source instance.
Project Preferences
To migrate your project preferences, note them in the source project and set them again in the target project.
Project preferences include favorite Git repositories and Agile boards, and the watch settings of branches and jobs.
Git Repositories and Branches
- Open the source project. In the
navigation menu, click
Project Home
.
- Open the target project. In the
navigation menu, click
Project Home
.
- In the source and target projects, click the Repositories tab.
- Switch to the browser with the source project.
- Note the repositories marked as your favorite. You can identify them with the
icon.
- Switch to the browser with the target project.
- In the Repositories tab, click the
Favorite
icon of the repository to mark it as your favorite.
- In the source project, click Git
and then click Refs.
- Switch to the browser with the source project.
- For each repository in the Repositories list, note the
branches you watch. They are marked with the Subscribed
icon.
- Switch to the browser with the target project.
- In the Refs tab, select the repository and click cc in the branch to watch it.
Jobs
- Switch to the browser with the source project.
- Click the job's name to open it.
- If CCme is CCed, click it and note the states of check boxes in the CC Me dialog box. Click Cancel. Then, follow these steps in the target project:
- Switch to the browser with the target project.
- Open the same job.
- Click CCme. In the CC Me dialog box, select the check boxes as noted, and click OK.
- Switch to the browser with the source project.
Agile Boards
- In the source project's navigation bar, click Boards
.
- In the target project's navigation bar, click Boards
.
- Note the boards marked as your favorite. You can identify them with the
icon.
- Switch to the browser with the target project.
- For the boards marked as favorite in the source project, click the Favorite
icon to mark it as your favorite.