Everyone who has worked with Magento for a time knows that Magento uses indexers to achieve higher performance than it might otherwise achieve when dealing with certain complex data types. A list of these indexers can be easily found by looking at the output of bin/magento indexer:status on the CLI. These indexers usually support both synchronous (Update on Save, also known as realtime) and asynchronous (Update on Schedule, also known as schedule) modes.

This guest post by Erik Hansen will cover how to use the capistrano-magento2 Capistrano Gem to deploy Magento 2 on any static infrustructure design of your choosing. A Little About Capistrano Capistrano is a a tool used to run scripts on multiple servers, typically with the purpose of deploying code changes to those servers. Capistrano works well with both single node deployments as well as multiple node deployments that include separate application and database servers sitting behind a load balancer.

Magento 2 ships with a complete testing suite out-of-the-box. These include a complete set of operational unit, integration, and static tests. The simplest of these to run is probably the unit tests, having all necessary components setup and in-place automatically after installing Magento 2 successfully. Here I’ll show you how to run the full tests suite, run each type of tests independently, and also how to run a small portion of the unit or integration tests if need be.

There are two common ways to install Magento 2. One is to simply clone the Magento 2 GitHub repository and install. This is great for contributing, but not so much for starting a new project. Magento released the Magento 2.0 GA this Tuesday, November 17th at the MagentoLive Australia event. Very exciting stuff! With that they threw the switch on the new meta-packages server which hosts all you need to install Magento 2 with only a set of authorization credentials and composer.

Using the file-system for a cache backend on a production Magento site is just asking for your site to run slowly. But what about development? Should you use a file-system based cache there or not? Well, that is ultimately up to you, but you’ll be able to work faster if you develop on a stack with a fast cache backend. My personal favorite is currently Redis. Magento supports this out of the box in later versions of Magento 1 as well as in the developer betas of Magento 2.

By now the overhaul of the indexer system used in Magento Enterprise Edition 1.13 is fairly common knowledge, especially amongst those that have the privilege to work with it on some large builds. I’ve had the chance to work with it a fair bit on a rather large project currently still in the oven over at Classy Llama. This project has over 40 million product pages and 5 million parts in inventory!

In some rare cases there is functionality that clients need me to develop that requires disabling some built-in observers due to them conflicting with the desired custom behavior. There are also some that aren’t needed by everyone that you can gain a performance boost from by disabling. I have previously disabled a few observers by rewriting the observer model and returning NULL inside the observer method. Brought to light by Colin M.