One of the most significant features of any business is continuous growth. What is more, online business is as of great importance as brick-and-mortar stores and deserves no less attention. Web stores should be fast and meet customer’s needs. Besides, it should be easy to customize and implement new up-to-date options. That’s why one of the most famous retailers Shiekh.com entrusted us to take the store to a new level.
What is Shiekh.com
Shiekh Shoes is a well-known West Coast clothing retailer that has 146 offline stores located in different cities including Nevada, Arizona, Oregon, Michigan. The store is famous for selling athletic footwear and apparel of such brands as Nike, Adidas, Reebok, Sketchers, Lacoste, Converse. Additionally, more than 1000 employees provide customers with exclusive goods which other retailers do not sell.
Guys from Shiekh Shoes chose our company to create a new web store aimed at mobile ecommerce. Having come into line with them, we took the following responsibilities:
- integration with the existing store on ASP.NET;
- providing high-speed performance: decreasing response time at peak load is unacceptable;
- scalability: deploying as many server resources as needed at the moment; automatic instance changing according to load;
- simple and reliable deployment process: all proved changes should be displayed immediately while being invisible for users;
- mobile-friendly approach: more than 70% of orders are made with mobile devices;
- a convenient tool for marketing including standard loyalty campaign, newsletters, raffles, and close interaction with customers via the mobile application.
Magento Commerce (Magento 2 Enterprise Edition) was chosen for development due to its stability, scalability, and functionality which met our needs most. The updated Shiekh.com went live after Magento release. Every upgrade got the web store improved. Most bugs the first version had were fixed.
During development the following tools were applied:
- For backend: AWS (Amazon EC2, Amazon SQS, Amazon SNS), PHP 7.0, MySQL 5.7, RabbitMQ 3.5, Supervisor.
- For frontend: RequireJs, LESS, Jquery 1.11, Angular 1.2, Nodejs 4.6.2, Gulp.
- For caching: Redis 3.1 and Fastly.
- For testing: Apache Jmeter 3.0, Phpunit 4.1, Codeception 2.2.
- For deployment: Bamboo.
Development and deployment processes
A separate instance is created for a particular task with all necessary services connected. After the sprint is completed, the code runs into the staging branch of the repository on the dev server which reproduces the live version infrastructure. Then the last build is deployed and testing including module, unit and functional runs. It’s great that Magento provides the number of tools for it. If all tests are conducted successfully, then manual testing runs. Later load testing is conducted.
It is commonly known that testing is a time-consuming process, that’s why we divided the process into some stages. First off, slow and fast tests were separated. It’s obligatory to conduct some tests before merging code with the master branch. The other part of tests is conducted when deploying on live. You may think the number of tests is enormous, but the multi-step process ensures the released version efficiency.
Later a new VPS instance where the build is delivered is created automatically. After statics is compiled, functional testing is conducted one more time. The next step is changing the active server into load balancer. In such a way, we ensure the live version to work. For website users the process is invisible. Sometimes it happens when surfing the old version, a user is turned into the upgraded website.
Due to the process, we have some snapshot of previous successful builds and an ability to turn to them if necessary.
On the whole, as I noticed above, build process and testing take much time and require extensive server resources, that’s why we prefer deploying at night when minimum load.
Magento 2 developers created queues to perform routine tasks. In fact, this is a breakthrough if compared with Magento 1. In our case, queues are considered as a “life saver”. Push notifications, API interfaces, products import are based on queues.
For queues implementation, we used RabbitMQ and Supervisor. The details of RabbitMQ Queue implementation are described in the article How to Use RabbitMQ Queue in Extensions For Magento 2.0 EE.
We used these services for a long time, but unfortunately, it didn’t meet our requirements completely, so we had to perform some tasks manually with every release. So we applied Amazon SQS which met our requirements completely. It was primarily integrated into AWS ecosystem that saved us the trouble of additional abstraction layer with RabbitMQ.
For dealing with Amazon SQS we had to create the wrapper module which simplified handling with queues. Feel free to test, fork and commit updates.
Magento cache is stored in Redis cluster which is supposed to be the common approach taken by different online shops. Besides, Fastly is used as proxy cache. Fastly is a service which allows caching and delivering Magento content faster. In addition, the service can be considered as CDN, cloud Firewall, and additional load balancer. All in all Fastly is a must-have for any large-scale shops.
Our project has been existing more than a year. Nearly 1000 customers are served daily. Development and deployment processes are adjusted that allows optimizing quality control and store support costs. The development time was reduced to 25% while the excellent website performance can handle nearly 25k users. As for items, 10k product details can be automatically changed for marketing strategies. With the help of such tool as Balancer, the web store can withstand two times more peak load than before.
It goes without saying that a lot of interesting facts such as mobile application, Bluefoot CMS & Page Builder integration, stocks update are not mentioned in the article. If you’d like to know more about the project, you can ask questions to the team of developers below. They will be happy to provide you with necessary information related to the project.
The team of developers who worked on the project: