Ecomerce maintenance environment - Prestashop

Question

I took a service to support an e-commerce on the Prestashop platform.

I found the environment configured this way:

The main application files are in bitbucket. To do the maintenance, I change the files via git and do the deploy of Bitbucket to the server where the application is.

The problem is that, in the administrative area of the site, when a plugin or module is installed, both source and database files are changed, but the files are changed on the server and not in the bitbucket and, in addition, the git does not manage the database.

I would like to know whether there is an environmental model or some solution to this problem.

Answer 1

This is an old question that even in the official Prestashop forum no answer can be found.

To apply the commits in the modules you will have to create administrative use policies where several useful functions would be blocked, among them, modifications in themes, modules, overrides among others.

Whenever you need to add some module, Theme or other function within the situation you described in the question, you will have to do it first in the production environment. That is, it would no longer be allowed to control this through the Prestashop Backoffice if you want full control over GIT.

This also applies to other modular platforms.

You’ll have the advantage of being able to control it through git, but the platform loses an important part of the resources. Because the attraction of this type of platform is so that laymen in programming can install resources without knowing anything about programming.

But the reality is that a module doesn’t always work well when updated. Sometimes they cause failures where you need a professional and experienced programmer to solve them. Ultimately, the feature that allows a layman to install things without knowing what he’s doing becomes a knife of two.

About the database, how to control the versioning of the structure (schemas) is a matter of opinion, but usually a schema dump is made and saved in a common text file. So you can add the structure to the git control. There are those who also prefer to add the data (together or separately from the schema). It depends a lot on the situation. Particularly save essential parts of settings. The data itself, the ones that consume more space like order tables, customers, logs, products, etc, I prefer not to keep together even in git. Except separately. This is because if you always save all the data at each commit, in a short time the space in the storage media reaches the quota limit and it is very easy to do this because a simple store, small, usually has just over 1GB of data. If you do 5 commits in a day, it means + 5GB of database data only and most of the time you don’t even need to have all that "duplicate information".

Tip, Since you’ve already picked up the project with this structure and because you’re asking this kind of question, I assume that the previous manager didn’t give you instructions. Based on this, I advise to do a thorough checkup between versioning and the data that are in production. Most likely there should be modifications to the production environment incompatible with what’s in git.

So just take care of it. I suggest pulling everything from production via FTP, or any other viable medium, and generating a new commit of everything with your new administrative and management policy, if you want to continue controlling it through git. Document this well and provide documentation to the store owner so that the day you fail to provide support, the next programmer can know how to proceed.

Of course, before anything else, have a meeting with the owner to explain the situation. From there, formalize in contracts and proceed with the service as agreed because all this is service, it is much more labor and must be burdened. If your support contract doesn’t include that level of detail, you can go out on a limb, working way over budget. With time it builds up and weighs to your side.