--- In [EMAIL PROTECTED], Ron Jeffries
<[EMAIL PROTECTED]> wrote:
...
> The smaller the time-frame between commits, the more I'd like to
> have an automated setup. //But I want one that pushes code to all
> the other developers, keeping the sandboxes synchronized.//
I'd say that time-frame between commits and updates is a fundamental
consideration which is why my default position is the automated setup.
Eclipse introduced a feature where it would automatically synchronize
on schedule. I don't know if that was kept or not. This is not the
same as forced updates because you still controlled when to actually
take the updates. Continuous forced updates feels wrong to me but I
haven't really tried it. When I think Private Workspace, I think
total control.
> I think that the manual check in is a team-building and
> experience-building practice. A team with existing habits of
> throwing their code at the build and waiting until Friday will, I
> believe, do well to experience building, and its impact, directly,
> hands on, before going to some automated scheme.
My question is, what practice is gained from manual check-in that is
not from an automated scheme? And vice versa?
Off the top of my head, the habits/lessons/practice I want are:
- Commit often. Update even more often.
- The team is responsible for broken builds, not any particular
individual or pair. Particular individuals or pairs involved in the
latest change will be most capable in helping fix a broken build.
- When a build breaks, it's an opportunity for us to learn how to
improve our build, tests, and deployment process.
- "Live" builds that have occasional failures are preferred over
"dead" builds that never break.
> My reasons are primarily social, just as they are for wanting
> planning done on cards rather than in a software tool. First I'd
> like to get the society right, and all the automated things that
> most pre-Agile developers have used have set up almost exactly the
> wrong habits.
My reasons are also primarily social. I'm wondering what the
difference is in what we consider to be right or wrong habits?
Some wrong habits that I'm concerned are more likely acquired with
purely sequential integration is infrequent commits and believing that
the build should never be broken.
I consider CI to be a balancing act between the speed and quality of
integration feedback. There is a continuous pushing of the envelope
toward speed, but we use automated tests to catch us if we push too far.
To Post a message, send it to: [EMAIL PROTECTED]
To Unsubscribe, send a blank message to: [EMAIL PROTECTED]
ad-free courtesy of objectmentor.com
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
