Suitecrm: Performing an upgrade from the CLI

Created on 2 Jan 2019  路  6Comments  路  Source: salesagility/SuiteCRM

Issue

We're trying to perform an upgrade to our SuiteCRM instances (we have dev, test, staging, prod, and local instances for each of our developers, so each person would need to separately go through the update process as well as four separate updates on our hosted instances). This is pretty time consuming and has caused us to fall behind quite a bit on upgrades (the customizations we've made are also partly to blame, but that's our own fault and our own problem to deal with).

It should be possible to run (maybe via a Robo task?) the upgrade procedure entirely from the command line, with no need for interaction with the web interface. There's a "Silent Upgrade" functionality that seems leftover from SugarCRM but that doesn't seem to have been maintained and I'm not sure if it'd actually work currently.

Does anyone have similar problems, or any potential solutions/guidance for this?

Fix Proposed Suggestion

Most helpful comment

@Abuelodelanada I didn't know about sqlt-diff, it definitely looks like a useful tool for this purpose. 馃憤

To make SuiteCRM easier to maintain and deploy, we need to overcome the way that changes are split across database and file system, or even between different folders in file system, not always consistently. I'd love to see us making some progress in that front.

All 6 comments

Hi @connorshea

I know that it's not exactly what you are looking for, but a year ago we wrote an Ansible Role to install SuiteCRM instances silently.

May be you can take some ideas from it.

We have forked the SuiteCRM official github... And this have more brancech... Our forked primary SuiteCRM is again forked by external developers...

On their instance do the chances and move to Our forked primary SuiteCRM do develop branch... Where is created the test version live by cli. When the changes are working are merged to master and deploy by cli on production site.

From Official SuiteCRM we are merging the changes to Forked Primary SuiteCRM to hotfix branch and from there each developer to own forked instance from Forked Primary SuiteCRM.

We are not found better way how cooperate more developers and testers when we want apply the fixes from Official github and develop/customise own things

The big challenge for us is database and structure changes of there... This is nightmare.. Even more if you create new module and you want distribute the changes in mysql over team.

If will someone lauthing on our system, we are small company with small budget and can't hire best of best on the world 馃槑 and we do what we can 馃憤

Hi @Mausino

In 2014 we migrated a big SugarCRM CE 5.2 instance to the last SugarCRM CE 6.5.25.... Since we had a lot of non-safe-upgrade customizations, we managed to fix this during that migration. For this we did the migration "manually".... That migration lasted several months. :-|

Any way we managed not to have a nightmare with the database using sqlt-diff. You can read (in spanish) what we did here.

@Abuelodelanada thank you for reference.. sure we will look on it.. and spanish isn't problem for google translate 馃敤 we heared about sqlt-diff but had not so much experience with it... we worked with dump sql structure to text file-> diff it -> created the sql command (which we had in one file.. )

that for any upgrade which have influnce on datatabase we made commands for new table structures and marked by our internal numbers... or for laziest can create by stagging the latest duplicate of mysql database and saved it on server to download it (after develeper can import it by command line to clear mysql)

Not the best.. but working for us... but we look on your reference... and will see, if will our "virtual life" easier

Will mark this as a suggestion for now, i'd like to take a look into the silent upgrade process and see if we can add it into Robo.

@Abuelodelanada I didn't know about sqlt-diff, it definitely looks like a useful tool for this purpose. 馃憤

To make SuiteCRM easier to maintain and deploy, we need to overcome the way that changes are split across database and file system, or even between different folders in file system, not always consistently. I'd love to see us making some progress in that front.

Was this page helpful?
0 / 5 - 0 ratings