TECHNICAL

Continuous Development

Management is more important than talent. Such a conclusion was made by a group of researchers who compared the results of two teams: the skill of developers in the first team was high but the management was poor. While the professional skills of the second team were on an average level, but their management was good. And what do you think? What team had the upper hand? The second!Our company occupied its niche in the e-commerce market in particular thanks to good management, efficient internal processes, the use of continuous integration, effective communication, timely detection and prediction of risks, and making the right decisions.I’ll tell you about the development cycle in our Magento team which is based on the use of Continuous integration schemes, as well as the approaches to work with GIT on our Magento projects.Scheme 1 shows a block diagram of the Magento project development cycle. There is the local Development server located in the office local network (LAN) and inaccessible outside (from the Internet) for security purposes. On this server, a standard operating environment (LAMP – Linux + Apache + MySQL + PHP) is deployed and set up with working copies of the project for each developer. Each working copy of the project is connected with its virtual host – so each developer works with his own copy of the project not interfering with the work of other developers. Another important objective to keep working copies on the shared DEV server is to relieve the local PCs. Each project copy is accompanied by a cloned GIT repository (or to be more precise, each working copy is taken from a GIT repository copy). The files of each working copy are available for the developer through the shared folders. For each working copy folder, the indexing is applied by the means of OS in order to improve the searching speed of the files.The developers save all the results of the work in the local GIT repository (commit), and send them to a remote central repository (push) – for example, stored in GitHub.Since in all our projects we use Continuous Integration approach, let’s explain it in more detail: in the upper right part of the scheme we see Jenkins server – it is responsible for the following essential components:
  • automatic deployment of the latest project version on the DEV server from GIT branch DEV, turning on the Magento compilation, reindexing, JS / CSS files compiling, Unit and load tests modelling. This automatic runs on GitHub hooks and activates after each PUSH into GIT of the DEV branch.
  • the numbering of project versions: 1.0.2, 1.0.3, 1.0.4 – release versions, 1.0.2.1 – hotfix version for this release (a 3-digit number for the release version, if the number is of 4-digits, then the last number is a number of a bug fix).
  • deployment of the project latest version from the GIT branch master on the STAG (QA) server (ideally this server is a replica of the LIVE server), turning on the Magento compilation, reindexing, JS / CSS files compiling, Unit and load tests modelling. The deployment is applied by the system administrator in Jenkins Web panel.
  • deployment of the project latest version from the GIT branch master on the PROD server.
pic1Scheme 1. Magento project development cyclepic2Scheme 2. GIT branches usedFor a better and deeper understanding of Continuous Integration let’s get to Scheme 2, explaining the approaches used in the context of GIT. Time here goes upwards. Any major task is divided into subtasks and each developer independently from the others is developing in his local branch (task1, task2, task3). Once the task is ready, its Merge into the branch DEV is made for demonstrational reasons as well as for preliminary testing.Thus, while some of the tasks have already been tested by QA, and this part will be included in the release version, the other tasks are still under development – it is nothing else than Continuous Integration in action.When the decision what concrete tasks will be included in the release version is made, the branches of these tasks get in the branch RELEASE through Merge. This is an extremely important branch and it is necessary to absorb ONLY what is necessary for a particular release and eliminate those tasks on which work is still underway and which will be included in the next releases. Important point: if a bug is found, then its fix is made and this fix by Merge gets both in DEV and master branches (such duplication is necessary to make DEV and master branches as equal as possible).Branching all new tasks (task4, task5) should start from the point of the latest release.Yes, in the case of a large number of subtasks (and branches in GIT) the scheme may seem confusing, but this scheme has one key and distinct advantage – VERSATILITY. After all, all our projects are long-term and fast-growing, with a huge number of tasks of different level of priority. At the end of each week, we decide what will and what will not be included in the release. Under these conditions a simple scheme with one or two branches will be simply useless – by the time of release, it will be impossible to quickly and accurately select only a certain group of branches.Over many years of development, the approaches shown in this article have completely proved their effectiveness. Of course, it is essential constantly to adapt to current market conditions and the specific project, but our team always adhere core principles of high quality, the stability of our products, compliance with all the time frame for development.“Your wishes are our issues.”
Anatol Kravchenko,The lead of PHP team,NEKLO LLC

Related posts

MAGENTO
Magento in 2021 and Beyond: Magento Experts Share Predictions
Two experts from the NEKLO ecommerce team, contributing to our expertise as a Magento development company, share their thoughts on the potential of their favorite and one of the most popular ecommerce platforms on the market today. Find below expert quotes about Magento development, Magento services, and Magento partners from our Senior Magento Developer Michail…
author's avatar
Nadya Bakhur
Researcher, Content Writer
TECHNICAL
App Development Cost Breakdown: How Much Does It Cost to Design an App
There is a wide price range within custom software development and mobile app development today. This article focuses on the factors that affect the final average app development cost of a project. It will help you negotiate the price with any application development specialist googled through the “app developers near me” query and understand how…
author's avatar
Dasha Korsik
Content Team Lead
TECHNICAL
Build vs Buy Software: Pros & Cons of Custom Software Development
In today’s digital world, almost every business, regardless of its size or niche, needs a software solution to manage data, improve customer experience and update internal processes. A dizzying array of business software programs is already available on the market and there is always a prospect to build a custom software solution. “Buy vs build…
author's avatar
Nadya Bakhur
Researcher, Content Writer
INSIGHTS
NEKLO DIGEST #5: Is Dropshipping Worth It? Ecommerce Strategy Tips
Starting an ecommerce activity seems the right choice for many business owners today. However, many of them are puzzled about existing ecommerce business ideas and aren’t sure which one to follow.  When the choice is difficult, they come to our ecommerce development company for a custom software solution or professional consultancy. Additionally, we provide the…
author's avatar
Dasha Korsik
Content Team Lead
MAGENTO
Magento Big Data Solutions: How Big Data Projects Change eCommerce?
If you rely on data and analytics, the chance you will be disappointed is minimized. In this article, we’re going to overview why and how companies use big data within their ecommerce initiatives. What’s more, NEKLO team wants to make it certain for you that one of the key benefits of merging Magento web development…
author's avatar
Nadya Bakhur
Researcher, Content Writer