The goal of a CI environment should be to make master branches unbreakable and not to provide a quick feedback when the master branches are broken.
we had some passionate discussions about CI environments. Those discussions started after the reading of "How Google Test Softwares".
What's the current goal of most CI environments ? Notifying you as quick as possible as soon as some master branches have been broken ? With such approach, it's ultimately the responsibility of any developer before pushing some changes into a master branch to make sure that those changes don't break anything : compilation, unit tests, integration tests, ... whereas we all know that :
- The local developer environment is not reliable for such kind of validation
- This can highly impact the developer productivity (what to do when integration tests requires 3 minutes to be executed and consume 100% of the CPU time ?)
- This is a stressful approach for the developer as whatever is the effort provided, the risk to break the build always exists.
Of course, as soon as the build is broken, this becomes the top priority of the developer to fix what he has broken but it's already too late and this is again stressful and counterproductive.
In fact a paradigm shift should occur : whatever the developers are doing, the master branches should be unbreakable. In other words : the CI environment should prevent developers from pushing some changes in the master branches which breaks the build.
If my understanding is correct, this concept is already in place at Google and a CI engine like Team City provides the required feature to "almost" support such approach when feature branches are used and when Team City is configured to automatically create some new jobs when a feature branch is started : (Continuar Lendo)A Step by Step Guide to using GitFlow with TeamCity – Part 4 – Feature Branches in TeamCity