Easing Web Application Development with CVSby Oktay Altunergil
Web applications, by definition, work in conjunction with a Web server to perform a variety of tasks, ranging from displaying basic customized greetings to performing complex transactions. Most complex Web applications also make use of a database to store information.
While none of the above are radically different when developing a traditional standalone application, a Web application developer might think CVS is designed for working on traditional offline applications. I know I thought like this until I realized how applicable CVS is to Web development and how useful it really is.
One of the more important differences between the two types of applications is the notion of a "working copy." A standalone application developer can usually transfer a set of source files to his own development machine, compile it, and expect it to work. There's usually minimal configuration required each time a new version of the source is used. On a Web development environment, however, there are differences, stemming from the client/server nature of Web applications. These applications usually require the presence of a certain environment. The environment can consist of the environment variables on the server, variables specific to the Web server application, and the database that is being used. Again, some of these also apply to standalone applications, but are more visible when programming for the Web.
It is possible to increase productivity and speed up Web development by making use of facilities that CVS provides.
This is a case study on how to make the most of CVS in a Web-application development context. What I will describe here is the environment that I have set up to satisfy our particular needs and, as such, does not cover all possible scenarios, nor does it go into depth about how to set up a CVS server or use CVS commands, for which there's a lot of documentation available (see links below).
Here is our scenario:
A Windows & Unix shop developing PHP and MySQL Web applications. Each employee has access to either Windows, Linux, FreeBSD, or all of the above.
Some developers are more familiar with Windows tools such as advanced text editors and graphical diff viewers, and they usually want to test their code on a Windows-only Web browser. These people should still be able to use their favorite development environment. On the other hand, if others choose to develop on Unix systems, they should also be able to do it without a problem. It is also desired that people can work from home or other offices with minimal hassle.
- A CVS server (to host the repository). This server should also have SSH running.
- Samba on the development server to allow Windows users direct access.
- FTP or SSH on the development server and FTP client or editor with FTP/SSH capabilities on the Windows machines.
Preparing the Work Environment
After initially toying with the idea of having one development environment on which all developers would work and test their changes, I've decided to create a separate working environment for each developer. My reasoning was: it is very easy to create a separate virtual host on the Web server and keep one developer's working copy separate from that of another's.
By its nature, Web development requires a lot of testing at each step. Even getting a page to display right might require an extensive amount of coding, testing, and recoding. Having a separate environment gives the developer the freedom to do whatever he wants, without causing other developers any trouble.
On our project, we opted for using the same instance of the database, because the code is not very dependent on the actual data in the database. As long as the database structure is the same, we can share the same database without a problem, since the actual data in it is test data anyway. If we need to, we can easily get the latest state of the database from whoever made the change by inspecting differences in the MySQL structure dump for the two databases.
The repository can be on a separate server that doesn't have a Web server installed or it, can be on the development server itself. We have opted to run the development server and the CVS server on the same machine. Since the CVS repository is a separate entity, it will not be affected at all by this.
Although some of our developers work on the development server, I have placed my working directory on my Linux desktop, which I am also able to access via SAMBA from my Windows desktop. This way I have a self-contained development system and native access to both Windows and Linux tools. I have also set up a MySQL database and Apache with PHP on my Linux desktop.
If you're working on the same server as the CVS server, everything is straightforward. All you have to do is check out the source code into your working directory once. After that, you can update, add, and commit source code locally by running the appropriate CVS commands.
However, if you'll be placing your working directory on a different server like I've done, there are a few more configuration changes you have to make before you can successfully use CVS.
Pages: 1, 2