Magento 2: Problematic Deploys

The process itself, in entirety, in my opinion, is flawed. It is burdensome. It is gross, and, finally, it is not simplistic.

./bin/magento setup:upgrade
./bin/magento setup:di:compile
./bin/magento setup:static-content:deploy

Sigh. The worst part about this entire process isn’t that it’s burdensome. The problems run far, far deeper.

Cleanup

Magento is very bad at cleaning up after itself and very often you’ll need to:

rm -rf generated/code/*
rm -rf generated/metadata/*
rm -rf var/view_preprocessed/*
rm -rf pub/static/*

This is because if you, for example, disable a module, Magento might forget to cleanup a file that has traces of compiled code from that module. Also, before anyone claims this is the fault of 3rd party modules, this happens with core modules, try disabling Magento_Inventory* modules and look at all the files it forgets to clean up when running di:compile

Downtime

Because the above processes can take a long time, you need to put the site in maintenance mode for the entire process.

You have to set maintenance mode to:

• di:compile
• static-content:deploy
• and to upgrade the database setup:upgrade

Sure, one could use Blue-Green deployment for handling a part of this…but not really, because a lot of code relies on DB changes, so your site would simply break.

This was a complaint for Magento 1 and the Magento team had a chance to do things better for 2.x, but instead they made the problem worse.

Separate Servers

It is not uncommon to load-balance your Magento instance or to even have a separate domain and admin server for security reasons.

With Magento 1, all you needed was a simple NFS share, an Elastic Drive or any of a bunch of other simple solutions to get media and potentially var shared across servers.

However, with Magento 2 the problems get exacerbated immensely, mostly due to the above deploy process.

When the deploy process runs it creates a versioning system, so as an example, let’s pretend you have two servers running:

• mystore.com
• admin.mystore.com

To run a deploy you now need to follow these steps in this order:

On both servers

composer install (if needed)

On any server

./bin/magento setup:upgrade (if needed)

on admin.mystore.com

./bin/magento setup:di:compile

on mystore.com

./bin/magento setup:di:compile

back to admin.mystore.com

./bin/magento setup:static-content:deploy

back to mystore.com

./bin/magento setup:static-content:deploy

This is difficult to handle manually and difficult to get working the way you need with tools like Capistrano. It’s verbose, it’s overly complex and it’s very error-prone.

Composer: Modular design that…isn’t

Don’t get me wrong. I love package managers and handling code in a modular fashion, however, the entire process isn’t approached this way at all.

Instead of offering users a choice of what to install and keeping the footprint small, Magento chooses to install everything by default; the entire kitchen sink and then some extra sinks to be safe. Even worse they enable everything they install by default.

Therefore, every upgrade you need to be extremely vigilant because without giving you the option to enable things yourself, Magento will just install and enable, by default, optional features that may very likely break your site.

Examples:

Magento_CardinalCommerce

Payment 3DS tools, great for some people, not needed at all for others, also, has a number of known bugs that still haven’t been fixed

Vertex_Tax

New tax functionality – great except a lot of people have opted out of Magento’s tax functionality entirely or chosen to use other tools such as Avatax, and if you have chosen to use Avatax it’ll break your entire site – Thanks, Magento!

Magento_Inventory

Inventory is required, right? Except this isn’t the built-in inventory, it’s a convoluted multi-warehouse overly complex inventory system that wasn’t asked for and isn’t needed by most people. Let those who need it, optionally install and enable it. Don’t force functionality that I don’t need down my throat

Magento_Auth, Magento_Braintree, etc

Why do we need the code installed for every payment platform in existence? We have composer, why can’t we install just what we need and go from there? User uses Auth.net, they install that; Braintree, install that…etc

Temando_Shipping

Really? A 3rd party shipping offering that isn’t free and was cancelled less than a year after being forced into the core codebase. C’mon, guys – this is gross.

My point here is moving to Composer offered a real chance for a streamlined modular codebase that only contained the modules that were needed – the rewrite of the code even looks like it was leaning toward this philosophy and then the Magento team simply ignored it. All of those modules can be disabled, so they aren’t dependencies, so I ask again…why?

Installing things via Composer takes time and the more modules that are installed the bigger the codebase. The bigger the codebase the longer deploys take and the less performant the entire site is.

I repeat, the entire process is flawed, and Magento really needs to work on fixing it.