<?xml version="1.0"?>
<rss version="2.0">
<channel>
  <title>The Devil in the Details</title>
  <link>http://www.anthillpro.com/blogs/devil-in-the-details/</link>
  <description>A blog about the practice of software development.</description>
  <language>en</language>
  <copyright>Maciej Zawadzki</copyright>
  <lastBuildDate>Wed, 21 Feb 2007 03:08:00 GMT</lastBuildDate>
  <generator>Pebble (http://pebble.sourceforge.net)</generator>
  <docs>http://backend.userland.com/rss</docs>
  
  
  <item>
    <title>Build Types Vs. Build Promotions</title>
    <link>http://www.anthillpro.com/blogs/devil-in-the-details/2007/02/20/1172027280000.html</link>
    
      
      
        <description>
          When it comes to builds, we often talk about build types - a development build, an integration build, a release build, etc.  We very rarely hear people talking (or writing) about build promotions.&lt;p&gt;&lt;a href=&#034;http://www.anthillpro.com/blogs/devil-in-the-details/2007/02/20/1172027280000.html&#034;&gt;Read more...&lt;/a&gt;&lt;/p&gt;
        </description>
      
    
    
    
    <comments>http://www.anthillpro.com/blogs/devil-in-the-details/2007/02/20/1172027280000.html#comments</comments>
    <guid isPermaLink="true">http://www.anthillpro.com/blogs/devil-in-the-details/2007/02/20/1172027280000.html</guid>
    <pubDate>Wed, 21 Feb 2007 03:08:00 GMT</pubDate>
  </item>
  
  <item>
    <title>Archiving Some Past Presentations</title>
    <link>http://www.anthillpro.com/blogs/devil-in-the-details/2006/10/09/1160430180000.html</link>
    
      
      
        <description>
          &lt;p&gt;With the new website, the presentations below have (at least temporarily) lost their home.  So, they are being archived for the time being here.&lt;/p&gt;&lt;p&gt;&lt;a href=&#034;http://www.anthillpro.com/blogs/devil-in-the-details/2006/10/09/1160430180000.html&#034;&gt;Read more...&lt;/a&gt;&lt;/p&gt;
        </description>
      
    
    
    
    <comments>http://www.anthillpro.com/blogs/devil-in-the-details/2006/10/09/1160430180000.html#comments</comments>
    <guid isPermaLink="true">http://www.anthillpro.com/blogs/devil-in-the-details/2006/10/09/1160430180000.html</guid>
    <pubDate>Mon, 09 Oct 2006 21:43:00 GMT</pubDate>
  </item>
  
  <item>
    <title>Archiving the EJB Benchmark</title>
    <link>http://www.anthillpro.com/blogs/devil-in-the-details/2006/10/09/1160422620000.html</link>
    
      
      
        <description>
          We released an EJB benchmark in early 2002 based on some work we did early on with EJBs.  With the new site design, the EJB benchmark would have been lost, and that&#039;s why it ended up on my blog for archiving.&lt;p&gt;&lt;a href=&#034;http://www.anthillpro.com/blogs/devil-in-the-details/2006/10/09/1160422620000.html&#034;&gt;Read more...&lt;/a&gt;&lt;/p&gt;
        </description>
      
    
    
    
    <comments>http://www.anthillpro.com/blogs/devil-in-the-details/2006/10/09/1160422620000.html#comments</comments>
    <guid isPermaLink="true">http://www.anthillpro.com/blogs/devil-in-the-details/2006/10/09/1160422620000.html</guid>
    <pubDate>Mon, 09 Oct 2006 19:37:00 GMT</pubDate>
  </item>
  
  <item>
    <title>The Nuts and Bolts of Release Builds</title>
    <link>http://www.anthillpro.com/blogs/devil-in-the-details/2004/08/16/1092673620000.html</link>
    
      
      
        <description>
          Given that I work for a company that develops an automated build management server, I get to hear about some of the different build and release processes that are in use.  Generally, they all follow the same structure, but there are some variations.  In this month&#039;s column, I would like to present that general structure and talk a little about some of those variations.&lt;p&gt;&lt;a href=&#034;http://www.anthillpro.com/blogs/devil-in-the-details/2004/08/16/1092673620000.html&#034;&gt;Read more...&lt;/a&gt;&lt;/p&gt;
        </description>
      
    
    
    
    <comments>http://www.anthillpro.com/blogs/devil-in-the-details/2004/08/16/1092673620000.html#comments</comments>
    <guid isPermaLink="true">http://www.anthillpro.com/blogs/devil-in-the-details/2004/08/16/1092673620000.html</guid>
    <pubDate>Mon, 16 Aug 2004 16:27:00 GMT</pubDate>
  </item>
  
  <item>
    <title>Part 2 of Sloppy Deployments</title>
    <link>http://www.anthillpro.com/blogs/devil-in-the-details/2004/06/14/1087256940000.html</link>
    
      
      
        <description>
          In my previous post, I wrote about the evils of sloppy deployments.  Two main practices may lead to what I call &#034;sloppy deployments,&#034; they are ...&lt;p&gt;&lt;a href=&#034;http://www.anthillpro.com/blogs/devil-in-the-details/2004/06/14/1087256940000.html&#034;&gt;Read more...&lt;/a&gt;&lt;/p&gt;
        </description>
      
    
    
    
    <comments>http://www.anthillpro.com/blogs/devil-in-the-details/2004/06/14/1087256940000.html#comments</comments>
    <guid isPermaLink="true">http://www.anthillpro.com/blogs/devil-in-the-details/2004/06/14/1087256940000.html</guid>
    <pubDate>Mon, 14 Jun 2004 23:49:00 GMT</pubDate>
  </item>
  
  <item>
    <title>Don&#039;t Let Your Controlled Build Process be Undermined by Sloppy Deployments</title>
    <link>http://www.anthillpro.com/blogs/devil-in-the-details/2004/04/17/1082240280000.html</link>
    
      
      
        <description>
          Deployment management, although not strickly a part of build management, is still a very important topic, as it can render very strong build management practices almost useless.  Recently I&#039;ve ran into several development teams that have what I would call &#034;terrible&#034; deployment proctices.&lt;p&gt;&lt;a href=&#034;http://www.anthillpro.com/blogs/devil-in-the-details/2004/04/17/1082240280000.html&#034;&gt;Read more...&lt;/a&gt;&lt;/p&gt;
        </description>
      
    
    
    
    <comments>http://www.anthillpro.com/blogs/devil-in-the-details/2004/04/17/1082240280000.html#comments</comments>
    <guid isPermaLink="true">http://www.anthillpro.com/blogs/devil-in-the-details/2004/04/17/1082240280000.html</guid>
    <pubDate>Sat, 17 Apr 2004 22:18:00 GMT</pubDate>
  </item>
  
  <item>
    <title>Beyond Continuous Integration</title>
    <link>http://www.anthillpro.com/blogs/devil-in-the-details/2003/11/01/1067716800000.html</link>
    
      
      
        <description>
          Having a team of 10, 30, or 100 developers committing their changes multiple times a day or even on 
a daily basis has the potential of creating chaos.  This is a big point, and one that I would like to explore in a 
little more detail ...&lt;p&gt;&lt;a href=&#034;http://www.anthillpro.com/blogs/devil-in-the-details/2003/11/01/1067716800000.html&#034;&gt;Read more...&lt;/a&gt;&lt;/p&gt;
        </description>
      
    
    
    
    <comments>http://www.anthillpro.com/blogs/devil-in-the-details/2003/11/01/1067716800000.html#comments</comments>
    <guid isPermaLink="true">http://www.anthillpro.com/blogs/devil-in-the-details/2003/11/01/1067716800000.html</guid>
    <pubDate>Sat, 01 Nov 2003 20:00:00 GMT</pubDate>
  </item>
  
  <item>
    <title>Beyond Continuous Integration</title>
    <link>http://www.anthillpro.com/blogs/devil-in-the-details/2003/10/01/1065035880000.html</link>
    
      
      
        <description>
          &lt;p&gt;In this first of a two part series, we are going to try to answer the following question: &lt;br/&gt;
What are the types of builds that you would typically see during the lifetime of a project?&lt;/p&gt;

&lt;p&gt;But before we can start to answer this question, we need to come to an agreement about what happens during the lifetime of a project.&lt;/p&gt;&lt;p&gt;&lt;a href=&#034;http://www.anthillpro.com/blogs/devil-in-the-details/2003/10/01/1065035880000.html&#034;&gt;Read more...&lt;/a&gt;&lt;/p&gt;
        </description>
      
    
    
    
    <comments>http://www.anthillpro.com/blogs/devil-in-the-details/2003/10/01/1065035880000.html#comments</comments>
    <guid isPermaLink="true">http://www.anthillpro.com/blogs/devil-in-the-details/2003/10/01/1065035880000.html</guid>
    <pubDate>Wed, 01 Oct 2003 19:18:00 GMT</pubDate>
  </item>
  
  </channel>
</rss>
