When a team is working on a project we often meet the similar issue:
- how to divide the work so as not to interfere with each other and avoid conflicts.
- testing and error correction
- split on version and demonstration of the project at different stages for the customer
Here we will go through two versions of the workflow, the first version was born because of a lack of financial resources and can be approached by those who want to organize a team work at a minimum cost. The second version is the most common so there is no point in plunging deeply into this approach.
Before we get started
At the heart of all the rules and workflows is working with the version control system – Git
We use BitBucket as the primary provider of storage and management services for Git repositories. The choice was made not by chance, inside the team / company we use JIRA to manage projects and tasks and this system is released and maintained by the same company as BitBucket for this JIRA + BitBucket = 100% compatibility.
Approach # 1
This approach was developed taking into account the fact that it would not run the projects locally (on the desktop), but on the server. This server should be the most powerful computer on the local network.
Server
All projects work under their own users, for example: project1, project2 under which we will go to the server using SFTP / SSH
As a background, Apache + php-fpm is used (it is necessary to run processes under certain users)
The folder structure on the server
Project1 /
– public_html (main staging’s folder) https://staging.company.com/
– logs (staging and team’s logs)
– team (the main folder where the command directories are stored)
– m1 (first developer folder) https://m1.staging.company.com/
– m2 (second developer folder) https://m2.staging.company.com/
The media folder is shared (symlink) to all developers, as well as other resources that are shared.
The databases are two, one for the main staging, the other for the developers.
Since we specialize in Magento projects, the approach of dividing the database and media data is different from us. There are advantages and disadvantages here. The advantage is that all the data: goods, categories, attributes, orders, etc. become available immediately to all developers.
The downside is that the work of all team can be stopped for some time if added an attribute with a dependency on a class (file) that has only one developer.
Below is an example of a local.xml file, through the configuration of which we solve the issue with different URLs on one database
This file allows you to override any settings of the admin panel including the main URL of the site
Benefits
Significant savings of local resources – HDD, since we work locally only with code, media and databases are on the server.
Security. When we log into the server under the user, we can work only in his home directory or with those files / folders that belong to him, therefore nothing else (that the user does not belong to) can not be deleted.
Members of the team can work on almost any PC from any place where there is Internet connections.
There is no need to configure the local server on the workstation, which may require some knowledge and time.
You can work in a local network without the Internet.
In general, the process design can depend on what you are working with, in our case we are working with Magento, which is rather resource-demanding, so running the project remotely and working with the code locally for us was an ideal option.
Disadvantages
The server have to be always online, because work outside the office will be impossible without access to it.
The debugging process is difficult, which can be very important, because the same xDebug is better to run on the workstation. If you run remotely, there will be a very significant load on the server and other projects might work slowly.
Work station
Here is a fairly common scheme. The repository on which the project is created is cloned. In the project settings, we specify: the remote server and the folder (each developer has his own) where the files will be uploaded.
When you first initialize the project, you will need to download all the files or use the SSH console to copy files from the main staging server to the developer folder or you can do it right away for everyone.
Testing
Considering that many developers can work on the project and each of them performs a certain task or even a group of tasks, then the progress of the process can be observed at each developer’s host. For example, the layout of pages A, B, C on the host m1, and the blog can be viewed at the host’s site. This can be very convenient for the client, because you can show the process in several ways.
After the commit and merge of the branch into the master branch (this may be some separate development branch), the work of TeamCity continuous integration server is included which can run tests, various commands, documentation creation tools, send notifications. If all operations (command starts) were successful, then the project is sent to the main stage, and the client staging can also be updated. The actions of the developer are minimized by additional operations on the code.
Approach # 2
It is widely used by all developers. You need to set up a local server, you can do this one time, which saves time in the future. Expand the project from the repository, add the necessary files, also import the database, copy the media folder.
Benefits
You can work without the Internet. To debug a project locally is easier, there is no need for additional settings, as for the server, for example, to connect to xDebug remotely and this does not interfere with other developers.
Disadvantages
Not all projects run immediately and often require additional knowledge, especially if you are working on Windows and sometimes it takes hours to unfold the project.
The project takes up space on the disk, most of all it is media data and a database, some projects can have very impressive sizes and when the question arises, which project to remove it may not be an easy choice.
In the repository you need to store not only the main code but also additional files that you may need to run the project.
At the moment we actively use both approaches of work and most likely this is already a matter of choice or habit. When you know Magento very well and do not need to spend so much time studying the code, then option number 1 is suitable
Of the additional tools in the work, mainly to check for errors, we actively use Scrutinizer and Blackfire tool.
