There was a time when the build files and other build-related configuration files and scripts were owned by the build team.   This set of files is commonly referred to as “the makefiles,” even though they now include build files for numerous non-make technologies such as Maven. In those makefile days, the build team made the decision as to when new features were added to the process, and it was appropriate for the build team to own this work. Manual or nightly builds would run successfully after the build team’s makefile changes were added to the branch where the developer’s source code changes were made.

Separating ownership of the makefiles between the developers and the build engineers in today’s continuous integration world would result in an awkward workflow to synchronize source code changes with corresponding build file changes by another team. I have seen this situation cause unstable code lines during the time between the source code change commit and the necessary build file change commits. This instability was disruptive to the development process and completely unnecessary since it can be avoided by shifting ownership of the makefiles to the developers.

Build technology has evolved to the point where developers can (and should) be expected to understand how builds work and make build configuration changes themselves. This has the desired impact of keeping code change sets together with their corresponding build files, as well as tracking feature change decisions since Version Control is Decision History. Continuous integration and other continuous delivery workflows make it necessary for the build file changes and source code changes to be combined.

Developers own the Makefiles

Ask anyone about the benefits of using a version control system (VCS) and you will undoubtedly hear about things like change tracking, release branching, merge tracking, and the ability to roll back changes. But how often have you thought about the version control system as a history of design decisions? This is one way to think about version control – and thinking of it this way helps us notice things in the development workflow that are out of place and need to be changed.

I like to see version control changes made by the person or team who is making the decision in case there is a need for locating the person who made the decision. SCM should not provide a check in service for the development team when it comes to decisions made by someone else. Doing so will sometimes put the SCM team members in a position of having to remember who asked for the change in order to find out why the change was made. In today’s world of agile programming and continuous integration, the decision to include new features is likely owned by the development team, while configuration management teams are more likely to provide quality control services and administration of the build artifacts.

Version Control Is Design History