headers
Slava Imeshev | 1 Feb 2007 01:18
Picon
Favicon
Gravatar

Re: Continuous Integration Question

--- Psychie Naill <psychieslash <at> gmail.com> wrote:
> I've spent a fair while researching continuous integration. From what I
> gather the code is compiled and tested after being checked into the
> repository and the results are unknown until afterwards. This suggests that
> the head revision in the repository will more than likely be unstable most
> of the time. This to me, in my limited experience seems, for want of a
> better work, "un-good". I like to only check passing code into the
> repository. 

Letting code into repository only after it has been pronounced 
good by a judging third-party is extremely inefficient, no matter 
if a judgment is made automatically or by hand.

> This might seem like a stupid question but how come no-one has
> come up with a way to only allow passing code into a repository? 
> Would such a system be counter productive?

It is counterproductive. A much more efficient approach is using
"good-faith check-in" approach. You run you build and tests cleanly
before checking in, update to the latest, repeat clean build and tests.
To your best knowledge your submission is clean so you check in.

There is a chance of breaking the build as a result of an in-flight 
code or semantics-level conflict or an environment mismatch here, 
but this kind of build breakage is caught by a Continuous Integration 
server like our Parabuild, and is immediately reported back to you so 
that you can fix the build and move on.

The efficiency here is that before-check-in local integration is performed
in parallel by all member of the team. Any other system using of a form of
(Continue reading)

Permalink | Reply | 100 comments |
headers
Slava Imeshev | 1 Feb 2007 01:36
Picon
Favicon
Gravatar

Re: Continuous Integration Question

----- Original Message ----- 
> There are two ways to get what you describe, a tool and a practice.
> 
> On the practice side read up on "Rubber Chicken" continuous integration:
> 
> http://www.jamesshore.com/Blog/Continuous-Integration-on-a-Dollar-a-Day.html

I call that approach "Dead Chicken Token". In  the particular case the idea of 
asking for *that* to check in your changes would make most of the engineers 
I know plain sick (or at least guilty :)

Tokens are bad in general because 1) they serialize check ins which doesn't 
work in real-life products b) promote deepening distrust in the code base

> On the tool side various systems offer "unbreakable builds". The idea
> is described here:
> 
> http://blogs.codehaus.org/people/vmassol/archives/000937_unbreakable_builds.html
> 
> However... in my experience the situation you describe -- code usually
> broken -- isn't what happens in practice, but two things are required:
>
>   1. the developers need the ability to self-check before committing.
> If I can't easily run the same build locally then I can't take the
> steps to ensure I don't break anything.

Exactly.

>   2. the team culture must be that any broken builds are a
> stop-the-line showstopper issue that should be addressed immediately.
(Continue reading)

Permalink | Reply | 2 comments |
headers
William Pietri | 1 Feb 2007 04:37
Favicon
Gravatar

Re: How does your user story board work?

Psychie Naill wrote:
> In relation to the generic task board, (which by the way I love; if only I
> had the time to make one :), in Williams team room; this suggests that each
> of the next nine week's iterations are planned out already. I thought the
> idea of the iteration planning meeting was to plan only the next iteration.
> I wonder how he would account for inaccurate estimates? If a card had to be
> moved to the next iteration, how would it affect the flow of things?

If you'd like one, I should mention that my brother is a 
furniture-maker, and is now making much nicer ones than what you see in 
those photos. I'm glad to put people in contact with him; just drop me a 
line off-list.

Regarding those photos, we actually used two boards. The long-term 
product plan was kept on the big board:

    http://www.scissor.com/resources/teamroom/#storycards

Every week at the iteration planning meeting, we would move the 
completed stories to the completed-stories zone at the top. We'd then 
select the cards for the next iteration, and the product manager would 
adjust the cards for the next couple of months of work. The only thing 
we took very seriously was the next iteration's work; the rest was just 
our best guess based on current priorities and recent velocity.

Once we had selected the work for the iteration, we'd break down each 
selected story on the whiteboard:

    http://www.scissor.com/resources/teamroom/#current
(Continue reading)

Permalink | Reply | 1 comment |
headers
William Pietri | 1 Feb 2007 04:48
Favicon
Gravatar

Re: Continuous Integration Question

Psychie Naill wrote:
> Hi there,
>
> I've spent a fair while researching continuous integration. From what I
> gather the code is compiled and tested after being checked into the
> repository and the results are unknown until afterwards. This suggests that
> the head revision in the repository will more than likely be unstable most
> of the time.

I've seen projects where the head is usually unstable, but continuous 
integration generally helps that. The trick is to make it obvious when 
somebody breaks the build. CruiseControl will send emails, for example.

Personally, though, I prefer to make it visible even to people not 
reading email. On one project, our build server made different sounds 
for successful and failed build. The failure noise (which I think was 
the Pac-Man "a ghost got you" noise) would cause everybody to look at 
the CI web page to see who to tease.

On another project, I used an Ambient Orb:

http://xp123.com/xplor/room-gallery/index.shtml#team4

If a build broke, the orb would start as orange-red and get redder and 
redder, eventually even blinking. When fixed, the orb started as a 
sickly yellow-green and got greener and greener.

The great thing about the orb was that it was the one thing that a 
manager could walk in the room and instantly understand. With that 
project, there was never a mandate that we not break the build, but the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ron Jeffries | 1 Feb 2007 05:33
Favicon

Re: Convincing a team about collaborative office space

Hello, Phlip.  On Wednesday, January 31, 2007, at 3:39:21 PM, you
wrote:

