Magento – Magento 2 deployment without downtime – are there proven production strategies

deploymentmagento2

We know the recommended Magento 2 deployment process which roughly contains the following steps:

php bin/magento maintenance:enable
composer require <package> <version> --no-update
composer update
php bin/magento setup:upgrade
php bin/magento setup:di:compile
php bin/magento setup:static-content:deploy
php bin/magento maintenance:disable

This process includes a downtime which can take a while depending on different factors like the number of modules, dependencies and of course the included database changes in a version.
While the static content can easily be deployed in non production environment and taken later into production (e.g. container, simlinks etc.), the database schema update is a challenge.

I have read a lot about this issue, for example the answers and discussion to this question: Can you achieve zero downtime deployment with magento2?

There are a lot of E-Commerce sites where continuous deployment is state-of-the-art and a deployment downtime is not acceptable.

Now my questions are:

  • What are your proven production deployment strategies (and architectures) to achieve a zero-downtime with Magento 2?
  • Is zero-downtime deployment only possible if there are no database changes?

And yes, I know that for the most stores a downtime of a few minutes is not an issue and acceptable 🙂

Best Answer

Long story short, if there are database changes there will be downtime since you will need to do setup:upgrade and that will take the application down temporarily.

Currently, we have CI/CD setup on AWS, we build the application (static content deploy, di compile etc) and pack it as an EC2 AMI. Once this is done, we deploy the new images into the cloud keeping the old ones running. At this stage, we have the old version of the website running and new new version not receiving any traffic. Then we enable maintenance mode, do setup upgrade, redirect traffic from old codebase to new codebase and disable maintenance. Now you could say, do maintenance enable, setup upgrade and maintenance disable on the new codebase so the old codebase still processing requests, but the problem is that when you do setup:upgrade, since there is only one database working, both version of the codebase would go down.Doing this approach we achieve a few seconds downtime (the time setup:upgrade takes).

IF you want, I can specify a bit more how we have achieved the above.

Related Topic