RE: Practice: Daily Deployment

Adrian,

I learned this pattern when adding a second product to a life insurance
system. We had months of development and refactoring to do before we would
be ready to add a new item to a drop-down list. We still deployed every day
so that if one of our refactorings broke the first product we would know
right away. For example, the extracted superclass would get exercised every
day. For a while I felt like we were cheating, we should branch and merge
months later, but once I got used to it I found the constant feedback
valuable and comforting. We were also much more aggressive with refactoring
a single code base than we would have been if we would have had to retrofit
"development" refactorings to the "production" code base. Daily deployment
made this possible.

Does that help?

Kent Beck
Three Rivers Institute

> -----Original Message-----
> From: xpbookdiscussiongroup-hHKSG33TihhbjbujkaE4pw@xxxxxxxxxxxxxxxx 
> [mailto:xpbookdiscussiongroup-hHKSG33TihhbjbujkaE4pw@xxxxxxxxxxxxxxxx] On 
> Behalf Of 
> Adrian Howard
> Sent: Thursday, May 26, 2005 2:22 AM
> To: xpbookdiscussiongroup-hHKSG33TihhbjbujkaE4pw@xxxxxxxxxxxxxxxx
> Subject: Re: [xpe2e] Practice: Daily Deployment
> 
> 
> On 26 May 2005, at 07:20, Kent Beck wrote:
> [snip]
> >  As long as you don't change the user's
> > experience of the system, you can deploy all the rest of 
> that work.  
> > On the
> > last day you put the "keystone" in place, the change to the user  
> > interface.
> [snip]
> 
> Hmmm... how do you manage that in a way that can get you useful  
> feedback? If the new UI is the only way to get at new features  
> they're not going to get tested until the keystone stage. Or am I  
> missing something?
> 
> Adrian