>> Phlip, was that supposed to be funny?

> No.

Good.

Ron Jeffries
www.XProgramming.com
If another does not intend offense, it is wrong for me to seek it;
if another does indeed intend offense, it is foolish for me to permit it.
  -- Kelly Easterley

To Post a message, send it to:   extremeprogramming <at> eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe <at> eGroups.com

ad-free courtesy of objectmentor.com 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/extremeprogramming/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/extremeprogramming/join
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ron Jeffries | 1 Feb 2007 05:34
Favicon

Re: Continuous Integration Question

Hello, Slava.  On Wednesday, January 31, 2007, at 4:18:14 PM, you
wrote:

> Letting code into repository only after it has been pronounced 
> good by a judging third-party is extremely inefficient, no matter 
> if a judgment is made automatically or by hand.

Why's that? If you're going to test it anyway, why not test it
first? And if you're not going to test it, why write it, since if it
doesn't have to work, a shorter program would suffice.

Ron Jeffries
www.XProgramming.com
Logic is overrated as a system of thought.

To Post a message, send it to:   extremeprogramming <at> eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe <at> eGroups.com

ad-free courtesy of objectmentor.com 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/extremeprogramming/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/extremeprogramming/join
(Continue reading)

Permalink | Reply | 99 comments |
headers
Jeffrey Fredrick | 1 Feb 2007 05:32
Picon
Gravatar

Re: Continuous Integration Question

On 1/31/07, Slava Imeshev <imeshev <at> yahoo.com> wrote:
> ...
> Along these lines, here is a presentation on best practices for pain-free
> continuous integration:
>
> http://tinyurl.com/23c4o3
>

That's a nice presentation (putting aside the last slide).  :)

Have you seen these numbers from Cusumano?

"Trade-offs between Productivity and Quality in Selecting Software
Development Practices", IEEE Software, Sept-Oct 2003
Impact of daily builds: 93 percent gain in productivity
Impact of regression testing on code check-in: 36 percent reduction in
defect rate

To me the combination of these two just beg for CI.

Jtf

--

-- 
http://www.developertesting.com/
http://www.junitfactory.com

To Post a message, send it to:   extremeprogramming <at> eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe <at> eGroups.com
(Continue reading)

Permalink | Reply | 1 comment |
headers
Slava Imeshev | 1 Feb 2007 06:45
Picon
Favicon
Gravatar

Re: Continuous Integration Question

----- Original Message ----- 
> Have you seen these numbers from Cusumano?
> 
> "Trade-offs between Productivity and Quality in Selecting Software
> Development Practices", IEEE Software, Sept-Oct 2003
> Impact of daily builds: 93 percent gain in productivity
> Impact of regression testing on code check-in: 36 percent reduction in
> defect rate
> 
> To me the combination of these two just beg for CI.

Daily builds are so eighties... In fact, for many companies even daily 
builds is a leap forward.  Which makes me wonder why.  

To Ron Jeffrey:

You are dealing with  customers face-to-face often - do you have ideas why 
build management (not to mention continuous integration) falls behind? 

My personal theory is that it because academia hasn't picked it up yet.

Regards,

Slava Imeshev
www.viewtier.com

To Post a message, send it to:   extremeprogramming <at> eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe <at> eGroups.com
(Continue reading)

Permalink | Reply | 0 comments |
headers
Slava Imeshev | 1 Feb 2007 07:03
Picon
Favicon
Gravatar

Re: Continuous Integration Question

Ron,

----- Original Message ----- 
> > Letting code into repository only after it has been pronounced 
> > good by a judging third-party is extremely inefficient, no matter 
> > if a judgment is made automatically or by hand.
> 
> Why's that? If you're going to test it anyway, why not test it
> first? 

I think there is some misunderstanding here. I am all for everyone
running build and tests cleanly before checking in. It is serializing
checkins that is bad because it slows down integration.

Our shop is all-XP. Parabuild has been running over 3000 unit tests up until 
recently at every check in. But  the test time started taking quite some time so 
we have moved some of tests to a backline build that runs hourly rather than 
continuously. This approach works well with the growing test base.

> And if you're not going to test it, why write it, since if it
> doesn't have to work, a shorter program would suffice.

Exactly. 

Regards,

Slava Imeshev
www.viewtier.com

To Post a message, send it to:   extremeprogramming <at> eGroups.com
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nam Dao Xuan Thien | 1 Feb 2007 14:11
Picon

Productivity Metrics

Hello,

My name is Sal Bruno.  I am a program metrics coordinator for my company and
joined this group to grow in my abilities and skills in producing leading
edge metrics for a CMMI Level 5 company.

I am creating new metric - the productivity metric.  This metric is an
aggregated metric from SPI and CPI.  This metric is an indicator to
compliment the traditional Progress Metric which is simply planned verses
actual.  I would like feedback, constructive criticism, and recommendations
from the group.

The Productivity Index = [ P – (R – E)] / P x 100 %

            Where   P = Planned hours (or BCWS)

                        A = Result hours (or BCWP)

                        E = Actual hours (or ACWP)

Example:          In creating the program plan, it was estimated that it
takes 1 hour to build 1 widget

You plan 8 hours to build widgets today – Planned hours (8 widgets)

                        You actual product (the result) 11 widgets – Result
hours (11 hours are reported to represent 11 widgets)

                        You actually work 11 hours – Actual hours – Actual
hours worked that day
(Continue reading)

Permalink | Reply | 9 comments |

Gmane