105■ ■ ■
CHAPTER 8
Testing, Deployment, and
Continuous Integration
In the course of development for any reasonably complex application, you will encounter
bugs, logic errors, and collaboration headaches. How you handle these issues can make the
difference between a successful development cycle with happy developers and an overdue,
overbudget application with an employee-turnover problem.
There is no silver bullet that prevents these problems, but a series of tools can help you
better manage your projects and track your project’s progress in real time. These tools, when
combined, form a programming technique called continuous integration.
Any continuous integration project includes four main components: revision control, unit
testing, deployment, and debugging. Typically, when working with PHP, the tools used for these
four areas are Subversion, PHPUnit, Phing, and Xdebug, respectively. To tie them all together,
you can use the continuous integration server, Xinc.Subversion for Version Control
Subversion (often abbreviated as SVN) is a version control system that lets you keep track of the
changes you make to your application files. If you are a PHP developer, you will likely already
be familiar with revision control, maybe in the form of the Concurrent Versions System (CVS),
which predates Subversion and is still widely used.
Subversion can help prevent a common scenario that occurs when two or more developers
work on the same file. Without revision control, one developer downloads the source file (typically
from an FTP server), makes modifications, and then uploads the file, overwriting the original
copy. If another developer downloads the same source file while it is being worked on, makes
some other changes, and then uploads the file, she ends up undoing the first developer’s work.
With Subversion, this scenario can no longer occur. Instead of downloading a file, a devel-
oper checks out the current version of the file, makes changes, and then commits those changes.
During the commit process, Subversion checks to see if any other users have changed the file
since it was downloaded. If it has been modified, Subversion then attempts to merge any changes
so that the resulting file contains both sets of changes. This works fine if the changes do not
affect the same portion of the file. However, if the same code is changed, a conflict will be raised,
and the last committer is responsible for integrating her changes with those that came before.
In this way, no work is ever lost, and the project stays internally consistent.McArthur_819-9C08.fm Page 105 Friday, February 22, 2008 9:06 AM