Any sustainable software development project needs good foundations. While it is possible to write a Ruby on Rails application with nothing more than Ruby, a few libraries, and a text editor; this approach does not lend itself well to a team project where multiple authors may be working on the same code base. In addition, deployment and maintenance of the application once it reaches production becomes problematic if there is no supporting infrastructure in place.
This chapter outlines how to lay some firm foundations for a sustainable Rails development project. The core of this is obviously the Rails stack itself: we'll see how to install and configure this in some detail. But you also need some good infrastructure under this to ease development, deployment, and maintenance. Rails developers have faced the same issues all web developers face, and have integrated Rails with a variety of supporting technologies; things like database servers, graphics generation libraries, IDEs, version control systems, and web servers. Throughout the chapter, we'll encounter a few of the technologies closest to the heart of Rails, which can readily be used to support your development work.
In the preceding chapters, the example of the Acme development team was used to illustrate the initial stages of a Rails project. In this chapter, we'll see how such a team can set up its infrastructure for Rails development, using Acme as a case study. As is typical of small companies, Acme has limited cash to pay for software, and makes extensive use of open source software. We'll take the same approach, utilizing several best breed of open source technologies which can accelerate your Rails development.
We'll also focus on setting up Rails development infrastructure on limited hardware. In the case of Acme, they are again typical of many small companies and have the minimum hardware setup they can get away with. The hardware they use for their projects looks like the following screenshot:
Zooming in, the development environment looks like this:
- Developer machine
There are two developer machines, belonging to Rory and Jenny, respectively. Rory refuses to use Windows, and insists on Ubuntu Linux for his machine; Jenny uses Windows XP Pro.
- Server
Runs Apache for the Acme web site, a shared network drive, and handles local email (including spam filtering). Acme currently uses the shared network drive for its ad hoc code repository. The plan is to deploy Rails applications to this machine for use on the intranet by Acme staff.
There are other machines on the network, but they are used by administrators and other company employees rather than for development work. However, they do make use of the shared network drive on the server.
This kind of heterogeneous environment is fairly typical where hardware has been added as a company grows, and where developers get to install and manage their own machines. It introduces extra challenges where the aim is to introduce infrastructure to support new technologies, as it makes it harder to provide a consistent environment for the team.
Another issue is that small teams tend to work in a single room where they can manage projects verbally. In the case of Acme, if Jenny and Rory both need to work on a single file, they make an ad hoc arrangement to prevent potential synchronization problems, for example, "I'm working on library X, so stay off it for a while". However, they are thinking of hiring contractors for some of their new projects, who could potentially be working off-site, making ad hoc arrangements like this unwieldy and slow. They have also been stung a few times when their ad hoc verbal locking of files has failed, and they have both ended up simultaneously editing a single file: important changes made by Jenny were overwritten by Rory when he saved his copy of the file. Consequently, they have been considering using some kind of version control system to manage their code better. This will also allow an arbitrary number of developers in geographically-dispersed locations to work on a single body of code. They also see the value of having a mechanism for rolling back to previous versions of an application or individual files.