6

I see very little existing posts ANYWHERE about best practices for managing upgrades so I'm hoping this helps me and others.

I have 2 Magento Environments:

  • Production/Live: Running 1.7.0.0
  • Development: Copy of Production which I have on a separate clone of the production server.

I wish to upgrade my production site to 1.9.2.0 so this is what I've done so far.

  1. Upgrade development instance: I've followed Magento best practices for conducting an upgrade as per here http://devdocs.magento.com/guides/m1x/install/installing_upgrade_details.html

  2. As part of the development upgrade I'm tracking all changes on dev via git so I have full file version history on dev now.

  3. At this point I'm now happy that Dev is stable and I'm ready to upgrade production.

Here's the point I'm stuck on. What I've typically seen on any posts/tutorials related to this is that I should rinse and repeat the steps I've taken on dev again on production. Well that would be fine if it hadn't taken me a week to update the dev environment! If I need to go through the same process again in production it will involve a lot of downtime that I can't afford.

So what I was thinking of doing was the following:

  • Backup live - (filesystem and DB)
  • Move a copy of the dev file system over to production (separate web root)
  • Hook up a copy of the live DB to the dev codebase on production
  • Load live url - I'm hoping this will upgrade the production DB to 1.9.2.0
  • Copy /media from backup of live
  • Tweak a few settings in Admin that I would have previously setup on dev

Does anyone foresee any issues with this approach? It will mean not having to manually tweak the live codebase to match the steps taken on dev which will dramatically shorten the downtime required for the switchover.

Any thoughts on this greatly appreciated.

As part of my tasks on dev I maintained a changelog as there were quite a lot of small tweaks required to the source of my theme to ensure it worked correctly with 1.9.2.0.

1 Answer 1

7

Use a version control system (like GIT).

  1. Put the "old" code in your version control on your dev environment
  2. Upload this to your production (I think VCS folders only should be sufficient, e.g. .git folder in root)
  3. Commit the new code (upgraded to CE 1.9.2.0) into the repository on your dev environment
  4. Set the maintenance.flag on your production env
  5. Pull the new changes in on your production environment (e.g. git pull
  6. Clear all caches
  7. Run the website once for the DB upgrades to be applied (see here how to enable the website temporarily for your IP only)
  8. Remove maintenance.flag

Why simply uploading won't (always) work:

  • There can be files removed in between versions. Simply uploading a new version over the old files will not remove these files.

Why you do not need to copy your dev DB to production:

  • Magento works with DB upgrades through scripts (files). This is why an upgrade is portable through files and thus through a version control system. Is is not necessary to 'redo' the upgrade on production in order to get the DB modified. Once the new files are pulled in, Magento will run all DB upgrade scripts and the result will be the same as on your dev DB (only with production data).

How to 'transport' local admin/config/DB changes:

  • Make use of Magento's upgrade scripts mentioned above by setting up a small custom local module (like Mynamespace_Basesetup module) and configure it with a setup resource. Now put your config changes in upgrade scripts ($installer->saveConfig( 'config/path/tochange' , $value [, $scope = 'default' [, $scopeId = 0]] );)
1
  • Can we use similar approach for upgrading from 2.2.x to 2.3.x as well from dev to live or anything needs to be changed?
    – cnu
    Commented Feb 25, 2020 at 3:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.