Jump to content

understanding modules and parts of /install folder in designing own own git repo deployment


Recommended Posts

We don't want to use the 1-click upgrade functionality as it doesn't suit our needs. We built a deployment script to help deploy to our development, staging and production servers from our own custom git repository. So far in testing it seems to work well for us. However, we would like to understand the differences and dependencies related to the official PrestaShop git releases, their included modules (in /modules and /themes/default-bootstrap/modules), the contents of /install and the upgrade process, better.

1). We think that we JUST need to track and release, as part of our own upgrade process, any modules that we modify, our own, or those that are not part of official PrestaShop Marketplace. We think this as we can selectively use the standard Modules update process to upgrade all that we don't include in our own git. So, we are considering not including most of those modules found in PrestaShop releases in /modules and /themes/default-bootstrap/modules leaving that to the standard Modules update process included in PrestaShop. Does this make sense? Do both those locations get updated as part of the standard back office Modules update process?

 

2). Following that, if we see that all modules are up to date (via the standard Modules upgrade functionality found in the back office) just prior to our own git deployment, and then we deploy (without most of the modules in /modules and /themes/default-bootstrap/modules), and then again we use the back end standard Modules update process, will that be good practice?

 

3). Won't the standard Modules update process ensure all those modules that we didn't include from the PrestaShop git release get properly upgraded?

4). It isn't just a matter of a whole bunch of extra code (from the modules we don't want to track in our own git repo), but rather will those modules could also be stale versions by the time we deploy. If a stale version of a module (say version 1.1) were deployed over a fresher version (say, 1.2) that could be troublesome, especially if the module had made database changes as part of the upgrade from 1.1 to 1.2 already. We would like to not have to write a deployment routine to handle this if possible.

 

4). Finally, if we base our own git deployment on a PrestaShop git release (omitting what is in /install), and we also synchronize and update SQL as part of our deployment (based on what we find in /install/upgrade/sql) is there something we are missing? Do we need to do anything else or consider what is in any of the other parts of the /install folder?

 

I hope I've explained what we are wanting/doing well enough so that some of you can share your knowledge a bit so we can design an upgrade process that meets our own deployment needs.

 

Thank you so much, in advance.
 

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...