Thread Details
  • State Not Answered
  • Replies 3 replies
  • Subscribers 353 subscribers
  • Views 969 views
  • Users 0 members are here
Forum Actions
Related

best practices for upgrades?

Francesca Shiekh

For the past 12 years my process for upgrading Sugar has been:

On my Development Server:

  • Ensure that I'm running the latest PHP version supported by both the current version, and the one I'm upgrading to.
  • Ensure that I'm running the latest MySQL version supported by both the current version, and the one I'm upgrading to.
  • Upgrade Sugar 
  • Ensure that Elastic Search is on the version supported by the upgraded version.
  • Test and Debug document any changes in detail

Repeat on my TST Server
Test and Debug again as needed.

Repeat on my PRD Server
Test and verify once more

Repeat on the two integration testing Servers.

We fell behind and are still on Professional v11 so, based on the Compatibility matrix

 **  CURRENT Sugar Ent 11 Sugar Ent 12 Sugar Ent 13
Version Pro 11.0.5 11.0.5 12.0.3 13.0
PHP 7.3.18 7.3, 7.4 7.4, 8.0 8.0, 8.2
MySQL 8.0.26 5.7, 8.0 5.7, 8.0 5.7, 8.0.32
Elastic 7.16.1 7.16.1 7.16.3 8.4.3

it looks like the process for upgrade will be:

  • Backups
  • Sugar Conversion to Ent v11.0.5
  • Test and Debug customizations document in detail
  • Backups
  • Upgrade PHP to v7.4 
  • Upgrade Sugar to Ent v12.0.3
  • Test and Debug customizations document in detail
  • Backups
  • Upgrade PHP to v8.0 
  • Upgrade to MySQL 8.0.32 
  • Upgrade to Elastic Search 8.4.3 
  • Upgrade Sugar to v13 
  • Test and Debug customizations document in detail
  • Backups

Then repeat ALL that for EACH of the other 4 servers
(TST, PRD, and the two integration testing servers)
reapplying/copying the custom code changes needed for compatibility etc...

As you can imagine this gets to be a VERY time consuming process for me.

It would be nice if I could just "copy" my fully tested and ready to go TST version to PRD and the two other testing instances.

But, while that is relatively easy for code changes, each upgrade includes not only code changes but also DB changes and, of course, my TST and PRD data are not the same and in certain cases there may be modules in the development and testing environments which are not yet deployed to PRD (which is what has been holding us up these past years).

So my question is... how do you do it?
How do you upgrade multiple instances whose databases are not necessarily identical?

Surely Sugar doesn't upgrade one cloud customer at time?
What's the time-saving trick?

Thanks,
FrancescaS

PS. lesson learned:

DO NOT fall behind on your upgrades! You WILL regret it.

Parents
  • 0

    Hi Francesca,

    My apologies if any of this is redundant but I figured I would start by describing how I would set up my environments.

    My first suggestion would be to implement a CICD flow using Git if you don't have one already. I would create a repository and dedicate a branch per deployment. Normally, I see branch structures similar to this:

    • prod
    • training
    • sit
    • uat
    • dev

    Given this setup, a normal code promotion flow for a new feature would be: dev -> uat -> sit -> training ->prod. There are many ways you could choose to move your code between the actual environments but with a CICD flow, you can create pull requests for features to branches rather than dealing with MLPs or having "copy pasta" between code bases. The biggest issue with any flow is tracking and promoting database changes which is why we developed Migrator.

    Using a CICD flow, you would do the upgrade once locally against your dev branch and commit the file changes as well as the tracked database changes (using something like Migrator) to Git and promote those changes to each branch. The CICD flow will then push those changes to each environment one by one for testing and then you wouldn't have to manually do the upgrade for each environment.

    The best part about a flow such as this is it works for bug fixes, new features, and upgrades. Hope this helps give you some ideas!

    Co-Founder | SugarCRM's 2023 Emerging Reseller of the Year & Fastest Growing Outfitters Partner

  • 0 in reply to Jerry Clark

    ,

    I'd love to talk more about your Migrator, and the suggested Git setup. I think you have my work address, if not PM me and I'll send it to you. I can explain my situation, I may need Upsert's help on this.

Reply Children
No Data