https://citconf.com/wiki/api.php?action=feedcontributions&user=94.192.89.229&feedformat=atomCitconWiki - User contributions [en]2024-03-29T06:53:46ZUser contributionsMediaWiki 1.35.11https://citconf.com/wiki/index.php?title=CI_Smackdown&diff=7102CI Smackdown2008-10-06T16:14:56Z<p>94.192.89.229: New page: This session was a demo of several CI servers. CruiseControl, build-o-matic, Hudson, JetBrains TeamCity, Rational BuildForge, Zutubi Pulse2, Cruise. Related articles: [http://ericlefevr...</p>
<hr />
<div>This session was a demo of several CI servers.<br />
<br />
CruiseControl, build-o-matic, Hudson, JetBrains TeamCity, Rational BuildForge, Zutubi Pulse2, Cruise.<br />
<br />
Related articles:<br />
<br />
[http://ericlefevre.net/wordpress/2008/10/05/back-from-citcon-europe-amsterdam-2008/] Eric Lefevre<br />
<br />
[http://ivan.truemesh.com/archives/000749.html] Ivan Moore</div>94.192.89.229https://citconf.com/wiki/index.php?title=CITCONEurope2008Sessions&diff=7094CITCONEurope2008Sessions2008-10-06T07:09:30Z<p>94.192.89.229: </p>
<hr />
<div>CITCON 2008 Amsterdam Session<br />
<br />
== 10:00 Topics ==<br />
<br />
#[[Selling Automated Acceptance Testing]]<br />
#[[Release Management and Automating Deployment]]<br />
<br />
== 11:15 Topics ==<br />
<br />
#[[Setting up Test Data]]<br />
#[[CitconEurope2009]]<br />
#[[FlickeringBuilds]]<br />
<br />
== 2:00 Topics ==<br />
<br />
<br />
== 3:15 Topics ==<br />
[[Sustainability]]<br />
<br />
== 4:30 Topics ==<br />
#[[Javascript - Who Cares?]]<br />
#[[CI Smackdown]]<br />
<br />
== Books & Polls ==</div>94.192.89.229https://citconf.com/wiki/index.php?title=FlickeringBuilds&diff=7089FlickeringBuilds2008-10-05T15:18:55Z<p>94.192.89.229: New page: Many people have experienced random build failures. Random build failures reduce the motivation for developers to take notice of the build status, make it harder to work out whether the b...</p>
<hr />
<div>Many people have experienced random build failures.<br />
<br />
Random build failures reduce the motivation for developers to take notice of the build status, make it harder to work out whether the build is really broken or not, and make it harder to work out why the build is broken if it really is broken.<br />
<br />
This session was about what causes random build failures, and solutions that people have used, or could potentially use, to deal with them.<br />
<br />
On the flip chart, we wrote up some causes and solutions, which I will transcribe here. I'll also comment on some of the discussion that we had, and the "ah ha" moment that I experienced.<br />
(Note - not quite 100% as on flip chart but very close - sorry I didn't write down solutions for all causes), without much in the way of embedded comments. <br />
I personally don't approve of all the suggested solutions.)<br />
<br />
<pre><br />
Causes Potential Solutions<br />
-----------------------------------------------------------------------<br />
non-deterministic random shit exorcism/comment well known flickering tests<br />
multi-threaded apps test on multi-core machines, slow machines etc to try to make the build fail if the "random" failure is actually a real failure<br />
selenium adding waits/using existence of ids/don't make assertions for things that don't matter<br />
real problems try to make the build fail if the "random" failure is actually a real failure/have a "zero tolerance" approach to "random" failures (aka "broken windows")/KISS<br />
environmental differences virtualization<br />
external dependencies stub them/use a clean version of the external dependency<br />
state of machine/environment/dependencies<br />
interactions and dependencies between tests write isolated tests/run tests in random order to make sure such tests are exposed<br />
windows file handles auto reboot regularly<br />
microsoft<br />
out of memory show what memory usage is<br />
tomcat/redeploying use clean undeploy-deploy rather than redeploy/jetty<br />
incremental builds<br />
infrastructure start time, e.g. spring, hibernate don't use those things<br />
</pre><br />
<br />
Other things that came up in discussion or as suggestions:<br />
<pre><br />
Test your build scripts. Treat them like other production code.<br />
Have a look at Rake http://rake.rubyforge.org/ and "Builder" (I can't find a link to this).<br />
Write the build in Java/language of your choice. (I suggested it might be possible to do this using ant code, <br />
as it's written in java, to save reimplementing lots of things, i.e. effectively using ant but from a java <br />
program that you can write tests for).<br />
Know why your build fails.<br />
If something is causing the build to fail randomly, don't use it.<br />
Keep it simple, stupid! (KISS). If the build fails randomly because the configuration/architecture etc of<br />
your application is really complicated - then make it simpler.<br />
</pre><br />
<br />
Some stuff that came up in discussion, including some comment by me:<br />
<pre><br />
Take a zero tolerance approach - treat every failure as a failure <br />
rather than ignoring things that looks like a "random failure". Work out how to either stop them happening, <br />
or (perhaps more insightfully - this is the "ah ha" that I experienced - I think it was from <br />
http://citconf.com/wiki/index.php?title=Jason_Sankey) make the random failure happen consistently. Many of<br />
the participants agreed to having seen "random" failures that were actually real errors. The existence of<br />
such "random" failures is the reason you need to make sure you understand what has caused the "random" failure,<br />
and why it's a good thing to make such failures happen more rather than less if they expose a real problem.<br />
"Random" failures which are not due to a real error need to be eliminated so that you really do treat all <br />
failures as failures and don't just press "rebuild" on reflex.<br />
</pre></div>94.192.89.229https://citconf.com/wiki/index.php?title=CITCONEurope2008Sessions&diff=7088CITCONEurope2008Sessions2008-10-05T14:34:41Z<p>94.192.89.229: </p>
<hr />
<div>CITCON 2008 Amsterdam Session<br />
<br />
== 10:00 Topics ==<br />
<br />
#[[Selling Automated Acceptance Testing]]<br />
#[[Release Management and Automating Deployment]]<br />
<br />
== 11:15 Topics ==<br />
<br />
#[[Setting up Test Data]]<br />
#[[CitconEurope2009]]<br />
#[[FlickeringBuilds]]<br />
<br />
== 2:00 Topics ==<br />
<br />
<br />
== 3:15 Topics ==<br />
[[Sustainability]]<br />
<br />
== 4:30 Topics ==<br />
[[Javascript - Who Cares?]]<br />
<br />
== Books & Polls ==</div>94.192.89.229