This is the first post in a series of tips on working properly with Magento E-Commerce in an Enterprise environment. Here we’ll define enterprise as an environment that generates more than $30,000 in sales/month and/or requires multiple servers to sustain the existing traffic.
The first element of something being Enterprise is that the stakes are higher than they might be in a smaller store. A problem in production can cost thousands instead of hundreds.
The second classification deals with scale. An enterprise solution should be able to scale to multiple frontend & database servers with automated administration. This series will attempt to cover some Magento best practices as you scale into the enterprise.
Plugins are a critical piece of the Magento ecosystem. They help you extend your store and build in custom functionality external to the core code. I’m going to cover a few do’s and dont’s on Magento extensions.
- The first thing to note is to actually use extensions to integrate custom functionality instead of implementing it directly in core code. Magento core code should NEVER be edited. An extension is your supported way to override core code in a safer manner.
- If you’ve purchased an extension from a third party vendor, DO NOT edit the extension files. It’s often simple to go in and make a quick edit, but it could make the extension un-maintainable as future updates are applied.
- If you decide to break rule #2, make sure to properly version control your changes just like you were managing your own code base. This will help you to merge in new extension updates and make the best of a bad situation.
- Prior to purchase, contact the extension provider to ensure the extension will work in a multi-server environment and what steps you may need to take to facilitate that functionality. I recently had the chance to work with a search plugin that was overloading the database because it was running a separate search engine on one server. Don’t assume your extensions can scale. Ask and test thoroughly.
I could and probably will write a full post about version control and why you should do it, but for now will only hit on the key points. Version control, like Git and SVN, are tools that allow you to track code changes and merge those changes, partially or in full, into the main code base. Key benefits are:
- Version control allows you to rapidly find the source of bugs by tracking exactly what code was put in then. There’s a massive production problem on January 10th! What code was checked in on the 9th? This alone makes version control worth the time you’ll put in setting it up.
- Version control allows distributed teams to work on large projects together. If Developer A is working on updating the product view in a category and Developer B is working in the same files, tools like Git allow developer A & B to push changes, not files, to the working code base. Git will merge those changes in properly instead of having developers overwrite files forcing a messy manual merge.
This part is critical. 90% of the developers in the world consider their code perfect, bug free, and error free. It’s also pretty common for technologists in general to feel like they’ve found the most efficient way to solve a problem. While having a single developer work on a single project might seem to make sense from a cost standpoint, bringing in peer, or better senior code review, will help lower overall project costs as code quality goes up. It will also lower the amount of technical debt involved with your projects and eliminate possible refactoring later on.
I’ll cover more on code review later. For now, the fact that you’re considering doing it is a big step forward.
It’s far too common to leave QA off the table on smaller development teams. It’s expensive, time consuming, and there’s often nobody around to do it. Quick tips on QA.
- Do it! No excuses. Your clients will thank you later even if they’re grumbling about the bill.
- Have someone dedicated to QA or train someone NOT involved with development to do QA. If you’re a tiny shop, your assistant, designer, or someone who fills another role may need to double as QA. Just make sure it’s from an end user point of view, not a developer’s.
- Have a written set of test cases built for your QA. In Magento, I’ve found a simple spreadsheet can work wonders in making sure everything’s been done. This is a very basic piece of advice but it can help to ensure nothing is missed.
The biggest problem in application testing is ignoring things that we “know” are working right. The steps above will help you avoid that problem and ensure the utmost quality in your end product which will, in turn, make managing Magento in the enterprise that much easier.
Check out the next article in this series at the link below: