search

davidalger / capistrano-magento2

Magento 2 specific tasks for Capistrano 3
https://rubygems.org/gems/capistrano-magento2
Open Software License 3.0
228 stars 75 forks source link

Enable all modules on deployment #123

Closed dooblem closed 5 years ago

dooblem commented 5 years ago

Hello,

Just seen #70 .

We are frequently having problems with developers forgetting to commit the config.php file.

If the purpose of keeping config.php in version control is just to be able to disable modules, why do not use config.local.php for that ?

If I remember, when deploying to magento cloud, they are just simply running "module:enable --all".

Thanks in advance, Marc

hostep commented 5 years ago

If the purpose of keeping config.php in version control is just to be able to disable modules, why do not use config.local.php for that ?

It's not only for keeping track of disabled modules, but also for the sort order of modules. The ones on the top get loaded before the ones on the bottom.

Also: as far as I know, the config.local.php file is only being used in the Magento Cloud environment and was deprecated in Magento 2.2.0. Or am I mistaken?

If I remember, when deploying to magento cloud, they are just simply running "module:enable --all".

Indeed, they do that for some reason, probably to make sure all available modules are present in that file and are in the correct order in case it wasn't committed properly, but afterwards, they restore the config.php again with the disabled modules as before, see here.

Since you still want to be able to keep disabled modules disabled after a deploy.

We are frequently having problems with developers forgetting to commit the config.php file.

We run into this as well, sometimes after performing a composer update or when merging branches and getting conflicts and then somehow some developer forgets to put that file in a correct state after fixing the conflicts. You need to educate all developers about the importance of this. It will still happen just because people forget or are in a rush. There might be some way to check in a pre-commit hook in your VCS system to see if that file is correct, but you'll have to experiment a bit and it will probably cause some slowdowns for every commit. Or if you have some sort of automated pipeline setup with a testing phase, you can probably detect an incorrect file as well over there.

dooblem commented 5 years ago

Thanks for the explanation. In fact I do not see lots of projects having the need of disabling modules (at least on our side). Feel free to close this. Would you accept a pull request with a config option doing just the enable --all ?

davidalger commented 5 years ago

Would you accept a pull request with a config option doing just the enable --all ?

Probably not, as much of this tool is built with the assumption that config.php is committed to the repo and does not change on deployment.

Also: as far as I know, the config.local.php file is only being used in the Magento Cloud environment and was deprecated in Magento 2.2.0. Or am I mistaken?

@hostep I believe this is correct. config needed for SCD to run (without a database connection) is stored in the config.php file and I believe their deployment also no longer always runs module:enable --all. It might in some scenarios, not 100% sure on that point.

dooblem commented 5 years ago

To my knowledge, and confirmed by @hostep "here" link above, module:enable --all is run every time but with a hack to restore the "local/specific" project config.

With that for offline SCD ?

Regarding the SCD without database connection we gave up this deployment complexity: composer install + SCD + di:compile is done on front1, or an offline front, and with a slight hack the other web front get their releases via rsync.

davidalger commented 5 years ago

module:enable --all is run every time but with a hack to restore the "local/specific" project config.

Color me clueless as to why they're doing that. Maybe some hack to make sure modules are at least loadable to make sure they don't fail something later? Who knows! ¯_(ツ)_/¯

Yes, for SCD without db connection, all it takes is what bin/magento app:config:dump scopes themes puts in config.php be present (and there is an optional i18n you can dump into there as well). Once that info is in config.php, the SCD no longer opens a database connection, and doesn't need Redis around for cache either. I've got this working in a cloud build pipeline running on Google Cloud for another setup, but haven't done this with Capistrano deploys having not had the opportunity since I work for a new company now which doesn't have any clients using Capistrano deploys currently.

hostep commented 5 years ago

Color me clueless as to why they're doing that. Maybe some hack to make sure modules are at least loadable to make sure they don't fail something later? Who knows! ¯(ツ)/¯

As far as I know, Magento Cloud does that for the reason @dooblem mentioned in his initial post:

We are frequently having problems with developers forgetting to commit the [correct] config.php file.

This is probably to not having their support being spammed by questions regarding weirdness during/after deploy when that config.php file was not in a correct state in VCS before deploying.

But in my opinion, it shouldn't be the task of the deployment tool to try to work around this, but is more of a task for some pre-deploy step to check if the file is in its correct state.