3 Replies to “Tips and Advice: Continuous Integration”
Great discussion, especially about what sorts of tests to run in commit-triggered vs. scheduled builds! I love the phrase “Never let the sun set on a broken build.”
Unfortunately a lot of folks think CI is hard to set up. I think this is a fallacy, especially with the current available CI tools. Atlassian’s Bamboo (http://www.atlassian.com/software/bamboo) will allow you to run your first CI builds within minutes.
We’ve also tried to address the issues of long-running tests with our Clover test optimization for Java (http://www.atlassian.com/software/clover). Clover can detect which classes changed since the previous build and runs just those tests that touch changed classes. In Atlassian’s own build system, this sped up build times for one of our teams from 40 minutes to 7 minutes: http://tr.im/u63V
Agreed, great discussion. I think it is a great way to position Continuous Integration as the stepping stone to so many other good tools and techniques that a development team can use to become more effective. Usually the benefits from CI are so easily understood that there is very little resistance to implementing it. Once CI smooths out the road, then things like automated testing, static and dynamic code analysis, and everything else can start to be added because the foundation works.
Good podcast guys. Definitely a very important topic.
The one thing I was hoping you’d have mentioned was that you should not continue to checkin if the build is broken… other than just to fix the build… for what I’d consider obvious reasons.
Great discussion, especially about what sorts of tests to run in commit-triggered vs. scheduled builds! I love the phrase “Never let the sun set on a broken build.”
Unfortunately a lot of folks think CI is hard to set up. I think this is a fallacy, especially with the current available CI tools. Atlassian’s Bamboo (http://www.atlassian.com/software/bamboo) will allow you to run your first CI builds within minutes.
We’ve also tried to address the issues of long-running tests with our Clover test optimization for Java (http://www.atlassian.com/software/clover). Clover can detect which classes changed since the previous build and runs just those tests that touch changed classes. In Atlassian’s own build system, this sped up build times for one of our teams from 40 minutes to 7 minutes: http://tr.im/u63V
Agreed, great discussion. I think it is a great way to position Continuous Integration as the stepping stone to so many other good tools and techniques that a development team can use to become more effective. Usually the benefits from CI are so easily understood that there is very little resistance to implementing it. Once CI smooths out the road, then things like automated testing, static and dynamic code analysis, and everything else can start to be added because the foundation works.
Thanks for the discussion!
Good podcast guys. Definitely a very important topic.
The one thing I was hoping you’d have mentioned was that you should not continue to checkin if the build is broken… other than just to fix the build… for what I’d consider obvious reasons.