Magento Zero downtime deployment 2

Magento eCommerce availability is one of the criteria considered for the success of your business. It is important to make sure your sales are not impacted due to software deployment activity.

Magento 2, as a legacy PHP application, doesn’t have a real 0 downtime deployment. If you are advertising Zero deployments but you can’t upgrade/remove/install a module without downtime during

it is not zero downtime deployment.

Magento Commerce Cloud runs Magento in maintenance mode during the deploy phase, which takes your site offline until the deployment is complete. The length of time your Production site is in maintenance mode depends on the size of the site, the number of changes applied during the deployment, and the configuration for static content deployment.

Magento official docimentation

Steps to deploy Magento :

  • prepare a package with the new version of the application (static files, di compile). You can do it even locally
  • shut down the running application -> downtime
  • run the database migration scripts -> downtime
  • deploy and run the new version of the application

Let’s take a look at how we can fix that.

Magento needs maintenance mode to run setup:upgrade command. However, his is a core Magento 2 issue. Historically Magento 2 doesn’t follow the best software development practices. They are reinventing their own home grown bicycle.

Why is Zero downtime not possible? Magento has Plugins feature (also the weirdest invention of Magento spaghetti architecture), which kills the Application and can’t control it.

Here is this guy:

, by commenting out these “throw new LocalizedException(“ lines, you can achieve DB upgrade on a live project without downtime. Or log it but not kill. By the way, M1 worked this way but without issues. You don’t need to run any wires command like setup:upgrade/compile/generate/dance with M1.

How setup:upgrade works in the Magento 1:

When you upload the new code onto your web server’s filesystem, the next time that you load any Magento page, Magento will apply the files in the sql\modulename_setup folder in sequence to bring the data_version up to match the module’s version. Without any Localized exceptions…

However, you should review your code first! Sometimes Magento and extension developers don’t follow “software development best practices” only legacy “Magento certified bad practices,” and they can delete fields or tables and break “backward compatibility with old code. To prevent this, you should do Incremental Deployments.

You should always explore changes that will bring down the total Magento deployment. It would be best if you moved it to pre-deployment and post-deployment steps.

The downside is that zero-downtime deployments require more care about database changes. Two versions of your code need to be able to work simultaneously. You can’t just remove or rename fields.

Renaming or deleting a column or table needs to be divided into several deployments. This way, we make sure that the application still works with every incremental change.

However, if the old code needs catalog EAV tables, in the new deployment, you are removing this Magento legacy with simple flat tables without any indexers obfuscation. You should delete EAV tables in the post-deployment step/script (no need to use Magento XML) or during the next deployment when your code doesn’t depend on the old DB structure.

What are our new steps:

  • deploy new Magento version of your server
  • migrate your database to a new version -> setup:upgrade
  • Now your application running with old code but with a new database,
  • replace the old code with the new code. Or run “Sudo service php-fpm” restart if you are relying on PHP opcache during deployment.
  • You’re done!

Note: you should deploy only good code tested on local or on staging. If your code is doesn’t work with 0 downtime deployment, it is not the deployment issue.

There is not the only way to achieve this. But it is the simplest. It is up to you how you will achieve Zero downtime. Deployment with maintenance mode also works for some companies, but you should know the best software development practices and deploy database changes without downtime…

Update: Magento community released a plugin to achieve 0 downtimes. Read more below this article.

It is important to automate every step of the Magento deployment. No matter if you want to deploy your code on every merge to some branch (githook will help you) or trigger it manually.

Comments about this deployment approach from the Magento community:

This is a simple zero-downtime Magento deployment script example. Posting this to make this post bigger for Google and other dictators.

Take a look video about the Magento deployment process:

Magento Zero Downtime deployment module from the community:

Module prevents showing database versions exception when you pull new code to the server. The best idea is to use CI/CD with Docker/Kubernetes. Suggested deployment:

  • get docker base image
  • to enable this module got to App Configuration Options ->Go to Stores->Configuration->Monogo->Zero downtime deployment; Enable module Default value is 0 (No); Enable logger Default value is 0 (No)
  • run php bin/magento setup:upgrade on destination database
  • run php bin/magento setup:di:compile and php bin/magento setup:static-content:deploy on build container
  • deploy a new container

Git Hub Repo:

Thanks, guys. We made Magento 2 greater again together. However, Magento core is still a legacy.

Maybe somebody can donate a pull request to Adobe's official repo.

Magento/APP Cloud Architect. Melting metal server infrastructure into cloud solutions.