I’m at the point where I want to release the instance of suiteCRM that I have been working on into the wild for user to test. They will be adding data, and obviously changing records and so on. I want to continue to develop suiteCRM on a dev. environment and then release the updated dev. version of suiteCRM to the live server. Question: how do I achieve this without impacting the data that has been changed? We’re self hosting SuiteCRM. I’ve never done this before so apologies if this has been asked before, but I want to be clear.
What I’m looking to do:
Initially, Development Server -----> Live Server
Subsequently, Development server version re-released with code/ other changes ----->live sever/no data change, but updated SuiteCRM
If you keep the two servers in sync regarding the SuiteCRM version, and you make sure nobody is using Studio / Module Builder / Dropdown Editor in your production instance, then your two databases should stay in sync, regarding structure, only the data will be different.
This means that you can move database form one server to the other, and move code from one to the other, with independence (and proper backups!)
You can probably just move any new code into production just by copying all your files on top of what is already there.
You need more care if you still plan to do structural changes in your new developments (new custom fields, etc).
The documentation says to “develop” in a development or test environment. So I want to do this, but do I have to operate a separate environment (server, suitecrm installation, DB etc) or just copy the suitecrm folder?
If a separate environment is required, how is the release of new developments, fields etc handled?
Normally I would keep the two environments completely separate - different VMs or different servers.
Then, I see that companies who use automated deployments tend to disable Studio on the production server, otherwise things wouldn’t be properly tested, and would be hard/impossible to manage.
So you do all your changes in development, and then push the changes out via file copy. When you deploy these new files, if they have any vardef changes, you go into the Admin / Repair in production, do a QR&R, and scroll down to the bottom where a button is offered to create the new fields in the database.
I am not that much experienced in this sort of maneuver so please test this with simple things before relying on it.