1

I've read Magento upgrade instructions that describe setting up the new version, then moving the customization from the old version to the new install (oversimplification).

I was wondering if people could recommend a process for possibly accelerating/automating through git merges migrating from old to new? Is that practical? Or, is this going to be mostly a manual process.

0

Upgrading, yes, Magento already performs installer scripts to apply DB and/or data changes. If you are "doing it the right way™" you should have a local copy for reach dev, a development environment, and a staging environment. If you are a one man operation, staging may be overkill, but as easy and cheap as it is these days to spin up a cloud server there's really no reason not to.

Simply apply the .sh patch or even a fresh thx and overwrite on top of your installation from your local instance, create a new git branch, and test away. There are many testing frameworks to utilize like selenium, magetest, unit tests, etc. to throw out your now patched code base. If asks all, then commit the branch, and if you are doing continuous integration, you shouldn't need to do much else, as to treat it just like deploying a commercial or local module.

The most difficult part is regression testing, make note of what the upgrade is fixing/adding/removing, etc. To help narrow down pain points to focus more on. And there's always good community efforts to help others with upgrades and patching on here at MageExchange.

But with that said; security patches coming in various flavors requires a bit more of a manual process. Since Magento usually gives patches in an "supposed" easy way to apply them. Most of the patches are just the same bash .sh scripts that wrap the Linux patch command while embedding the generated diff changes. You can cherry pick the diffed embeded code out and store it in Git or such & use a means like a webhook to trigger applying them with patch.

One thing computers are great at doing is repetitive tasks, anything doing twice is worth automating. Hence the reason everyone loves & strives for clean readable code. Plus you should be coding as the next guy to inherit the technical debt, is a psychopath and knows where you live. 😀

Further reading: - http://molotovbliss.com/magento-modules-post-deployment-uninstall-downgrading/ - http://molotovbliss.com/rules-of-magento-club/

  • I do have a dev and production, also a test/staging that I rarely use (1-man shop). Your instructions are interesting... so many upgrade instructs tell me to create a clean directory, install the new Magento there, then copy my changes over. So the approach you describe should work? What about the recreating my template on the new base in 1.9.x (I'm moving from 1.8) – MarkE Jan 26 '17 at 4:33
  • If your template has been setup regarding the best practices approach you should only be modifying the bare minimum so that way the template fallback system would use the base/default path as much as possible. This minimizes the amount of work needed to upgrade. It's why it is not a good idea to just copy over the entire template over into your own, and leverage a local.xml layout file as much as possible. See magentotherightway.com/#layouts – B00MER Jan 26 '17 at 18:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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