It still amazes me how far behind software development standards and best practises Magento Agencies and Developers can be. I think this is a unilateral issue pertaining to the PHP community in general. But the amount of implementation I see, where using FTP to sync changes into production then manually running deployment commands is mind boggling!

In 2024, there is no reason to not be using a CI pipeline to deploy changes. Github, Bitbucket, Gitlab all include built-in pipelines. Even something as simple as RSYNC and a BASH script to deploy your changes is better.

As a Magento developer, I put a big focus on automating all the boring admin stuff, so we as developers, can focus on changes with actual meaningful business impact. (Unlike deployments!)

Considering you can achieve Magento Zero Downtime Deployments with reproducible artifacts just by using your VCS provider. There really is no excuses not to be doing it. And while your at it, how about adding some code quality & security static analysis tests?

Zero Downtime Deployments

True Magento zero downtime deployments are usually not cost affective, as a lot of prebuilt modules are not built to support it. Instead its more of a minimal downtime deployment, and in the case of no database changes, we can then do a true Zero Downtime Deployment.

So to summarise, Magento Zero Downtime Deployments, are actually minimal downtime deployments. Where the store is only down for less than 30/60s on average, while any database changes apply. Deployments containing Styling / Template changes, can usually be deployed with true Zero downtime.

Zero Downtime Deployments are truly a tool that should be on all Ecommerce stores. As taking a store down for 5-10 minutes, is 5-10 minutes of lost revenue. And having to have downtime, usually slows down development and releases around key sales periods such as Christmas or Black Friday.

Get in touch to talk about how we can implement Magento Zero Downtime Deployments, or if you are an Agency, how we can help you implement Magento Zero Downtime Deployment across all your clients.

Continuous Integration and Continuous Deployment

CI/CD pipelines are another great tool we can implement into your Magento development process. There are usually three main steps, Build, Test and Deploy. Once implemented correctly, they can help improve the velocity, stability and cost of deployments. As well as, removing any bottlenecks around needing senior team members to perform the deployments.

The Build step will normally, take care of building the production application code. In the case of Magento this is running the composer install, di compile and static content deployment commands. As well as any additional steps such as critical css generation etc. Then the build step will package the compiled source code into a compress artifact for the next steps.

Then we move onto the test step, usually this will take the generated artifact and unpack it. Then this runs critical testing, smoke tests, unit tests etc.

The last step is deployment, this usually calls our CD tooling where that will either take care of uploading the artifact to the server, unpacking it, performing any database updates before switching the release pointer. Or pushing our built docker images to the repository and triggering a release.

Its also a good idea to run any static analysis tests, before we run the build step to help keep CI hours down, and reduce cost. We can utilise tooling here such as PHPCS, PHPMD, PHPStan, SonarCube, Snyk and various other analysis tools as a earlier warning to potentially buggy code.

Get in touch to talk about how we can introduce an affective CI/CD pipeline to improvement your deployments.

Merge Gates

A vital part of a good Continuous integration pipeline, is merge gates. These are predefined checks that occur during key parts of the pipeline to assert a result before allowing the pipeline to move onto the next step.

One Merge gate that I like to implement is for the merge to production, is E2E (End to End) testing on the pre-production environment where the tests ensure that all key actions work (Add to cart, checkout, customer account etc). If the E2E tests fail, we then prevent merging to production until this is resolved and the tests pass.

Some of the usually merge gates you can implement are:

• Blackfire.io page load
• Blackfire.io memory usage
• Blackfire.io database queries
• Google Lighthouse Web Vitals
• Varnish cachable content
• Static Analysis Pass

To see how we can help you improve the reliability of your deployments, Get in touch