I work on several projects, both for work and for recreation, that require code editing by more than one person at a time. Some projects I’ve created on my own, while others were well established long before I came upon them. There are common threads between them, and I would like to try to point out some things that I’ve learned along the way.
When working collaboratively, a source code control system is mandatory. There is simply no other way in my mind to efficiently collaborate on a project of any size without source code management.
One might think that code control is not necessary for collaborating on small projects, but for those smaller projects it is especially true. If a project consists of a single file, and two people are working on that file, the only way to make the changes not continuously conflict with one another is to use some form of code control. The alternative of sending back and forth changes or keeping in constant contact to ask if another person is editing a file you need is not practical.
Source control does not consist of having a single copy of the source on a development server that everyone edits directly, and checks in and out. Using source control this way would be tantamount to creating periodic archives of source code. The intent of source control is to allow collaborative development, by giving developers the option to create their own development copies of a project so that they can edit what they need without interfering with other developers’ work. When discrete working parts are completed, the code management functions serve to merge the changes back into the main copy, from which the project can be deployed.
It is an essential part of source control to have a working copy for each developer so that changes within each do not interfere with other developers’ work. As I said, it’s useless for everyone to work out of the same working copy, because none of the benefits of source control are realized that way. There is little accountability, and the protection of files from overwriting due to simultaneous editing is non-existent.
There are also additional benefits to a developer-specific working copy. If the copy is local, then the developer need not be connected to the server to work and make edits. By editing on a running local copy, changes can be seen immediately. Also, runtime debuggers are difficult to configure properly on remote sites, especially if that server belongs to a client or is using shared hosting. With a local copy, a developer can run a runtime debugger when the need arises, and configure the settings of the local server to accommodate this at whim. Developers are also free to test server configurations that they would not be able to test on a shared development server, which would affect the other developers on that server. They can then troubleshoot server parameters locally, and use their findings to adjust the shared server at a time that is convenient to all working developers and server admins.
Another benefit of the working copy process is that developers will be required to update their own working copies with the changes of other developers to keep in sync with the core project copy. This provides an ideal opportunity to review the changes committed by others, since the system will often show what files were changed, and even what changes were made in each file. If working on a shared development server, it’s nearly impossible to know what part of a file has changed to be able to review it, making peer review similarly impossible. Source code management provides this opportunity by default.
Since any project could become collaborative at any time, it is also best to configure all projects to work well with source control. This means, among other things, that projects should centralize their configuration options, and not rely on the server system for storage of those options. For example, developers will connect their working copy’s code to its own database while working. To do this, the configuration options for connecting to the database should be in a single file that is not included in source control. This makes it easy for developers to commit changes without mangling the staging server’s database connection.
Similarly, relying on environment variables that are not going to be present on every development system is problematic. Since not every developer has access to the exact development platform on which the end product may be employed, it’s important to set baselines when the project begins. If the target platform must be specific because of tools employed there, then that should be specified. For the most part though, even projects on Linux are reasonably portable to Windows.
It’s very possible to create a project (for the web) that runs smoothly on Linux, Windows, and OSX with any small OS-specific changes isolated to files that would not be in source control anyway (like the configuration). It takes only a bit of planning to make sure that a project will run in all places, and after you’ve figured it out once, it’s easy to use the process for any project.
By assuming any new project will enter source control as a best practice, you can make your projects easier for others to work on, speed development and delivery time, and leverage the benefits of source control revision tracking.
