7

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 :-)

  • I have been wondering this myself because some people just can't handle any type of downtime for development reasons. It would be great if this answer receives some response. I can see in the devdocs that there are tools for the Magento Cloud Commerce platform where they achieve zero downtime while redeploying. – gabtzi Jul 3 at 12:23
  • zero-downtime = you can not run these commands you posted on live system. so with some little research you need to have pre-production system, you push updates from to live... – MagenX Nov 23 at 13:22
0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.