Technology
Table of Contents
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.
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:
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
US-based and operating globally, NEKLO spearheads digital transformation initiatives for businesses worldwide. We deliver software solutions complying with your market and legislation.
.png)
