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