Every major development team eventually faces the need for standardized development environments. We classify them in the following way:
- Head office infrastructure development
- External servers
- Local computers of remote developers
Office Infrastructure
Each developer’s workplace is presented by a medium-performance computer (Acer Aspire X3200) used for running office software, such as heavy Eclipse type IDE, Net Beans, etc. The developers can use either Windows (in most cases), or Linux OS.
At the very beginning of our work, every developer ran a local web server on their own computer. But over time this situation stopped being suitable for the following reasons:
- Local Windows Web Server (mostly Denver) is rather slow.
- It’s hard to install additional Linux-software (such as codecs ffmpeg, memcached, etc.) on a local Windows-based web server.
- In case of Linux everyone may have different distribution packs, which sometimes complicates project deployment.
- Developers can’t see the local versions of their colleagues.
We solved all these problems by purchasing a powerful server for the office with a Web server installed and running on it together with local developers’ sandboxes they use working online.
How it all works:
- Every developer has his own home directory (eg /home/misha ) on the server.
- The server runs Apache with the mod_vhost_alias module, which creates vhost-s in Apache for the user's home directories. For example, /home/misha/www/superproject is available at http://superproject.misha.local/.
- The server also has Bind installed, which distributes local domains to network users to make those domains available in all the browsers.
- The server has Samba installed, which allows connecting a network drive to your home directory (eg /home/john) on the server. In this case in terms of work done the creation of a new sandbox is equal to the creation of a folder (in /home/john/www). First there were doubts as to whether it would make the whole thing work slow, because the speed is limited by the bandwidth of the channel connecting to the server via the network, but in practice a usual wifi connection to the server turned out to be enough to make everything work like clockwork.
- The sandboxes of other people are not restricted for viewing or editing (you can either open them in your browser, or connect through the network), but could potentially be restricted by the developer after setting the appropriate file permissions.
- SSH access to the server is working.
In my experience, this system can be effectively configured even if you don’t consider yourself a super admin and only know how to browse files in Linux. Of course, with Google’s help.
External Development Servers
Office system perfectly handles the team’s in-house daily development tasks. However, some problems still remain unsolved:
- Where to place a shared development/testing server available outside the office (for remote developers working from home, etc.)
- Where to display the development results to the clients.
- Where to perform load testing.
- How to pick hardware of different configurations for testing purposes.
Amazon Cloud
This issue had been in the air right until we first learned about Amazon EC2 cloud services. In a nutshell, these services allow you to create servers of various configurations paying only for how much you’ve spent (for example, 3 hours + 3 gigabytes of server network traffic) in different regions of the world (USA, Europe, Singapore) . Therefore, the main thing to understand about the Amazon is that it allows to rent 20 servers with 60 gigabytes of memory for a couple of hours every day and the whole process takes no more than 5 minutes. Classic hosting won’t let you do things like that.
In addition, there are hundreds of "snapshots" of ready-configured systems that you can use with the hardware you’ve just rented. Moreover, you are able to create such snapshots by yourself and use them in the future (for example, if you have a large application that requires a lot of servers).
Testing development servers
In general, our testing servers are built like the office ones - there is a server domain, and mod_vhost_alias allows accessing random projects, and the path to these instances will look like the third or fourth level domain (eg, http://superproject.test.shvetsgroup.com/). At the configuration level, the difference is that the projects, not the developers have the "primary" role.
A lot of times I have seen companies giving every developer route access to the development server and the repositories. Many of you know the consequences this may lead to, especially when unverified new remote workers and teams are involved. For us this has always been and still is a special aspect, that’s why when it comes to testing/development servers, we strictly separate access rights to server projects, both from outside and by the developers. None of the developers has access to "neighboring" projects on the server, and the Web-based access is closed by http authorization (this also protects against unwanted indexing of the project’s test version by search engines).
In rare cases, when the project requires a special testing environment, we create a separate server with the necessary configuration on the Amazon. Moreover, after the active testing and development are completed, we create a "snapshot" of the server and shut it down until the next round of testing.
Organizational Software Server
Another Amazon server hosting SVN-repositories, bugtracker and documentation system (for details, see the second part).
Local servers of remote developers
Obviously, there’s no way we can influence the hardware/software used on "that side", however, for the time we’ve been working we compiled a list of developer’s must haves necessary for the effective work:
- Broadband internet (from 4Mb/s)
- Backup-Internet channel. A very important thing we need the most when we don’t have it. An additional wire access or even cell phone access (GPRS/EDGE/3G), or 4G (Yota / FreshTel) will do.
- High-performance working computer, with two cores and 4GB of RAM. Linux or Windows with a virtual machine for the web server (not Denver).
- Large display (22 inches), or better two, with full color rendering.
- Skype client configured to forward calls and messages to the phone, good-quality headset and a webcam.