Anyone who have ever seen something like that might relate to this post:
Breaking the CI is not nice, however it does happen at times. When it happen, someone (myself this time) is appointed responsible, and will fix the build asap.
However, sometimes people do break the CI and then go home without fixing it
There are a few ways to deal with that. Usually you’d call the person who did the commit that made the build fail, and will consult with him about the best way to fix it quickly until he gets back. But sometimes it would prove complex to fix for someone that try to come in without having good knowledge on the full context.
So would you keep the CI red? that’s really bad, as you won’t get good feedback if someone else commits bad work, as it won’t turn to red, it would rather simply stay red.
At these times you’d simply wish that the person who broke the build wouldn’t have committed his change in the first place.
That’s what source control is for.
Just fire up your Subversion Log, gitk, whatever (I guess that even TFS has that ability ;) ), figure out the offending commit id, and revert these changes.
Then you get your CI in a good shape again, and you are free to break it in the regular day-to-day manner.
The CI breaker will then come back in tomorrow and will examine his change, then re-apply it correctly.