Source code revisions should be maintained so you can revert to an old code if necessary. Source code control is a must. It is especially helpful in situations where you are troubleshooting to locate the cause of an issue. If you know a broken feature was working some time back, you always can revert back to a known point and try to locate the change in code that caused the problems.

Source control also helps to keep in touch with what others are doing to the code by having a look at the change summaries. Most source code control systems support a means of evaluating the difference between the central source code repository and the local copy that a developer has, that he or she might have changed. With SVN, all that you need to do is to run the following command:

svn diff

When you work in a team, collective code ownership is a must. The commands such as svn diff make your life easy when living in a world where the source code is shared.

There are various source code controlling tools around. For example, SVN (http://subversion.tigris.org/) and GIT (http://git-scm.com/) are the most popular source code controlling tools nowadays. We will visit source control tools, and more importantly best practices, later in this book.

The concept of revisions, as shown in the preceding screenshot, helps to keep track of the changes that each developer in the team has done on the PHP source code. Whenever a change is done and is integrated with the central source code repository, it will be identified by a unique revision number. Revision numbers given to changes are continuous, and that helps to figure out the exact sequence of changes that has gone into the source code between two points in time. This makes it much easier to pinpoint problem causing changes, from among a sequence of changes that has taken place on the source code.

Make sure that everyone builds the system regularly, at least once a day. If the system is too large, make nightly builds. A build is a package where everyone's changes to the source code are included, and all of the elements of the software system are present. When the developers are busy with their own sub-modules, PHP classes, interfaces and unit testing the sub-modules, it can be easily overlooked to put all pieces of the system together and give it a test run.

For PHP, there is no compilation involved. There are cases where packages can be compiled and packaged in PHP, which correlates to something similar to building. For example, when developing PEAR packages and creating automated documentation, you would build the system. So what does it really mean to say 'do continuous builds?' Why bother with builds at all when working with PHP? There are numerous use cases in which continuous builds come into play. For example, those who are working on the database might change the database configuration or data schema. People who are working on libraries might refactor their code and change script paths or method signatures. This is possible, because everyone is busy developing in parallel. For maximum utilization of team resources, especially people, as well as to deliver the system sooner, you need to work in parallel. There is a drastic difference between working in parallel and deploying in parallel. When delivering a system, we need to define a set of milestones that we want to achieve as the project progresses. Each milestone would be achieved with a series of work iterations. Before deploying to the live system, for the purpose of integration testing, we would need to deploy the milestones to a staging server. Continuous builds are meant for testing with staging deployments and not for the real-life deployment of an application.

Due to the dynamic nature of the project and the way the team members' work, when you put all of the pieces together, the final picture would look drastically different from what you would see in isolation. You need to make sure that everyone sees the big picture on a regular basis.

When you are working with a team of people, there are various sub-groups within the team, who are experts in various domains. Some are designers and developers. Some are user interface design experts. Some are experts in testing and quality assurance. When you are working in a project, you need to keep all of these team members posted about the latest status. The designers, developers, and UI designers need to know what progress has been made so far. You also need to give the latest picture to the quality assurance (QA) team on a regular basis. In traditional software engineering, the quality assurance team would wait until they are given a release pack or a QA build. But with agile process, you can make the QA team be part of the daily process, helping to find issues on a daily basis. Continuous integration eliminates big surprises in terms of integration efforts.

Talking about QA, keeping track of issues in the system is very important. It makes life easier when you know what issues were found, what issues are still open, what were fixed, and when those were fixed. Sometimes, due to regression, some issues might even get reopened.

You can assign issues to team members and schedule issues so that other stakeholders of the project get to know when the issues will be attended to.

Not only bugs, but also improvements, wish lists, tasks, and so on can be tracked with an issue tracking system. This makes sure that all good ideas are noted and attended to at some point in time.

There are numerous tools that are available, both open source and commercial for bug tracking. Jira (http://www.atlassian.com/software/jira/) and Bugzilla (http://www.bugzilla.org/) are two popular bug tracking tools.

Communication is a critical factor for the success of a software project team. No matter how technically competent your team members are, if the communication is not perfect, the entire team could fail.

If the interface between presentation and business logic layers are to be changed, then all of the members of both the presentation and business logic sub-teams should know about the change. It is not only the fact that the interface is going to change that needs to be communicated, but also the rationale for the change, who gets affected, what to expect, and what needs to be done by each member to make the change successful.

There are many forms of communication, and there are many tools to help you with communication. You can have face to face meetings and design and code review sessions. Wikis for documenting and noting down discussion points, are shown in the following screenshot:

Mailing lists and forums can be used for discussions. Likewise, chat rooms can be used for discussions. However, discussing in a chat room is very different from discussing in a forum or mailing list. A chat room is real time (synchronous), whereas a mailing list or a forum has a time lag involved (asynchronous). Unlike in a chat room, you need to wait until the others respond to the emails or the forum entry. On the other hand, mailing lists and forums are archived (as shown in the following screenshot), so they can be used as informal documentation as well. Instant messaging is another great channel that can be used for communication. Instant messaging also comes with great archiving facilities.

Various forms of communication can be used for various communication needs of the team. It is helpful to ensure that every team member understands the need for communication as well as the means of communication to use, based on the information being communicated.

We will discuss the tools and techniques for communication, in detail, later in the book.