Dear All,
Please suggest how to deploy SugarCRM After upgrade existing instance to Staging server and also suggest the name of tables they are directly move to other DB.
Thanks & Regards,
Suraj Kumar
Dear All,
Please suggest how to deploy SugarCRM After upgrade existing instance to Staging server and also suggest the name of tables they are directly move to other DB.
Thanks & Regards,
Suraj Kumar
From my experience there is no easy way to "move" changes from a staging server to production when doing a Sugar upgrade. Or at least not one I have found. I repeat all the upgrade steps in each of my environments.
Chris Raffle may have some thoughts on this too.
Francesca
Hi Suraj Kumar ,
Francesca Shiekh is right in that there isn't an easy way to accomplish what you are seeking. Each upgrade can potentially include:
The last item, data manipulation, is the most difficult problem for which to solve. For complex implementations where we need to achieve your use case, we built tooling to capture all the database-level changes that happen in an upgrade. We would extract the critical database queries from that output to build a script. We then used a git promotion strategy that would execute the desired scripts within a specific promotion to ensure everything happens as we expect when it comes time to upgrade production.
It's a setup that is rarely needed outside of heavily customized instances. You are likely going to be better off in terms of cost & time to go with Francesca's approach of independently applying upgrades to each environment.
Chris
Hi Suraj Kumar ,
Francesca Shiekh is right in that there isn't an easy way to accomplish what you are seeking. Each upgrade can potentially include:
The last item, data manipulation, is the most difficult problem for which to solve. For complex implementations where we need to achieve your use case, we built tooling to capture all the database-level changes that happen in an upgrade. We would extract the critical database queries from that output to build a script. We then used a git promotion strategy that would execute the desired scripts within a specific promotion to ensure everything happens as we expect when it comes time to upgrade production.
It's a setup that is rarely needed outside of heavily customized instances. You are likely going to be better off in terms of cost & time to go with Francesca's approach of independently applying upgrades to each environment.
Chris