Magento Commerce Cloud has become the favored Magento configuration in our organization. I thought I would share some things that have been the key to our success.
- Embrace the infrastructure
- Embrace Magento
- Magento has a package loader and you should use it.
- Magento has a patching process and you should use it.
- Magento is tested and optimized for LESS and you should use it.
- Magento Commerce Cloud has a solution for 301 redirects and you should use it.
- Magento has a solution for JavaScript loading and you should use it.
- Do development elsewhere
- Use default processes
- Leverage the tool set
- Use composer sparingly
- Staging is for staging
- Just because you can doesn’t mean you should
Engineers are opinionated. System engineers are no different. They like the way they do it. They have passion. We had to convince our system engineers to acquiesce to the will of the Magento team. There was some initial hesitation and push back, but we decided to align with the Magento Commerce Cloud’s approach. It might have been a little rough at first but ultimately it has paid great dividends for our organization. Things we used to have to manage, stress over, and care about now are afterthoughts. If you embrace it, you can leverage it to your benefit and to your customer’s benefit.
This might sound strange. You are already using Magento so of course you have embraced Magento. We have been involved with taking over a few Magento Commerce Cloud implementations that were struggling and can tell some are not truly embracing Magento.
Every time you stray from what Magento has, your team has to shift focus from solving business problems to managing development, build, and environment issues.
I have seen a number of other companies try to use the integration environment for development. This does not work. The integration environment does not have the horse power to do proper development. There are good uses for that environment but development is not one of them.
Our team has their own virtual machines and/or docker setups for customers. We do our development from our office with the use of a shared database server. Depending on what each team member is doing we may have just one or multiple databases setup for the customer. Each developer has their own application server configured with XDebug and uses PHPStorm to write and debug code within their instance.
We follow the GitFlow process and have individual developers add code updates into feature branches and an integration prime responsible for reviewing, merging, and deploying code to the cloud for QA testing, UAT, and production builds.
The cloud build process allows for developers to add in their own build hooks to adjust the process. From the installations we have reviewed, it seems some development teams try to morph the process to align with their own internal deployment process. Those installations fight against the tide. Each time the Magento Commerce Cloud team modifies, fixes, or improves the build process, these custom modifications fail. It requires that the development team keep doing their own testing on each cloud deployment release rather than actually working on development for their customers.
The default processes work. They are simple. They will meet your needs.
Magento Commerce Cloud bundles in some nice technology and features that we regularly take advantage of. New Relic is a great tool to monitor the performance of your Magento site. Especially with complex builds, since there are a lot of integrations and custom programming, New Relic quickly shows what process(es) is consuming the most resources to help us isolate the problem. Where New Relic helps with the what, Blackfire.IO helps with the why. Blackfire allows you to connect to your running production server and debug an individual session. We have used this effectively to debug the exact problems found through New Relic.
The cloud tools make it simple to spin up a new instance into the Integration environment. While this environment doesn’t work for development, it does work well for giving access to an extension provider to debug and address issues with their code in an isolated environment without impacting any other ongoing development and testing. Add in your own script for scrubbing data clean and the normal hesitation you get when giving access to a 3rd party is mitigated.
This might surprise some. Isn’t composer the wave of the future? Don’t you want to automatically get the latest updates from extension builders? Don’t you want the last code from your System Integrator’s shared custom extensions? In short, nope. You can require an exact version in composer so no unexpected updates happen, but then on every build you are dependent on 3rd party servers to be running and responsive.
Magento 2 has excellent code separation making it very easy to manage extensions. You never want to get automatic extension updates. The system should be fully verified in your development process and approved through staging. This entails knowing EXACTLY what code is in use. If between builds you pull in unexpected new code, your system is no longer fully tested and unexpected problems crop up.
As already mentioned, the integration environment is not for development. That shouldn’t be interpreted as a reason to use the staging environment for development. Staging is for staging. Staging uses the same configuration (multi-server, Fastly, etc.) as production so is a perfect place for final QA and UAT prior to releasing to production. There should be no surprises when publishing to production. If staging is used for staging, there won’t be. Worry free production releases are possible.
Magento has built in a lot of flexibility to allow developers to divest from the Magento default direction in not only code, but tools and utilities. Magento has such a wide audience and enormous open-source community this makes sense. Magento Commerce however is built for the enterprise. Enterprise solutions are already complicated. Magento Commerce Cloud provides the hosting and infrastructure for an enterprise solution. Just use it.