40. (with egg)

I wrote the following in response to a coworker's questionnaire about continuous integration (CI):

CI's impact has been higher on some projects, while lower on others. If we are including past companies and projects, CI was extremely valuable when builds took a very long time to run on an individual's workstation (such as hours) and when CI tests things that are "hard" to test locally, such as deploys.

In general, CI becomes more important to me as the project becomes larger (resulting in longer test runs) and more complex (resulting in longer overall builds plus technical overhead/pain-in-the-ass factor). For those reasons I really like having CI set up at the beginning of a project in preparation for the impending time-consuming pain-in-the-ass.

Specifically for projects I've worked on, here's how CI has affected me:

• Previous project: Tests took a long time to run because of a huge Selenium suite, so offloading it CI was nice.
• Current project: Test suites, including Selenium, do not take very long so the time savings is not such a big deal.
• Both: Deploy testing is invaluable. We have a complex deploy process at and I sleep better at night knowing that CI is exercising this every time it runs successfully. If CI did nothing but deploy testing then it would be worth it.

Where broken builds have hurt me:

• For both projects a consistently red CI usually meant timing issues in Selenium. On a previous project these were especially annoying, since the build took over 30 minutes. In both projects we have solved these, but they were rarely if ever indicative of a "real" problem -- instead, the we had to make the testing framework handle the timing issues. The end result was that I was "not allowed" to do deploys because our deploy process, if you follow it, relies on a successfully CI run. This is not a criticism of the process: I wish everyone would strictly follow the CI-reliant deploy process because it brings order to chaos and will save you from shooting yourself in the foot by deploying bad code.

"I'll take CI if I can get it, but I don't really care THAT much whether it's there or not".

• Sometimes. It's a continuum. When a project has no deploy process and test take 1 minute run, and the team is 1 pair, then CI is a sledgehammer hitting a nail. For projects larger than then my-workstation-can-quickly-handle-it situation, with long, complex test suites, complex deploy process, CI is very valuable.