http://accurev.com/blog/2008/04/30/continuous-integration-the-temptation-of-the-antipattern/ SCM and Agile Software Development Blog Wed, 04 Jan 2012 22:30:54 +0000 hourly 1 http://wordpress.org/?v=3.3 http://accurev.com/blog/2008/04/30/continuous-integration-the-temptation-of-the-antipattern/comment-page-1/#comment-452 Chris Boran Sat, 10 May 2008 12:54:21 +0000 http://blog.accurev.com/?p=138#comment-452 I totally agree with Jonas - it is the classic: when you have a hammer, every problem looks like a nail. CI has a sweet spot and you will be best served to stay in it - rapid basic error checking. CI should not replace ALL automation. What have done is to have a CI build ongoing constantly that runs the 'essential' unit tests, and a build nightly that also runs all of the automated tests and tools, and takes much longer. What is possible is to reuse your CI framework to do those automations, just don't try to run the automations continuously. I totally agree with Jonas – it is the classic: when you have a hammer, every problem looks like a nail. CI has a sweet spot and you will be best served to stay in it – rapid basic error checking. CI should not replace ALL automation. What have done is to have a CI build ongoing constantly that runs the ‘essential’ unit tests, and a build nightly that also runs all of the automated tests and tools, and takes much longer. What is possible is to reuse your CI framework to do those automations, just don’t try to run the automations continuously.

]]> http://accurev.com/blog/2008/04/30/continuous-integration-the-temptation-of-the-antipattern/comment-page-1/#comment-453 Jonas Sun, 04 May 2008 16:36:17 +0000 http://blog.accurev.com/?p=138#comment-453 I think the anti-pattern here is trying to fit it all into a single build. We have four builds on our main product, two nightly (one for code-coverage and static code analysis and another for the "release build") and two "daily" (one for the core product and one for database delta upgrade scripts). This enables us to catch the criticals right away, but still have data for more long term maintenance/improvements. I think the anti-pattern here is trying to fit it all into a single build. We have four builds on our main product, two nightly (one for code-coverage and static code analysis and another for the “release build”) and two “daily” (one for the core product and one for database delta upgrade scripts). This enables us to catch the criticals right away, but still have data for more long term maintenance/improvements.

]]>