Why to force so many check-in rules during the CI build?

This is the second blog of a series of posts about the topics Continuous Integration and Continuous Delivery. It explains how important continuous integration is to deliver software in short iterations to the customer with a high quality standard.

Why to force so many check-in rules during the CI build?

The reason seems pretty simple: I have seen over and over again in the projects I was working that every rule which is not enforced during the check-in process will be broken sooner or later.

Usually, this is not done on purpose. There are multiple reasons for that. Most of the time due to high time pressure in the projects or because the developer is deeply focused on the current task and forgets just about it. But the rules and guidelines can also be misunderstood or just forgotten when definitions are discussed in a meeting or send as mail.

Another reason for check-in rules is that this approach saves a lot of time and money because problems are detected before they are actually integrated in the main code. During the architecture and code reviews, the architects can focus on other more important things than static dependencies and code metrics.

In general, every important change in the design of the application is forbidden by check-in rules. It will be all the time an explicit change and not done by accident without noticing it. A good example for that is ReShaper. It is a great tool of course, everybody should have it. But it has a feature, for instance, which detects the namespace and assembly when you just type-in the class name. It automatically adds a reference to the assembly in the current project. I often catch myself adding unwanted references while I am coding and trying to solve my local problem.

All of these problems can be avoided by using good static analysis tools during the check-in process:

Another good approach is:
When you find a problem in a code review, you can create a rule which detects this violation in the future. It is like writing unit tests to check the software architecture.