How to deploy SugarCRM After upgrade existing instance to Staging server

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

Parents
  • 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.

       may have some thoughts on this too.

    Francesca

  • Hi  ,

     is right in that there isn't an easy way to accomplish what you are seeking. Each upgrade can potentially include:

    1. File changes, additions, and removals
    2. Database schema changes
    3. Data manipulation

    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

Reply
  • Hi  ,

     is right in that there isn't an easy way to accomplish what you are seeking. Each upgrade can potentially include:

    1. File changes, additions, and removals
    2. Database schema changes
    3. Data manipulation

    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

Children
No Data