Upgrading and the Development Process - Best Practice for getting new DB fields in non-custom tables

đź’¬ General Discussion
1

Currently I have a development process such as:

localhost -> Test Server -> Production Server

Normally, when I deploy my own custom fields, I push my files to the test server, and then download a sql file of “fields_meta_data”. I then execute this sql file on the test server DB and then do a quick repair and rebuild to add in the new fields automatically.

Recently I have been working on upgrading our instance from 7.5.1 -> 7.10.4.

Somewhere along this upgrade process, some fields were added to the email_addresses table, I’m not sure if there are more, but I’m seeing those in the error log from sql queries failing. While I know I can manually add these fields back in, I was hoping for a solution involving a quick repair and rebuild or something similar.

Any help on best practice here?

2

Just to clarify, what is your plan when upgrading 7.5.1 -> 7.10.4? You are going to use the upgraders, with all incorporated scripts, or where you trying to just deploy the new files and database changes?

Because there is too much stuff in those upgrader scripts for it to be advisable (or even possible) to skip them.

3

So, on my localhost on my computer, I have gone through the upgrade process using:

-SuiteCRM-Upgrade-7.5.x-to-7.7.5
-SuiteCRM-Upgrade-7.7.x-to-7.9.4
-SuiteCRM-Upgrade-7.9.x-to-7.10.1
-SuiteCRM-Upgrade-7.10-to-7.10.4

After this I had to fix quite a lot of things due to high levels of customization. After the past month of development, I am ready for end-user testing, so I copied the files from the localhost and moved them to the test server, then executed the fields_meta_data table and did a quick repair and rebuild which added a lot of things including non-custom tables such as the oauth tables.

Are you saying I need to roll back the CRM to my last version, and then execute the upgrade scripts, and then copy my files over along with the fields_meta_data table?

4

The basic idea is:

  • always upgrade with upgraders, not with any special deployment scheme, because additional scripts in the upgraders are doing work behind the scenes, and you need that

  • always keep migrations and upgrades separate. If you’re migrating, do it to the same version.

So you would bring the destination server up to the same version, and then migrate your data and/or customizations.

As a side tip, if you use Cases check if the “Update Threaded” section is working well, that was the most problematic feature when upgrading from old versions.