Organization of web development environment
The productivity of the web studio team directly depends on the convenience of the development environment. We have a harmonious system of organizing work with projects, which includes a set of such integral components as IDE, SCM, PM-system, bugtracker and development-server. With this post I would like to start a series of articles on setting up and using these components in our studio.
In the first part I will talk about the most basic - the development environment (how we organized joint access to projects).
The concept is based on the fact that all projects are developed on one server. Pluses are obvious:
')
1. We get rid of numerous settings on employees' machines.
Everything is already set up once on the server, so you do not need to waste time or system administrators to configure the internal network to provide access to each of the computers, on the other - the developers themselves save their time setting up if they need to work remotely.
2. Unified Server Software Configuration
Many projects have specific requirements for server software. If these requirements are immediately set when developing on the server, then this can significantly save time during the testing phase and transferring to production. There is no need to synchronize software versions on programmers' computers with a working server (for example, when updating Apache, PCP, etc.)
3. Sharing access to a working copy of each employee
What is currently being developed by one person on his workspace, others can immediately see from the web. As well as the latest common version from the repository of the version control system.
4. Saving resources
We often hear from our friends stories about how they live badly because employers have spared money for a normal computer. In such situations, saving resources will be very useful, the functions of the web server and the interpreter are removed from the local machine.
The disadvantages of this concept are the requirements for network speed and reliability and the lack of flexibility in customizing the software for each project separately. In our case, the pros are far superior to the minuses :)
If all the code is interpreted on the server during development, how to organize convenient access to it?
View.
At home, inside the studio, we chose the following scheme:
At this address, the developer himself and all team members get access to each other's developments. For version control, we use SVN ( unstable trunk, stable branch scheme), creating a repository for each project, respectively, we turn to the correct branch, indicating its path (/ trunk; / branches).
Editing.
The most convenient thing for developers is to see project files without separating them from the OS file system. Therefore, each developer, in order to start working with the project, simply mounts his directory on the server to his local machine.
Oddly enough, but with the implementation of all very simple.
Bind
Naturally, if we want to get domains like username.project.example.com, then we need to add the following line to the zone file:
All subdomains matching the mask * .example.com will be addressed to the address of your web server.
Apache
Now, we need to teach the web server to process our domains and direct them to the correct directory. The working directory on the developer server is as follows: /var/www/username.example.com/project/trunk/htdocs/
Maybe it would be better to store everything in / home / username /.
Configuring virtual hosts:
Mounting a working directory
Local machines of developers may work under different operating systems, and the setting in each of the cases may differ.
Linux
The ssh protocol (if your server is the same as the linux or unix client) is native, therefore, having created each of the user's developers on the server, the directory is mounted by one command:
The parameter workaround = rename is needed for correct work with svn.
Windows
Everything is, as usual, somewhat more difficult, you have to use additional software, we have chosen ExpanDrive , the program allows you to mount the ssh directory.
It would be logical to use Samba on the server to refuse to use additional software, but, unfortunately, attempts to make Samba friends with svn were unsuccessful, making a checkout from svn into the mounted directory will not work. Now, perhaps, the situation has changed, but a year ago, a samba bugtracker on svn compatibility was opened.
Poppy
There are two options, you can use ssh: Macfusion application will be suitable for mounting the directory; You can use the native AppleTalk, then you can mount the directory through the Finder.
AppleTalk support can be organized by installing the netatalk package. To configure, you need to add the line to the /etc/netatalk/AppleVolumes.default file:
Now in Finder you can press ⌘ + K and in the address field enter afp: //username@example.com/username.example.com
This concept is suitable as the basis of the development environment for most small studios. At the same time, it is very flexible and simply expands, for example, to add one project or a new developer, it is enough to create the corresponding directory and add the user to the system.
In the first part I will talk about the most basic - the development environment (how we organized joint access to projects).
Ideas
- The development environment should be the same for all sites.
- Developers do not have to spend time setting up each its own server part.
- Whether one person or several people work on a project, version control is necessary.
- If the working directory (IDE workspace) is located on the server, then you can work at home without spending time reconfiguring the environment on your desktop or laptop.
Concept
The concept is based on the fact that all projects are developed on one server. Pluses are obvious:
')
1. We get rid of numerous settings on employees' machines.
Everything is already set up once on the server, so you do not need to waste time or system administrators to configure the internal network to provide access to each of the computers, on the other - the developers themselves save their time setting up if they need to work remotely.
2. Unified Server Software Configuration
Many projects have specific requirements for server software. If these requirements are immediately set when developing on the server, then this can significantly save time during the testing phase and transferring to production. There is no need to synchronize software versions on programmers' computers with a working server (for example, when updating Apache, PCP, etc.)
3. Sharing access to a working copy of each employee
What is currently being developed by one person on his workspace, others can immediately see from the web. As well as the latest common version from the repository of the version control system.
4. Saving resources
We often hear from our friends stories about how they live badly because employers have spared money for a normal computer. In such situations, saving resources will be very useful, the functions of the web server and the interpreter are removed from the local machine.
The disadvantages of this concept are the requirements for network speed and reliability and the lack of flexibility in customizing the software for each project separately. In our case, the pros are far superior to the minuses :)
Access
If all the code is interpreted on the server during development, how to organize convenient access to it?
View.
At home, inside the studio, we chose the following scheme:
username.project.example.com/trunkAt this address, the developer himself and all team members get access to each other's developments. For version control, we use SVN ( unstable trunk, stable branch scheme), creating a repository for each project, respectively, we turn to the correct branch, indicating its path (/ trunk; / branches).
Editing.
The most convenient thing for developers is to see project files without separating them from the OS file system. Therefore, each developer, in order to start working with the project, simply mounts his directory on the server to his local machine.
Implementation
Oddly enough, but with the implementation of all very simple.
Bind
Naturally, if we want to get domains like username.project.example.com, then we need to add the following line to the zone file:
*.example.com. IN A 208.77.188.166All subdomains matching the mask * .example.com will be addressed to the address of your web server.
Apache
Now, we need to teach the web server to process our domains and direct them to the correct directory. The working directory on the developer server is as follows: /var/www/username.example.com/project/trunk/htdocs/
Maybe it would be better to store everything in / home / username /.
Configuring virtual hosts:
<VirtualHost *:80>
ServerAlias *.*.example.com
ServerPath /var/www/
DocumentRoot /var/www/
RewriteEngine On
RewriteCond %{http_host} ^([^.]+)\.([^.]+)\.example\.com [NC]
RewriteRule ^/(trunk|branches|tags)\/?(.*)$ /%1.example.com/%2/$1/htdocs/$2
</VirtualHost>Mounting a working directory
Local machines of developers may work under different operating systems, and the setting in each of the cases may differ.
Linux
The ssh protocol (if your server is the same as the linux or unix client) is native, therefore, having created each of the user's developers on the server, the directory is mounted by one command:
sshfs -o workaround=rename username@example.com:/var/www/username.example.com/ /home/username/username.example.com/The parameter workaround = rename is needed for correct work with svn.
Windows
Everything is, as usual, somewhat more difficult, you have to use additional software, we have chosen ExpanDrive , the program allows you to mount the ssh directory.
It would be logical to use Samba on the server to refuse to use additional software, but, unfortunately, attempts to make Samba friends with svn were unsuccessful, making a checkout from svn into the mounted directory will not work. Now, perhaps, the situation has changed, but a year ago, a samba bugtracker on svn compatibility was opened.
Poppy
There are two options, you can use ssh: Macfusion application will be suitable for mounting the directory; You can use the native AppleTalk, then you can mount the directory through the Finder.
AppleTalk support can be organized by installing the netatalk package. To configure, you need to add the line to the /etc/netatalk/AppleVolumes.default file:
/var/www/username.example.com/ username.example.com allow:username cnidscheme:cdb options:usedots,upriv,noadoubleNow in Finder you can press ⌘ + K and in the address field enter afp: //username@example.com/username.example.com
Conclusion
This concept is suitable as the basis of the development environment for most small studios. At the same time, it is very flexible and simply expands, for example, to add one project or a new developer, it is enough to create the corresponding directory and add the user to the system.
Source: https://habr.com/ru/post/65005/
All Articles