setup:di:compile cause any problems if I execute it in production? I fear that my customers will see errors after I call these commands.
You should definitely set Magento to maintenance mode before running
setup:di:compile in production.
setup:upgrade clears both the
pub/static folders which will most likely result in your customers seeing an error page. Since they can't use the store anyways it is best to present them the maintenance page so they know the store will be available in a short time.
If you are concerned about downtime you can setup a build system where you can run
setup:static-content:deploy while your production system is still running and only run
setup:upgrade --keep-generated while in maintenance mode.
You can read more about setting up a build system here: https://devdocs.magento.com/guides/v2.3/config-guide/deployment/pipeline/build-system.html
An easier, but more "hacky" way could be building your "new" production system in a different folder and then pointing your document root with a symlink to the new production system after you're done. This can be done with only a few seconds of downtime.
You can read more about that approach here: https://www.hypernode.com/blog/time-saving/how-to-choose-the-best-method-to-deploy-code#example
In production mode
setup:upgrade will clear all static content, this could cause problems for any customers browsing the site who may end up with a nasty error message.
I always switch to maintenance mode before doing this and use a nice custom maintenance page to tell customers what is happening.
I find a deploy script useful to run all the compile and static content deploy commands that I need to get the site ready for production again.
Both answers are correct but it doesn't necessarily mean that you have to be OK about enabling the maintenance mode every time you want to run
setup:di:compile to deploy new changes. If you are talking about a big ecommerce, this is going to affect customers and sales.
To prevent that, use deployer.org or a similar alternative.
Deployer.org is a PHP-based routine to run deployments. The main different is that Deployer.org deploy your changes on different folders called "releases".
Let's suppose you made 3 deployments in the past, and you are deploying a new one. you will have a folder structure like this:
A few comments:
current/is a symlink which will be always pointing to the latest release. This is key, the symlink will be automatically moved ONLY when your deployment is fully completed. In consequence, you don't have to enable the maintenance mode.
4/is the ongoing release. At this point,
current/will be pointing to
3/. Once your routine finish,
current/will be automatically changed to
4/and your website will works as usual PLUS your new changes.
- If you configure Deployer.org to keep 3 releases,
1/will be automatically deleted once
4/is fully completed.
- If something goes wrong, you can rollback to a previous release very easily... Without deleting the latest! (Works in a similar way to
- Deploy.org allows you to set how many releases you want to keep alive. If your free disk space is too small, you can set just 1 release and everything will work fine.
- Commons Files and folder between releases can be stored into the
shared/folder. This is usefull to save disk space. For example, you don't what the save your media files on every single release folders. The deployment routine won't touch your shared folder, so anything won't be affected.
One important thing, even using deployer.org I suggest you to enable the maintenance mode if your changes includes SQL queries... Like creating tables, inserting/updating/deleting data and some other things using [data patches] and DB schemas.