<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Making build pain visible</title>
	<atom:link href="http://erik.doernenburg.com/2009/11/making-build-pain-visible/feed/" rel="self" type="application/rss+xml" />
	<link>http://erik.doernenburg.com/2009/11/making-build-pain-visible/</link>
	<description>Just another WordPress weblog</description>
	<lastBuildDate>Mon, 02 Jan 2012 19:53:00 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: Erik Doernenburg</title>
		<link>http://erik.doernenburg.com/2009/11/making-build-pain-visible/comment-page-1/#comment-6234</link>
		<dc:creator>Erik Doernenburg</dc:creator>
		<pubDate>Sat, 20 Feb 2010 03:30:27 +0000</pubDate>
		<guid isPermaLink="false">http://erik.doernenburg.com/?p=334#comment-6234</guid>
		<description>This is a visualisation on top of what our continuous integration (CI) server provides, a visualisation that shows long term trends, the big picture so to speak. 

To answer your question, Thomas, to find out what broke an individual build, we just use the features provided by our CI server. It allows us to see the build output, provides a report on the status of the tests, and it ties that back to the check-ins that triggered the build. 

Martin has a good write-up of the practice on his site: 

http://www.martinfowler.com/articles/continuousIntegration.html</description>
		<content:encoded><![CDATA[<p>This is a visualisation on top of what our continuous integration (CI) server provides, a visualisation that shows long term trends, the big picture so to speak. </p>
<p>To answer your question, Thomas, to find out what broke an individual build, we just use the features provided by our CI server. It allows us to see the build output, provides a report on the status of the tests, and it ties that back to the check-ins that triggered the build. </p>
<p>Martin has a good write-up of the practice on his site: </p>
<p><a href="http://www.martinfowler.com/articles/continuousIntegration.html" rel="nofollow">http://www.martinfowler.com/articles/continuousIntegration.html</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Thomas Emc</title>
		<link>http://erik.doernenburg.com/2009/11/making-build-pain-visible/comment-page-1/#comment-6226</link>
		<dc:creator>Thomas Emc</dc:creator>
		<pubDate>Fri, 19 Feb 2010 13:53:22 +0000</pubDate>
		<guid isPermaLink="false">http://erik.doernenburg.com/?p=334#comment-6226</guid>
		<description>That&#039;s interesting.

What are you doing when the light is red? I mean, How do you figure out what is the reason for the broken build? Do you have any report for the changed files or change-sets, merged files etc.?</description>
		<content:encoded><![CDATA[<p>That&#8217;s interesting.</p>
<p>What are you doing when the light is red? I mean, How do you figure out what is the reason for the broken build? Do you have any report for the changed files or change-sets, merged files etc.?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Links for November 3</title>
		<link>http://erik.doernenburg.com/2009/11/making-build-pain-visible/comment-page-1/#comment-4988</link>
		<dc:creator>Links for November 3</dc:creator>
		<pubDate>Tue, 03 Nov 2009 13:29:26 +0000</pubDate>
		<guid isPermaLink="false">http://erik.doernenburg.com/?p=334#comment-4988</guid>
		<description>[...] visualizes build [...]</description>
		<content:encoded><![CDATA[<p>[...] visualizes build [...]</p>
]]></content:encoded>
	</item>
</channel>
</rss>

