Comments on: Continuous Integration – emphasis on tests not builds? http://www.build-doctor.com/2008/07/15/continuous-integration-emphasis-on-tests-not-builds/ Continuous Integration, Delivery and Devops Consulting Thu, 02 Feb 2012 22:31:14 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Douglas Squirrelhttp://www.build-doctor.com/2008/07/15/continuous-integration-emphasis-on-tests-not-builds/comment-page-1/#comment-180 Douglas Squirrel Thu, 17 Jul 2008 22:18:00 +0000 http://beta.build-doctor.com/?p=69#comment-180 When a product passes its main build, we put a complete build artifact (a .war file, ready to deploy) in a shared folder. When a functional build server is ready for new work, it looks in the shared folder for a new artifact to test. If one is ready, the functional server copies the artifact from the folder to a local directory, then installs it and begins tests. <br/><br/>We wrote a little CruiseControl plugin that reads the master log file and identifies the modifications that triggered the main build, so these show up in CC just as normal and you can work out whom to blame - I mean, who should look at a failure. If the functional build is very slow and the product built multiple times on the master (some of our functional builds are on rather slow servers), the plugin is smart enough to identify all the intermediate changes.<br/><br/>If we ever really needed to, we could link up a functional build with the triggering master build by looking in the log file (the ant task says which file it is copying, and that file carries a timestamp that identifies the main build). In practise, the list of modifications are sufficient to do the trick. When a product passes its main build, we put a complete build artifact (a .war file, ready to deploy) in a shared folder. When a functional build server is ready for new work, it looks in the shared folder for a new artifact to test. If one is ready, the functional server copies the artifact from the folder to a local directory, then installs it and begins tests.

We wrote a little CruiseControl plugin that reads the master log file and identifies the modifications that triggered the main build, so these show up in CC just as normal and you can work out whom to blame – I mean, who should look at a failure. If the functional build is very slow and the product built multiple times on the master (some of our functional builds are on rather slow servers), the plugin is smart enough to identify all the intermediate changes.

If we ever really needed to, we could link up a functional build with the triggering master build by looking in the log file (the ant task says which file it is copying, and that file carries a timestamp that identifies the main build). In practise, the list of modifications are sufficient to do the trick.

]]> By: Julianhttp://www.build-doctor.com/2008/07/15/continuous-integration-emphasis-on-tests-not-builds/comment-page-1/#comment-179 Julian Thu, 17 Jul 2008 21:42:00 +0000 http://beta.build-doctor.com/?p=69#comment-179 Douglas, thanks for sharing. Are you able to say just how the pipeline was implemented? For example, what actually triggers the functional builds and can you easily reconcile them with the fast builds? Douglas, thanks for sharing. Are you able to say just how the pipeline was implemented? For example, what actually triggers the functional builds and can you easily reconcile them with the fast builds?

]]> By: Douglas Squirrelhttp://www.build-doctor.com/2008/07/15/continuous-integration-emphasis-on-tests-not-builds/comment-page-1/#comment-178 Douglas Squirrel Tue, 15 Jul 2008 14:41:00 +0000 http://beta.build-doctor.com/?p=69#comment-178 At youDevise, we have a two-stage pipeline. The main build compiles everything, as you suggest, as well as doing static analysis and unit tests. Then four other machines take the result, deploy it, and run functional tests. (Actually, I should say machine clusters, since we have several slaves parallelising the work at each stage.)<br/><br/>We implemented this about a year ago when we were trying to speed up the pipeline and it seems to work fine; average checkin-to-result time for the second-stage tests that matter is under an hour (though some less-critical tests do take longer). At youDevise, we have a two-stage pipeline. The main build compiles everything, as you suggest, as well as doing static analysis and unit tests. Then four other machines take the result, deploy it, and run functional tests. (Actually, I should say machine clusters, since we have several slaves parallelising the work at each stage.)

We implemented this about a year ago when we were trying to speed up the pipeline and it seems to work fine; average checkin-to-result time for the second-stage tests that matter is under an hour (though some less-critical tests do take longer).

]]>