Sensible shop deployment and maintenance

[Traumflug]

My brand new shop, currently based on 1.7.0.0-rc0 is nearing completion, so I'm watching out for a sensible way to do deployment and maintenance. However, wherever I look I get the impression that "everybody" does maintenance on the running live shop. New product? Go to the live shop's admin panel, enter it and cross fingers it works. New module? Click 'install' and cross fingers it works well enough to keep the shop running. Does not work? Well, too bad, call your admin, cross fingers and hope customers come back next week.

 

For me it's hard to believe professionals actually work this way, always operating on the living hearth or putting the shop into maintenance mode for hours.

 

Now, I'm not that good in having luck and crossing fingers, so I'd like to test such deployments locally before going public. Along these lines: install, test, fix, test, fix, test, test, test, automatic synchonisation local <-> public. Automatic, to minimise chances for failures.

 

Obstacles I recognized so far:

 

- The site's URL is stored in the database. Which means, a database working here doesn't work there and automatic adjustment this is non-trivial.

 

- Site design is partially stored in the database, too. Which means, changing CSS, templates, hooks and such stuff requires synchonizing the database as well.

 

- Site contents (pictures, upload, etc.) isn't cleanly separated from code. At least there is no folder "data" which clearly seperates code from content.

 

- Site has to be put into maintenance mode during synchonisation, which is again stored in the database, so doing this from a remote command line is non-trivial as well.

 

Anything else one has to take care of in addition to running 'lftp' or 'curlftpfs' & 'rsync' ?

 

 

[Dh42]

This is pretty much how all systems work. You need to develop a flow that you are happy with. The size and scale of the site will help dictate your flow from pushing staging to live. 

[Traumflug]

So people do test before going live. Glad to read this :-)

 

And there are no helper tools? Looks like it's high time to develop some :-)

 

For example, deciding wether a shop is in maintenance mode could be well decided by existence of a file instead of looking up the database. Same procedure for those doing it from the admin panel, a simple file push for those doing it from the remote command line. I could craft a patch for this. Are there chances to get such stuff into the distribution, like: are people interested in such helpers?

[Bill Dalton]

Here is what I use, best $75 I ever spent,

 

http://www.presto-changeo.com/en/105-test-site-creator.html

 

And for quickly making a back up just in case,

http://www.presto-changeo.com/en/prestashop-modules/37-automatic-prestashop-backup.html

[Traumflug]

Good. Crafting that change to store the maintenance flag not in the database, but by existence of a file, wasn't that difficult, it's already done.

 

Here we go: http://forge.prestashop.com/browse/BOOM-1504

 

With this patch it's as simple as pushing a file the the (public) server to put a shop into maintenance mode. Removing the file to do the opposite. Fully transparent in the admin panel GUI or by any other tool reading/writing configuration values, all these won't recognize the distinction.

 

If you like this approach, comment/vote on that bug/enhancement report. Prestashop developers want to read your feedback.

[Traumflug]

Next step towards automatic shop synchonisation: allow independecy from the shop URL stored in the database. For obvious reasons, this works for mono shop mode, only.

 

Instead of removing that storage I decided to add a specific keyword, '*automatic*'. If one enters an actual URL, behaviour is unchanged. If one enters this keyword as shop URL, the shop will run on any domain. Entering in the back office like this:

 

(one can set SSL domain to '*automatic*', too)

 

Code and feature request is here: http://forge.prestashop.com/browse/BOOM-1529

 

Edited September 21, 2016 by Traumflug (see edit history)

[Traumflug]

Next step: seperate code (and theme) from contents. Partially this meant just some changes in defines.inc.php along with the corresponding file movements, partially this required code refactoring.

 

See http://forge.prestashop.com/browse/BOOM-1560

 

With these two patches applied, all shop content files are inside content/, so one can back up just these, use a different backup mechanism for code vs. content or roll out code changes without touching content.