Quality Assurance: Why our Magento developments are top notch.

Michael Angelo Groeneveld Michael Angelo Groeneveld
30 - 09 - 2020

Our customers get nothing but the best quality development from us. But how do we make sure we get it right every time? In this post we describe our quality assurance (QA) process within El Niño regarding the development and maintenance of our Magento 2 web shops.

Automatic monitoring

We currently use two different external services to monitor the state of our Magento shops:

  • Sentry: Tracks application and database errors and are sent to an online environment to alert us pro-actively
  • NewRelic: monitors the uptime and speed of the web shop and triggers an alert when the conditions are not optimal

Both systems are linked to our Slack environment. This means that everybody involved in the project gets a Slack notification if an application error occurs and/or if there’s a hosting issue that needs to be solved. We pro-actively look at the alert and take immediate action to solve the issue and/or contact the relevant parties to have the issue solved (like for example the hosting company).

We collaborate with two renowned hosting companies located in The Netherlands: Byte and Hipex to guarantee a stable hosting environment and good integration with our monitoring systems. If the customer prefers to use a different hosting company, some auditing will take place to ensure our uptime and stability requirements are met.

Development and deployment

The source codes of our projects (including Magento projects) are hosted on a self-hosted Gitlab server. This ensures that the changes developers made to the code are always up to date and in sync. Changes to the code are automatically versioned so that we can easily roll back to a specific version of the code if we notice that a deployment causes (too) many problems and/or errors.

Having the code on Gitlab enables us to easily manage various environments:

  • Development environment: includes the latest code for new features and is actively updated with minor changes
  • Acceptance environment: is less active and used to share the progress with our customers and other stakeholders to get approval before putting changes to the production environment
  • Production environment: This is the live environment in which the shop is exposed to the public

Changes are pushed to the production environment by pressing a button within the Gitlab environment. Changes can be rolled back if necessary, by also pressing a button. Changes can be pushed to production within minutes and can be rolled back within minutes too. This setup also ensures that there are no differences in the code between the acceptance environment and production environment reducing the chances of having environment dependent issues.

Documentation

An important part of any maintenance of a system is the documentation. Documentation is important because this ensures that all parties are up to date with any (business) logic involved in the shop and can easily assess whether new features can have a (negative) impact on this logic.

Gitlab has the option to maintain a wiki for all projects. We actively use this functionality to document general aspects of the project, this can include information about:

  • Background information regarding the customer
  • General priorities of the customer
  • General information about the project (goal, stakeholders, key functionalities, etc)
  • Technical information about the project (versions, dependencies, hosting environment(s), etc)
  • Important business logic implemented in the project
  • External parties involved in the project
  • Key contact persons and their details involved in the project

This wiki is continuously updated to ensure that(new) developers working on the project can read through the information and have a good idea of what the project is about and what the important factors are that have to be taken into account during development.

When implementing new big features, this wiki is checked to prevent compatibility issues and conflicting interests/ functionalities. For every (new) feature, an issue is created explaining the goal of the issue, background information regarding the issue and any (external) dependencies that must be considered during development. Changes related to the feature are also tracked and linked to the issue. These changes can be related to the code created for the issue but can also include any feedback we got from the stakeholders during the implementation process.

Every version and release of the code is also documented to ensure that it is clear what new functionality is shipped with the release. This enables us to track down a certain release if there are any issues in functionality within the shop. All the documentation and issues stored on Gitlab can be shared with external parties and/or with the customer if necessary.

Testing

Magento 2 comes with a large collection of so-called unit tests that test the core functionality of the shop. These unit tests are executed every time a new version of the code is pushed to our Gitlab server. The code can only be released to acceptance or production when all these tests succeed.

When implementing new functionality, we can also write unit tests to ensure that this functionality is always automatically tested for every update done to the code. If a test fails, the developer gets notified via Slack, e-mail and the Gitlab interface so that the issue can be solved immediately so that the feature can be deployed to the environment.

If required, end-to-end tests can be created which basically automatically tests the interface of the web shop (by for example viewing a product, adding the product to the cart and finalizing the order). If this test fails, then the same alerts will be triggered and prevents the developer of putting broken functionality to the production environment.

The types of tests that are implemented greatly depends on the nature of the project, the complexity of it and the wishes/requirements from the customer. It is possible to (automatically) test only certain (core) functionalities.

We also employ a couple of testers who manually test the new functionality before pushing the changes to the acceptance and production environment. The testers also ensure that the initial requirements set by us and/or the customer are met, and certain edge-cases are checked.

Updates and Security patches

Regularly (once per 1 – 2 months) security breaches are uncovered for Magento. To solve these breaches, security patches are published and distributed by Magento. El Niño automatically gets an update regarding these patches and installs these patches as fast as possible (depending on the characteristics of the breach and the consequences of installing the security patch). The time spent to install these patches are invoiced on an hourly basis (a simple patch can be installed within 15 minutes; more complex patches can take as long as a day).

Browser support

We follow the international standard, as set by the likes of Google and Facebook, regarding the support of browsers. This means we’ll support the latest major version of Google Chrome (which updates automatically). Also supported are the current and last releases of Firefox, Edge and Safari on a continual basis.

Cookies and JavaScript are supposed to be enabled.

An optional compatibility mode should be turned off. New features are tested in different browsers using tools such as browserstack.com. This is mainly relevant to changes made to the interface of the web shop. The features are also tested in mobile and tablet view to ensure the interface works on different types of devices.

Third-Party extensions

The advantage of Magento being an open-source project is that there’s a large community of developers / companies that create Magento extensions that can be installed to easily add functionality to an existing shop. This large community of developers also means that the quality of the extensions (functionality wise but especially code wise) can vary. We have experience installing and maintaining many extensions and we have a list of Magento extension suppliers that generally offer high quality extensions. We always advise our customers to purchase extensions from these suppliers to reduce the risks of introducing bugs into the shop.

If third-party extensions contain bugs, we generally ask the suppliers to fix these issues for us. If this isn’t possible, or this can’t be done quickly, we can always fix the issue(s) ourselves

With all these measures and steps in place, we know we’re doing what we can to ensure we deliver quality development. Because for us, the customer’s trust and peace of mind comes first. Whether it’s in our creative and innovative solutions or in the fact that we deliver shops they can count on.

Michael Angelo Groeneveld. Michael is leider bij El Niño en is verantwoordelijk voor de interne en externe kennisontwikkeling gerelateerd aan webtechnologieën. Michael Angelo Groeneveld. Michael is leider bij El Niño en is verantwoordelijk voor de interne en externe kennisontwikkeling gerelateerd aan webtechnologieën.

Deel deze blog

Jouw partner voor digitalisering  en  automatisering

Bedankt voor je bericht! We nemen z.s.m. contact met je op. :)
We willen graag je naam en e-mailadres weten om contact op te kunnen nemen.

Laten we samen een keer brainstormen of vertel ons wat over jouw uitdaging. Laat je gegevens achter en we nemen z.s.m. contact met je op.