On our servers you can use symbolic links (symlinks) to point to the current release.
The only important thing is you point ~/httpdocs to the current webroot.
~/magento2 = Magento 2 root
~/httpdocs -> ~/magento2/pub
Advanced example, using multiple releases
201904111345 = example of one release
~/releases/201904111345 = Magento 2 root for this release
~/shared = Files not kept in Git
~/releases/201904111345/pub/robots.txt -> ~/shared/pub/robots.txt
~/releases/201904111345/pub/media -> ~/shared/pub/media
~/releases/201904111345/var -> ~/shared/var
~/current -> ~/releases/201904111345
~/httpdocs -> ~/current/pub
~/magento2 -> ~/current
After a Release
We have the PHP OPcache enabled on the servers we manage.
If you change a file, PHP will detect this and re-read the code from disk.
If you switch to a new release using a symlink, PHP will not detect this and keep using the old code. To fix this you have to flush the OPcache.
We do not recommend to clean Varnish after every deploy.
This will cause your shop to become unnecessary slow after a release.
You can flush Varnish manually, here is how to do it.
You may need to clean application caches after a release, depending on the changes you make.
If your application cache is in Redis, here is described how to manage it.
We recommend: Envoyer
When you use a deployment system or a script which connects to SSH, you may experience problems because the environment differs from a manual SSH connection. For example it may be using the wrong PHP or NodeJS version. The following steps help to solve this.
If your deployment system has a configuration setting to set the PHP path, for example in the 'Server' settings, set it to:
If your deployment system has a configuration setting to set the Composer path, for example in the 'Server' settings, set it to:
Put these lines on top of the script for each deployment step: