Organization of team development of an Internet project (using Git and 1C-Bitrix)
I remember that in the 90s there was such a profession (or vocation) - webmaster. So called the person who was engaged in development of the Internet sites: the designer, the maker-up, the programmer and the content manager - in one person. Times change. Modern Internet projects are often the fruit of 5–10 people. Team work
No matter how cohesive and friendly the team is, working on a common project is the basis for a potential conflict. And if the team - the conflict, the project - is doomed to failure. Swan, cancer and pike - the wagon will not move. The most common work conflict begins with a complaint: "You ruled here yesterday, and here it fell off." And then everyone is offended and begins to sort out the relationship, nationality, citizenship, religion, sex and age at a time as work - idle. I think this situation is familiar to everyone.
The likelihood of this kind of conflict in a team can be reduced to zero by using a version control system. In this article I want to share our experience in setting up a Git version control system using the github.com service for team development for the 1C-Bitrix content management system. I will tell from the point of view of the project manager, and not the server administrator.
')
In the simplest way of organizing team work on a project, we need one main site on the server — we will call it production, one test site (development site) —on the server next to it (dev site) + on a local copy of each developer’s site. (There may be several development sites on the server, but you should first consult with the technical support of Bitrix on the legality of such a system from the point of view of a licensing agreement).
Each developer will work on the project in his local copy of the site, in a separate Git branch for each task to be solved. At the end of the day, each developer makes a commit to the repository stored on github.com and only one developer, the lead, checks and merges the branches first on the developer site on the server, and then rolls the result to production. (In my subjective opinion, dual power on an Internet project is unacceptable. Even if merging branches and testing will take up all the working time of the lead developer of the project - no one else should make changes to the production site). At the beginning of the day, developers update their repositories with githaba
In the case when a change in the database structure is necessary, the developers first make changes in their local copies, write the change list to the lead developer, the lead developer makes them on the production, makes backup of the production database, which is then rolled onto the dev site and all the local dev sites . Additionally, database replication is configured (but this is a topic for another article).
So, we have a dedicated server, two configured virtual hosts and installed git server software - as a rule, the hosting staff can do this for us, where we buy the server.
In the directory of the main site, we deploy a backup site using standard Bitrix tools (or by hand), while the developer site directory is empty for now.
We register the corporate tariff on github.com. For the system discussed in this article, we have enough of the tariff for $ 25 per month. We start a private repository, we add existing githab users to the organization (or we get new users) - this is all done very transparently and conveniently, so we will not dwell on this point in detail.
After the corporate private repository has been established, we need to make the first commit to it.
We go via ssh to our server as a user with the rights to write to the site folders, go to the directory where we intend to initiate the repository.
The repository can be initiated directly in the site folder (then it is important not to forget to then protect the .git folder in the .htaccess file from downloading), or you can initiate it in the superdirectory (an option where the files of each site are not located immediately in the www directory or the dev directory, but in subcatolog, for example, dev / httpfiles, www / httpfiles And we initiate repositories in the www and dev directories, respectively. If the server is configured from scratch or if the admin is not too lazy to re-write virtual hosts, this option is preferable).
Before initiating a repository for the main site, it is necessary to decide which folders and files should be included in the repository, and which - not - to generate the .gitignore file.
An example of the .gitignore file for 1C-Bitrix for the case when the repository is initiated in the site directory:
An example .gitignore file for 1C-Bitrix for the case when the repository is initiated in the supra directory:
That is, we will not control changes in the backup folder (/ bitrix / backup), cache folders (/ bitrix / cache, / bitrix / managed_cache, / bitrix / managed_flags, / bitrix / stack_cache), folders with cron jobs (/ bitrix / crontab ), a folder with logs (/ logs), a folder with downloads (/ upload).
A folder with uploads / upload on all developer copies of the site, located on the same server, it makes sense to symlink to the / upload folder of the production site.
A symbolic link in the / dev / directory - the root directory of the developer site is created by the command
Speaking of symbolic links. When configuring a multi-site system on a single core 1C-Bitrix type 2, we will also need to exclude the bitrix folder from the main repository. Because physically this directory will exist only on one site of the system, and on the other there will be symbolic links to it. But since it is still necessary to control changes to the files in this folder, it would be advisable to have a separate repository for it.
The /bitrix/php_interface/dbconn.php file contains individual settings for each virtual host (in particular, the database connection settings), so we add this file to the git exceptions.
The file /urlrewrite.php is a file with the rules of processing of CNC addresses of Bitrix - it can be overwritten (sorted inside) by the engine itself, therefore we will exclude it.
The .gitignore and .htaccess files should also be in exceptions. In exceptions, it is also worth adding log files, text files, xml files - everything that does not relate directly to the program code.
Once we have decided on the contents of .gitignore and created the .gitignore file in the directory of the future repository, we can initiate a repository for the production site. To do this, we first need to take care of authorizing our server ssh-user on githab - to generate a key for it.
We execute the command
email can be entered any, but with email of the form bitrix@name.sayta easier to identify the key on the github.
Go to github.com/settings/ssh and add a new key - take the key data from the file / path / to /.ssh/id_rsa.pub
Check the connection:
We initiate a repository in the directory of the main site (or in the directory above):
go to / path / to / www / and execute the commands:
After the repository for the main site is initiated, we upload all the project files into the githab repository:
Now we clone the repository in the directory of the developer site:
After that, in the developer site directory, create a symbolic link to the upload folder as described above. Then, using the standard tools of Bitrix, we will make a backup database of the main site, and deploy it to the developer - the file that stores the connection to the database will be created for the site devs automatically.
Now you can create repository clones on local development machines in the same way. To do this, they need to put any git software bundle on their local machine (the Git command line comes with any bundle), run the command line, generate a key, add it to the githab, clone the repository into the virtual host directory on the local machine, and simply upload the upload folder from the main site, roll out the database dump from the main site.
After that, you can relax and enjoy teamwork, building friendly relations with colleagues without quarrels and disputes, promptly reversing incorrect changes - without searching for the guilty.
Related Links:
- Git Version Control System
- What are symbolic links?
- Installation and configuration guide 1C-Bitrix
No matter how cohesive and friendly the team is, working on a common project is the basis for a potential conflict. And if the team - the conflict, the project - is doomed to failure. Swan, cancer and pike - the wagon will not move. The most common work conflict begins with a complaint: "You ruled here yesterday, and here it fell off." And then everyone is offended and begins to sort out the relationship, nationality, citizenship, religion, sex and age at a time as work - idle. I think this situation is familiar to everyone.
The likelihood of this kind of conflict in a team can be reduced to zero by using a version control system. In this article I want to share our experience in setting up a Git version control system using the github.com service for team development for the 1C-Bitrix content management system. I will tell from the point of view of the project manager, and not the server administrator.
')
In the simplest way of organizing team work on a project, we need one main site on the server — we will call it production, one test site (development site) —on the server next to it (dev site) + on a local copy of each developer’s site. (There may be several development sites on the server, but you should first consult with the technical support of Bitrix on the legality of such a system from the point of view of a licensing agreement).
Each developer will work on the project in his local copy of the site, in a separate Git branch for each task to be solved. At the end of the day, each developer makes a commit to the repository stored on github.com and only one developer, the lead, checks and merges the branches first on the developer site on the server, and then rolls the result to production. (In my subjective opinion, dual power on an Internet project is unacceptable. Even if merging branches and testing will take up all the working time of the lead developer of the project - no one else should make changes to the production site). At the beginning of the day, developers update their repositories with githaba
In the case when a change in the database structure is necessary, the developers first make changes in their local copies, write the change list to the lead developer, the lead developer makes them on the production, makes backup of the production database, which is then rolled onto the dev site and all the local dev sites . Additionally, database replication is configured (but this is a topic for another article).
So, we have a dedicated server, two configured virtual hosts and installed git server software - as a rule, the hosting staff can do this for us, where we buy the server.
In the directory of the main site, we deploy a backup site using standard Bitrix tools (or by hand), while the developer site directory is empty for now.
We register the corporate tariff on github.com. For the system discussed in this article, we have enough of the tariff for $ 25 per month. We start a private repository, we add existing githab users to the organization (or we get new users) - this is all done very transparently and conveniently, so we will not dwell on this point in detail.
After the corporate private repository has been established, we need to make the first commit to it.
We go via ssh to our server as a user with the rights to write to the site folders, go to the directory where we intend to initiate the repository.
The repository can be initiated directly in the site folder (then it is important not to forget to then protect the .git folder in the .htaccess file from downloading), or you can initiate it in the superdirectory (an option where the files of each site are not located immediately in the www directory or the dev directory, but in subcatolog, for example, dev / httpfiles, www / httpfiles And we initiate repositories in the www and dev directories, respectively. If the server is configured from scratch or if the admin is not too lazy to re-write virtual hosts, this option is preferable).
Before initiating a repository for the main site, it is necessary to decide which folders and files should be included in the repository, and which - not - to generate the .gitignore file.
An example of the .gitignore file for 1C-Bitrix for the case when the repository is initiated in the site directory:
/bitrix/backup /bitrix/cache /bitrix/crontab /bitrix/managed_cache /bitrix/managed_flags /bitrix/modules/*.log /bitrix/php_interface/crontab /bitrix/php_interface/dbconn.php /bitrix/stack_cache /logs /upload /.gitignore /.htaccess /urlrewrite.php /*.log /*.sql /*.txt /*.xml /*.dt An example .gitignore file for 1C-Bitrix for the case when the repository is initiated in the supra directory:
/httpfiles/bitrix/backup /httpfiles/bitrix/cache /httpfiles/bitrix/crontab /httpfiles/bitrix/managed_cache /httpfiles/bitrix/managed_flags /httpfiles/bitrix/modules/*.log /httpfiles/bitrix/php_interface/crontab /httpfiles/bitrix/php_interface/dbconn.php /httpfiles/bitrix/stack_cache /httpfiles/logs /httpfiles/upload /httpfiles/.htaccess /httpfiles/urlrewrite.php /httpfiles/*.log /httpfiles/*.sql /httpfiles/*.txt /httpfiles/*.xml /httpfiles/*.dt That is, we will not control changes in the backup folder (/ bitrix / backup), cache folders (/ bitrix / cache, / bitrix / managed_cache, / bitrix / managed_flags, / bitrix / stack_cache), folders with cron jobs (/ bitrix / crontab ), a folder with logs (/ logs), a folder with downloads (/ upload).
A folder with uploads / upload on all developer copies of the site, located on the same server, it makes sense to symlink to the / upload folder of the production site.
A symbolic link in the / dev / directory - the root directory of the developer site is created by the command
ln -s /path/to/www/upload Speaking of symbolic links. When configuring a multi-site system on a single core 1C-Bitrix type 2, we will also need to exclude the bitrix folder from the main repository. Because physically this directory will exist only on one site of the system, and on the other there will be symbolic links to it. But since it is still necessary to control changes to the files in this folder, it would be advisable to have a separate repository for it.
The /bitrix/php_interface/dbconn.php file contains individual settings for each virtual host (in particular, the database connection settings), so we add this file to the git exceptions.
The file /urlrewrite.php is a file with the rules of processing of CNC addresses of Bitrix - it can be overwritten (sorted inside) by the engine itself, therefore we will exclude it.
The .gitignore and .htaccess files should also be in exceptions. In exceptions, it is also worth adding log files, text files, xml files - everything that does not relate directly to the program code.
Once we have decided on the contents of .gitignore and created the .gitignore file in the directory of the future repository, we can initiate a repository for the production site. To do this, we first need to take care of authorizing our server ssh-user on githab - to generate a key for it.
We execute the command
ssh-keygen -t rsa -C "bitrix@." email can be entered any, but with email of the form bitrix@name.sayta easier to identify the key on the github.
Go to github.com/settings/ssh and add a new key - take the key data from the file / path / to /.ssh/id_rsa.pub
Check the connection:
ssh-T git@github.com We initiate a repository in the directory of the main site (or in the directory above):
go to / path / to / www / and execute the commands:
git add README.md git commit -m "first commit" git remote add origin git@github.com:/_.git git push -u origin master After the repository for the main site is initiated, we upload all the project files into the githab repository:
git add . git commit -m “second commit” git push Now we clone the repository in the directory of the developer site:
cd git clone git@github.com:/_.git dev After that, in the developer site directory, create a symbolic link to the upload folder as described above. Then, using the standard tools of Bitrix, we will make a backup database of the main site, and deploy it to the developer - the file that stores the connection to the database will be created for the site devs automatically.
Now you can create repository clones on local development machines in the same way. To do this, they need to put any git software bundle on their local machine (the Git command line comes with any bundle), run the command line, generate a key, add it to the githab, clone the repository into the virtual host directory on the local machine, and simply upload the upload folder from the main site, roll out the database dump from the main site.
After that, you can relax and enjoy teamwork, building friendly relations with colleagues without quarrels and disputes, promptly reversing incorrect changes - without searching for the guilty.
Related Links:
- Git Version Control System
- What are symbolic links?
- Installation and configuration guide 1C-Bitrix
Source: https://habr.com/ru/post/219569/
All Articles