First Principles

CI is a Mirror

The first principle is that you must not fool yourself, and you are the easiest person to fool. - Richard P. Feynman

Before Continuous Integration, we had a substantial 'works for me' problem. CI was thought of and often sold as a solution to this, but it accomplishes so much more than that.

A CI build is a neutral party. If the code works in CI, but not in your machine, odds are good that the problem is yours. If the code doesn't work on your machine or in CI, then the problem likely exists for everyone, and needs to be acted upon before the lost productivity stacks up. Without that veneer of objectivity, we often play for time. We push back and make the other party prove that we created a problem, so that we don't get preempted from the next activity we are ensconced in for a user error. But people often don't notice when they're being affected by a problem, and may misattribute it to their own changes. The amount of lost time due to a broken trunk is rarely accounted for objectively. However large you think it is, the truth is usually worse.

We Chronicle Actions

Code commits, code reviews, wiki edits, deployments, rollbacks, you name it. We record these actions so that we know when we are done, and we know when things were done. Connecting these artifacts to one another paints a story of what happened, and when.

We Need Actionable Data

In a CI tool, the red build is the ultimate actionable event, but there are so many more that can be measured, tracked, and alerted upon.

Software Development is a Team Activity

I am not the only one who needs to know what I've been working on. Nor is my boss. Ultimately, a problem could arise from any action by any team member (or by external parties). When reacting to a production issue we need to be able to discern what is going on.