Hi Chandrasekhar,

Did you want to migrate app from one environment to another i.e. dev >> Test >> Prod in OS?

Please confirm

Regards,

Rajat Agrawal

Rajat,

We have currently 3 environments Dev , Test and Prod. We use Lifetime to migrate app from Dev , Test and Prod. 

The new application we are implementing have around 6 environments. We want to simulate same number of environments by utilizing 3 environments.

In .Net, we used to copy the application folder to multiple folders and setup new websites for System Test1, System Test 2 and Integration Test in the staging server with connections to correct databases. 

App - NGSS (used for UAT )

Cloned App -- NGSS_System1 ( Used for System Testing ) in Test Environment

Chandra

Hi,

I think it is exactly as you described, you will need to clone the applications and reference them according to the relationship you want.

I am not convinced that this would be the best solution, because if you need to make adjustments in this application you will have to replicate the adjustments manually.

The branching functionality in OutSystems is in Early Access Program, maybe you can take a look at it.

https://www.outsystems.com/nextstep/2019/?wchannelid=lxt52ix89e&wvideoid=oft9gqg5d5

If I use clone, what will happen to the tables, roles etc. Will the tables be duplicated with the data and the roles also will be duplicated?

There is not much documentation on how to use clone and create a replica of the app.

Branching also seems interesting. I don't know if we can use the early access feature in Non-prod and get the support. How do we proceed if we want to use the early access feature of Branching?

Hi Chandrasekhar,

Carlos is correct about the Clone functionality: it clones only that specific module and just that one. If you have multiple modules in your application and you want to clone them all, you need to clone one by one.

Regarding to your question, here's my response:

• The Clone functionality literally creates a new module. If you have a module called ModuleA, then the clone will be a copy of it, called CloneOfModuleA;
• This new module called CloneOfModuleA works as any other module;
• If you clone a module with tables, these tables will be copied to the new module. So, if you publish the clone, tables will be duplicated;
• Since OutSystems assumes that the clone is an entire new module, the tables will be created in the database, so they won't have any data (you can always perform some queries to populate them). Of course, this doesn't apply to static entities;
• Although the tables have the same logical name, it is possible to distinguish the tables between the original module and the clone - the prefix in the physical table name will be different. You can also change the table names before publish;
• Roles will also be duplicated;
• The URL will be different between applications, since the names of the modules are different as well.

Overall, this functionality applies on how many modules you have in your application and their purpose. For example, maybe you don't need to clone a theme module or a library module, since they are not changed by the systems implementation. But other modules that are affected by these changes, you need to clone them in order to test those changes.

Let me know if you have any further questions.

Kind regards,

Rui Barradas

Hello Chandrasekhar.

Rui's answer is excellent. The only extra notes you need are:

1. Careful with the clones in test. You may exceed the database size loading multiple times the same data. Measure the space you takes and see if doubling and tripling it still fits.

2. Careful with the timers running over the same data. If they start at the same time, they will compete for the same resources. And if they have the same id, they may even steal data from each other!

I'd like to suggest two another things, in order to avoid duplication of tables and roles you can separate them in another core module.

And when you finish the tests, will you merge everything? As I mentioned before, if you make adjustments during the tests you will have to replicate for all applications, otherwise it will be very laborious.

Thanks for the reply.

That was our concern too. 

First, we can clone the module to new module in the new app. 

Concern 1: What is the easiest way to migrate the data ?

Concern 2: How to refresh the entities to point to new tables? What is the effort involved?

Concern 3: How do we make changes in the original development module and refresh to regular test and the cloned test module ? 

Concern 4 : When we overwrite the new test module, what will happen to the roles and connections ?

Not much documentation is available to explain clone and a continuous refreshes.

Thanks

Chandra

Hi,

I founded this infrmation about branching EAP:

You may ask to participate by sending an email to branching@outsystems.com.

Concern 1: What is the easiest way to migrate the data ?
In the same environment using server actions to wrapper the entity, make public and using dependencies.

At differents enviroments using API or the forge component (licensed) Infosistema DMM, for example.

Concern 2: How to refresh the entities to point to new tables? What is the effort involved?

I would choice  to separate the entities and roles in a Core Module

Concern 3: How do we make changes in the original development module and refresh to regular test and the cloned test module ? 

Unfortunately, manually :( unless using branching

Concern 4 : When we overwrite the new test module, what will happen to the roles and connections ?

You'll need to refresh dependencies and republish all consumers modules.