In most cases your organization is going to have more than one Visual Builder instance in order to separate the development instance from the production instance (sometimes adding an additional test/QA instance). While you develop your application on the development instance, once your code changes are ready you would need to promote the new application version to the other instances. In many cases those instances will already have a running apps on them, so you need to deploy the new version on top of the existing one without losing data.
In the past, with only Visual Builder, that involved manual export/import of the application from one instance to the other. With the functionality provided by Visual Builder Studio you can automate this process to simplify and streamline the process. In this blog we'll show you how to do this.
Demo
In the video below we use two environment Dev and QA with the application already running in the QA instance. Now we need to make a change to the application, we then deploy it on the dev instance to be able to verify it, and when we are ready, we deploy it to the other instance.
Let's look at the components of the solutions:
Environments
An environment is mapped to an instance of Visual Builder (or Oracle Integration Cloud). The instance can be in the same tenancy as your Visual Builder Studio – or in a separate cloud tenancy. In the first scenario, VB Studio will show you the instance as part of the tenancy instances when you click the add instance to environment. In the case where we are looking for an instance in a separate tenancy, use the option to add the server using the Visual Builder Credentials and specifying the URL to the instance (VB or OIC). For specific steps see our environments doc chapter.
Once your environment is defined you can map Oracle Deployment steps to it.
Deployment Jobs
When working with Visual Builder Studio you can leverage the Oracle Deployment build step to deploy an application to an environment. The deploy step will use a before build step to copy the artifacts created by a package job that will also optimize your VB app for deployment. Then you can pick up which instance you want to deploy to from the environments you have defined.
There are two important aspects to note in the deployment step:
- What to do with the data that already exists in the application's database (business objects) – the two options are to keep the existing data or to create a new empty database. It's likely that you'll want to keep the existing data. If you want to repopulate the app with a new set of data you can use the build steps that can import/export data from business object.
- Whether to include a version number in the URL of the app – For production apps you don't want to include the version number – this gives the end users a fixed URL that they access for the app. A new version of the app will replace the existing app in the same URL. For development and testing scenarios you might want to include the version number of the app in the URL – which allows you to have multiple versions of the app accessible simultaneously so you can test them all in parallel.
Summary
With Visual Builder your team is getting a simple way to manage your application code in one place and deploy to multiple instances in an automated fashion. If you are doing serious development with multiple developers and multiple environments – using VB Studio is highly recommended.
