Continuous Integration Best practices: #4 Never go home on a broken build
Company Blogs July 19, 2013 By Manuel de la Peña Staff
I love that picture! Imagine yourself any Friday, at the end of your day-work. You look at the CI server and, unluckily, it is broken. You have only three options:
- Resign yourself that you will be leaving late, because you'll try to fix it.
- Revert you changes and retry next week.
- Leave now and leave the build broken.
Of course, the best choices are to choose number 1 or number 2, never number 3. In the above picture, Iron-man decided that he doesn't mind what will happend after that "bomb". But why is it a bomb to leave the build broken?
It's a bomb, because any co-worker that pulls from your master branch will get dirty code. And what happens with this? Please look back to my first post about don't check-in on a broken build.
On the other hand, if you try to solve, or even revert your changes before leaving, you will keep the build green, and other developers will be happy to pull safe code from SCM repository.
Some good practices to avoid potential problems are:
- Check in frecuently and early enough to give yourself time to deal with problems should they occur
- Experienced developers often save checks in for the next day
Well, at this point you could say: "Ok, I follow similar practices but my team is distributed and we have problems working in different time zones".
In Liferay we actually have this "problem":
As you can see, we work in different time zones: China, Europe and America, following the sun.
In case of problems:
- If China breaks the build... then Europe day's work is dramatically affected
- If Europe goes home on a broken build... America would be screaming and crying