3.5. Scaling the Development Model

Source control is as important for a single developer as it is for a small team, but the utility increases as the number of developers grow. Most source-control systems are designed to scale to many simultaneous developers, allowing many people to work on the same project or even the same files at once.

As your development team grows from a single engineer to a small group, little will need to change about your source-control usage. When moving from one to two developers, you'll need to start updating your checked out copy of the source code more often, to integrate changes from other developers back into your working copy. A good rule of thumb is to update your working copy at the start of every development session and additionally when another developer commits a large change set.

If two developers work on the same file at the same time, the changes will be automatically merged by the source-control system, as long as they don't overlap within the file. If you find yourself in a situation where you get merge conflicts, then this probably isn't an issue with your tools but with your processes. Although most source-control systems allow multiple people to work on the same file at once, you still need to coordinate your development between developers and avoid having two people working on the same task at once. No amount of locking, branching, and merging can make up for plain old communication between developers.

As far as deployment tools go, a developer team may need to assign one or more developers to deploy control or deploy branch check in rights. As your team grows, you may also wish to designate a single developer as the release manager, responsible for overseeing all code releases. For one developer, the role of checking in production code and deploying it is straightforward, but as you add more developers each release cycle has more dependencies. At some point you may want to limit which developers can commit code to a deployment branch, having other developers commit code to the source-control trunk. When code is ready for deployment, engineers with deploy-branch access can move code into production status and the release manager can release the code to production. This team would still be using one-button deployment tools, but limiting who has access to them. Within the Flickr team, several engineers can commit code to the deployment branch and make a release, while more developers can only release certain portions of the application, such as the configuration module.

Bug trackers are also designed well to scale up with your team. As you add developers, the need to assign bugs becomes very important. Each developer should be able to view all bugs, those assigned to them and those they created, tracking the progress of all issues through the system. As the team grows, it's important that engineers stay on top of the bugs they've been assigned or have opened, closing them down when they're complete. More often than not, bugs get fixed in the code base but not marked as resolved in the tracker or left unacknowledged by the reporter. You should have a clear idea of how a bug report should move through the system, such as who has the responsibility to close the issue (the reporter or the resolving engineer) and what information should be supplied with a resolution (such as source control diffs or release numbers). For medium-sized engineering groups, you might want to consider appointing a bug czar, who has responsibility for assigning, tracking, and managing bug reports within the tracker, making sure issues are kept up-to-date.

A single lead developer can take the role of release manager and bug czar, but these roles are often better given to a secondary engineer so that a process of double-checking is maintained. Stories from development teams inside Microsoft suggest that being forced to be a release manager is punishment for breaking a software build, but treating the role as a punishment rather than an important responsibility may not be the best approach, depending on your development team.