<?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: The Build Pipeline</title>
	<atom:link href="http://thetoolsmiths.org/2009/01/28/the-build-pipeline/feed/" rel="self" type="application/rss+xml" />
	<link>http://thetoolsmiths.org/2009/01/28/the-build-pipeline/</link>
	<description></description>
	<lastBuildDate>Mon, 08 Mar 2010 23:40:21 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Anthony Brien</title>
		<link>http://thetoolsmiths.org/2009/01/28/the-build-pipeline/comment-page-1/#comment-282</link>
		<dc:creator>Anthony Brien</dc:creator>
		<pubDate>Wed, 28 Jan 2009 16:51:26 +0000</pubDate>
		<guid isPermaLink="false">http://toolssig.wordpress.com/?p=8#comment-282</guid>
		<description>We have a very similar build system as the one you describe for Orbus, where a couple of tools testers will regularly approve versions so that the team only updates to stable versions.

Another thing to consider on large project with a large number of developers (lots of checkins) is that you need the build system to validate the build as quickly as possible. This is not so obvious if you have a lot of projects, platforms, data binarizations, tests, etc. A good way to do accelerate that is to distribute the build on as many machines as possible. This can make a huge difference, where a build that would take 5 hours will finish in 15 minutes. On my team we have a custom build system to do distributed builds, but I&#039;ve heard great things about Anthill to handle the build farm more dynamically. You can assign all your team members machine has potential &quot;agents&quot;, so the more machines are idle the faster the build. (But Anthill is not free :( )

On large teams, you also need a way to effectively communicate with everyone the status of the build, you may want to block all other checkins until a fix, and if your team is large or in disconnected location, a system to know if someone is working on a fix to avoid multiple programmers working on the same fix.

Another problem I&#039;ve seen on very large complex multi-platform projects, is often developers will break the build cause they simply do not have the time at each checkin to compile the multitude of targets (platforms, configs, tools, etc). It would take hours to validate at each change. Some programmers will rely on the build system, but this can paralyze the entire team. A better solution is to have validation tools integrated into the source control client. For example, you can do a quick compilation, just of the files that have changed, on a couple of configs/platforms to trap the majority of build break errors locally, before they make it to the build system.</description>
		<content:encoded><![CDATA[<p>We have a very similar build system as the one you describe for Orbus, where a couple of tools testers will regularly approve versions so that the team only updates to stable versions.</p>
<p>Another thing to consider on large project with a large number of developers (lots of checkins) is that you need the build system to validate the build as quickly as possible. This is not so obvious if you have a lot of projects, platforms, data binarizations, tests, etc. A good way to do accelerate that is to distribute the build on as many machines as possible. This can make a huge difference, where a build that would take 5 hours will finish in 15 minutes. On my team we have a custom build system to do distributed builds, but I&#8217;ve heard great things about Anthill to handle the build farm more dynamically. You can assign all your team members machine has potential &#8220;agents&#8221;, so the more machines are idle the faster the build. (But Anthill is not free <img src='http://thetoolsmiths.org/wp-includes/images/smilies/icon_sad.gif' alt=':(' class='wp-smiley' />  )</p>
<p>On large teams, you also need a way to effectively communicate with everyone the status of the build, you may want to block all other checkins until a fix, and if your team is large or in disconnected location, a system to know if someone is working on a fix to avoid multiple programmers working on the same fix.</p>
<p>Another problem I&#8217;ve seen on very large complex multi-platform projects, is often developers will break the build cause they simply do not have the time at each checkin to compile the multitude of targets (platforms, configs, tools, etc). It would take hours to validate at each change. Some programmers will rely on the build system, but this can paralyze the entire team. A better solution is to have validation tools integrated into the source control client. For example, you can do a quick compilation, just of the files that have changed, on a couple of configs/platforms to trap the majority of build break errors locally, before they make it to the build system.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
