Right way to update database in production?

Support
#1

Hi,

We are working on a project. It’s deployed on our customer server, and every week we go and update and so on.
Last time we noticed some tables were not updated to latest model version. Not sure if it’s related, but when I will commit I see some files will be deleted from git
imagen

Right now we are deploying newer versions copying tomcat folder to customer server.

Some idea what could be happening about data model update on production database? We are doing something wrong?

#2

If you are not the only person who creates update scripts for the database, I would suggest migrating the database in multiple steps:

  • first, you integrate changes, build the product and review new update scripts
  • then update some test or staging environment
  • if everything is ok, update the production database
#3

Is not supposed CUBA can update automatically? Updates to database are coming from CUBA data model changes, not external

#4

This “automatic” update actually consists of two very different steps: first, you create update scripts (with the help of Studio or manually) on the development stage, then the app server applies the scripts when starting the app.

If you are working on the model modifications alone, usually there are no issues - Studio has a single source of truth when generating update scripts - your model and your development database. But when multiple developers do it simultaneously, there may be differences in their databases, so there is no guarantee that the resulting set of scripts will be consistent. You have to review it manually before applying.

1 Like
#5

Ok, let me explain other way. We are 2 developers making a lot of changes all the time and merging branches.

If we keep a copy of the structure in production in the customer, there are some way for CUBA to detect the changes needed from the new version we will deploy, and rebuild the DB scripts needed, before the final step of deploying, from our master branch?

#6

Then would I suggest the following workflow:

  • Copy the current production structure to your local databases.
  • When developing with local databases, do not commit update scripts to VCS. After each update from VCS, a developer should run generation of update scripts for his local database, to incorporate changes made by other developers.
  • After integrating changes into master, on one developer’s machine delete all uncommitted update scripts and run generation of update scripts again.
  • At this point, you will have an exact set of scripts for production database migration. You can commit it and go further with the deployment.
1 Like