Safety in the eCommerce project – how to sleep without worries?

Care to share?

When one’s creating a small or a medium-small e-commerce store – often nobody thinks about such big words like SLA, business safety or high availability. When you’re online store is bringing more and more income every hour of unavailability of software causes a noticeable decrease in money. Moreover, an unstable application could discourage people from further buying on your site.

Technology is important, but stable technology is more important :) It’s crucial. In the last post, I’ve described how we manage SLA. Here I’ll show you a few more global issues connected with business safety and technology safety.

Technology matters

Choosing the right technology could be crucial for business safety. From time to time we make code-audits and security tests of e-Commerce platforms which users are considering possibilities of further development or even have to change. Because there are no possibilities to use the software a little bit longer. In some cases, producer closed support for the platform, in other license agreements slows down or stops our tries. For example the costs of development, license are so big you cannot afford it. Sometimes lacks documentation could be a stopper.

In general – sometimes using proprietary software could be dangerous if you concerns fast growth. 

In small and medium businesses using SaaS platform or out-of-the-box solution will be OK. Costs are under control and you get the fast effect. When the company gets bigger in most cases there will be shown a need for customization and special features. Integrations with external systems or specified pricing rules are good examples of those requirements.

Choosing the software you should check if the licence allows making changes. How could you publish them? Who will be the owner of changes (for example using  SAP license – the SAP will be the owner of any changes customer will develop …). It could be very unsafe.

Next questions which are crucial are: If there is documentation? Is the company behind this product secure and will develop new releases and bug fixes? Or maybe the product is already dead..?

Choosing open-source products like Magento could is in most cases good decision:

  • you have to choose open-source product which is the market leader. MySQL in databases? Varnish on HTTP accelerators and so on… Those applications are very popular among developers. It’s almost sure they stay developing them and updating for long-time
  • open source is meant as safer software because developers around the world are finding security issues and publish patches. Yes, it’s true if you could apply them :) When developing custom functions, it’s crucial to implement them using features like hooks, events, modules and so on. Not changing the core codebase of product, which leaves it “upgradeable”,
  • look at the community – is there a lot of plugins, developers, forums and documentation for this product?
  • check if technology on which product bases are popular and there is no problem to recruit developers using it?

Of course, before making final choose it’s recommended to check case studies and read about production deployments of the desired product.

We recommend for e-Commerce stack following technology stack:

  • Magento as a platform – market leader, commercial support if needed,
  • Varnish + Apache + MySQL + PHP + Linux  – as software platform; are used by lot of web 2.0 sites – including Facebook. Those technologies are extremely scalable and very secure

All of them are open source and are industry standards in their categories

People make mistakes

People make mistakes. Because of that – there always should be a process which could be checked in case of problems. What goes wrong? What to make to improve this process?

We use checklists at Divante. We’ve checklists for almost every subprocess of software development:

  • deployments have checklist,
  • tests have checklists and customized to each project – test scenarios (which organizes tests and UATs),
  • developers have coding standards and project managers have QA checklists.

Checklists are very simple and powerful. They decrease cognitive effort for each team member to learn how to “do it well”. Team builts checklists themselves. In case of any problem we try to organize quick “5 whys” meeting and discuss conclusions which are transformed into new checklist-points.

To avoid people mistakes we are also strong fans of automatization. We automate tests (using Zabbix) to monitor servers; we automate deployments using Ansible; we create Selenium tests to automate testing (which is very crucial in case of safe deployments for example).

It’s crucial to avoid chaos. Each time – requirements are very customized. Let them change, but make process still and repeatable :-)

Everything should be on paper (at least virtual paper)

Having good software and process isn’t enough. I couldn’t count how many times when we got software for further development from a different company, there was no documentation.

The software could be complicated. Specially e-Commerce software which includes a lot of pricing rules, integrations and so on. Without documentation, developers are running out of time trying to guess how specified feature works. It’s a waste of time. It could be also dangerous – when without good understanding developers change code and incidentally include some hard to debug issues.

In our process documentation is important part of artifacts produced during development. We create functional analysis, mockups in the beginning. Then we create integration scenarios and collect formats of data that will be exchanged with other systems. After all we create technical documentation form developers and tutorials for end-users.

We plan about 10-15% of development time for documentation.

Stay safe

Methods described above should be treated as inspirations. We use it as minimum insurance to save Quality Assurance requirements. I haven’t written anything about security, performance tests which will be the topic of different posts!

What are your experiences in this field?

Published June 25, 2014