Continuous integration (CI) systems push the compilation, building, and testing of software changes. Either your change is a success, or you failed. Surprisingly, the route to this binary model is implemented in industry projects in a different way, as popular literature describes.

This paper proposes a CI usage metric framework to examine the relationship between the size of software development efforts and the ability to practice CI. The framework encompasses three sets of metrics--software size, organization size, and continuity--to examine if there is any major factor impacting CI practices.

By the book, CI means that a whole developer team works together on the mainline of a software project. Conversely, a first finding of the study is that larger organizations are unable or unwilling to directly integrate code changes with the mainline of a software project.

Another rule of thumb is that every developer should commit to the code repository constantly. The reasoning behind this is that you may have to look for errors in fewer places, because your code changes are made in smaller chunks. Hence, you are expected to fix conflicts faster. However, the paper describes difficulties in industrial projects that work in such a way.

This is an interesting study for readers looking for real-world challenges to CI. One major question remains: Why does CI implementation in industry differ so much from the proposed best practices?