Hi ,

We are having on-premise outsystem environment and we are using mysql database for lifetime. but All our applications use oracle database. Hence through lifetime we are only able to do user management and not code migration. Hence we want lifetime's database changed to oracle. But would it affect user management of current environment? Also, Is it okay that our lifeTime has latest Version of Development Environment and Platform server but our Application environments are of 10.0.405.0? is there anything we need to take care of while we are changing database of Lifetime?

Please reply ASAP as this is high priority issue for code migration.

Hi Snehal,

In a typical scenario, the LifeTime environment holds none of your code in its database, it's stored in the database of each of your environments (which from what I understand are already using a "regular" Oracle database). Given this, why exactly do you need to change the LifeTime database to Oracle?

As for user management, meta information on users may be stored in the LifeTime database, but each environment has its own setup for its own users (which LifeTime manages through API calls).

Finally, regarding compatibility, LifeTime is backwards compatible with environments on other platform versions, this means a LifeTime on the Latest OutSystems version should be able to manage environments on previous versions (even 8 or 9.1) with no problems.

why exactly do you need to change the LifeTime database to Oracle? 

The reason why we want to change database to Oracle is that we want to use lifetime for code migration, i.e., from Dev to QA if some small changes have been done then we want to just change that much code of QA and this will be easy from lifetime setup, isn't it?

LifeTime is used to handle the lifecycle of your applications throughout your Infrastructure, i.e. deploy applications from one Environment (e.g. Dev) to another (e.g. QA). It fetches your applications from one Environment and publishes them on the other. Code changes are performed on the Environments themselves, not on LifeTime or the LifeTime Environment.

You don't need to worry about the underlying Database Engine at all as long as:

  1. Your applications only use Aggregates; or
  2. If you use SQL in your applications, you're only using standard SQL syntax.

If this is not the case... as long as your Environments are all using the same Database Engine you don't have to worry about it either. The exception here is the LifeTime Environment, as you won't have your applications deployed there at all, so you shouldn't need to worry about what Database Engine it is using.

Thanks Jorge, I understood that we do not need change of database for code migration. But still we need to change server(VM) of lifetime. But one of our environments(lets call it dev) is already registered on current lifetime. If we released this lifetime and setup new lifetime server and registered this environment(dev) there, would it be properly managed from new lifetime server? As we have seen this behavior earlier that, even after removing dev from lifetime, there is link for  "manage all environments" 

I haven't seen that behaviour before...

Just keep in mind if you register it in a new LifeTime (and don't backup/restore the LifeTime Environment's database) you will loose all application lifecycle info (application versions, tags, history, everything).

If you setup the new lifetime Environment and carry over the database from the old LifeTime environment, I don't think you will even need to register the other environments again, as that information hasn't changed.