continuousintegration.html

极限编程 Extream Programing

above where the phrase "my version" appears.  This is a particularly
vicious form of ownership that fails in way analogous to the way Ron
sees <a href="http://c2.com/cgi/wiki?CodeOwnership">CodeOwnership</a> failing.  Not all versions are owned
by individuals.  Once they're put back into the version management system,
they belong to the project.  And because the &quot;project&quot; in this case may
be many conventional projects, that must deliver different versions of
the same code, <a href="ContinuousIntegration.html">ContinuousIntegration</a> of versions doesn't work.
<p>
<em>You seem to be saying in the above that the project owns a class, not a code owner. So do we.  Editors just pass through: change, test, release.	But you are coming out in favor of <a href="http://c2.com/cgi/wiki?CodeOwnership">CodeOwnership</a> here?  What am I missing?</em>
<p>
<em>I do see that for each moment in time where code goes to customer, you need to fork that class for updates, so the class has N &quot;live&quot; versions.  And I see that I'd probably want one developer to determine for all N whether and how his particular change applies to that version.  I don't see that the next change needs the same developer (<a href="http://c2.com/cgi/wiki?CodeOwnership">CodeOwnership</a>), and I don't see why version N.2 shouldn't be released to the code base right away (<a href="ContinuousIntegration.html">ContinuousIntegration</a>).  Please help.</em>
<p>
There are places <a href="ContinuousIntegration.html">ContinuousIntegration</a> works.  I accept that claim.  Now,
accept my claim that there are also places it doesn't work.  And let's
differentiate the contexts.
<p>
<em>Totally in agreement with teasing out where and why it won't work.  You know the big problem space far better than I!  See also my new Note in the top part.  Thanks --R</em>
<p>
-- <a href="http://c2.com/cgi/wiki?JimCoplien">JimCoplien</a>
<hr>
I don't see this one as controversial - I've expected daily updates for years. Actually I used to have a backup system which ran nightly and only backed up key parts of the network server, so anything not put under VCS by the end of the day was not backed up. It wasn't acceptable for programmers to have masses of community code that only existed on their machines. It makes me feel uncomfortable just thinking about it.
<p>
Maybe it's worth noting that people put stuff under VCS, and other people updated, when it fitted their personal work schedule. In other words I don't see your changes until I want to. It's daily rather than truly continuous. This avoids some of the feeling of quicksand you can get when the ground changes from under you unexpectedly. You have a stable environment for as many hours as you need to nail down your bug.
<p>
I tried getting people to send out email to the group when they put stuff back, which both notified that a change had been made and also described briefly what it did. The other guys could then go and play with the new features, give them a bit of ad-hoc testing and say, &quot;That's cool&quot; or &quot;That sucks&quot;. The email messages were archived to form a perminant record of daily progress. I don't think this really worked so it got dropped. It might be worth trying again if the group were larger. -- <a href="http://c2.com/cgi/wiki?DaveHarris">DaveHarris</a>
<hr>
Dave, can I ask you to explore a bit what you mean by &quot;I don't see your stuff
until I want to&quot;?
<p>
We did some really cool editor technology here several years back called
colored delta editing;  it's similar to work done in the same era at IBM
by VincentKruskal<a href="http://c2.com/cgi/wiki?edit=VincentKruskal">?</a>.  It allowed you to apply &quot;version filters&quot; so you could
work in the context of any version point, line, plane, hyperplane
or hyper*plane in version space.  (Different versions had different colors,
and you could apply &quot;color filters&quot;.  It also supported truly concurrent
editing and real-time change notification, as well as other goodies.)
<p>
If you work in the context of *all* the versions and see them all the
time, you get nothing done but trying to anticipate how to accommodate
the stuff flying at you.
<p>
If you ignore the changes, then you end playing catch-up when the
changes do become visible.
<p>
The editor technology we used experimentally minimized the physical
dependency problem, but all the deployed systems had the problems
of physical dependencies (which happens when there is a contradiction
about whether to include or exclude different sets of lines under
the influence of pairs of deltas with conflicting insertion/deletion
information).  This problem becomes even worse when you have physical
dependencies--because then you <em>must</em> take the other person's changes.
<p>
The most serious problems related to logical dependencies.
Even though you don't change my module, you interact with it in
subtly different ways.  Or you change both something that calls
me and something that I call in a consistent way, but if I depend
on the semantics instead of just passing the results through,
I'm screwed.  You can't automatically detect these things: it
takes architectural dialogue.
<p>
So you don't even get a chance to <em>ever</em> see how the other
person's changes affect your code, unless you're looking at all
the changes in the system all the time.
<p>
If there is code ownership, you can at least go to the person
in charge of the module and ask if they are affected.  A knowledgable
owner can give a quick answer most of the time.  In absence of
a code owner, everyone has to look at everything.  It's rare that
everyone knows enough about everything to render snap opinions
like this.
<p>
You're damned if you do and you're damned if you don't.
<p>
-- <a href="http://c2.com/cgi/wiki?JimCoplien">JimCoplien</a>
<hr>
<p>
Ah, I'm beginning to see some things.  Help me here, Jim, because we're clearly not damned over here.
<p>
In Smalltalk, methods are maybe 8 lines long, and each one is edited alone.  Most changes are extensions and by their nature cannot negatively impact anything.  Even if they are real changes, in <a href="ExtremeProgramming.html">ExtremeProgramming</a>, we have <a href="UnitTests.html">UnitTests</a> that check whether (a) class X works, and (b) all other classes work in the context of class X.  The <a href="UnitTests.html">UnitTests</a> run in under 5 minutes, checking everything.  (We are only testing around 1000 classes, with only about 20,000 individual checks, but, well, we all know Smalltalk is slow.  C++ would probaby be a lot faster. ;-&gt; )
<p>
This means that when any developer changes a class, she can immediately tell whether she has broken anything in that class, or elsewhere.  
<p>
In your last riff above, Jim, you refer to people having to &quot;ask if they are affected&quot;, and something about &quot;depending on the semantics&quot;.  What are the things in your world that can't be determined by testing (and yet which would break the application if done)?  I would think that if it could break the app, it could be put into a test.
<p>
Thanks --<a href="RonJeffries.html">RonJeffries</a>
<hr>
It sounds like my environment was less complex than Jim's. We were able to give each programmer a complete local copy of the code, so he was never forced to update it by either physical or logical dependancies. Although updating was an all-or-nothing affair; if you took one file you'd usually have to take them all, and people were encouraged to update each file before they first changed it so that they were working on the latest version of it. If cascading updates seemed likely to cause a problem they could skip that step and just merge later.
<p>
<em>You're damned if you do and you're damned if you don't.</em> - Quite so. Subtle interactions between work done by different programmers is a problem regardless of <a href="ContinuousIntegration.html">ContinuousIntegration</a>. Maybe your question is more about how to write <a href="UnitTests.html">UnitTests</a> for this stuff.
<p>
I do think <a href="ContinuousIntegration.html">ContinuousIntegration</a> means you are more likely to discover the problem early. If it doesn't work today and it did work yesterday, you can use the VCS to revert to yesterday's code base, add your changes back, look at the logs to see what other people have been doing, go and talk to them about it. They are more likely to remember what they did yesterday then if you wait a week before integrating. With a daily update, you are less likely to get two simultaneous problems interacting.
<p>
So there are lots of advantages to integrating often. On the other hand, I need to be able to focus on fixing the bugs I just put in, and only those. One thing at a time. I need to eliminate the extraneous changes created by other people.
<p>
The way I manage this is to get my stuff into a decent state before accepting an update. Then I know the new bugs are due to other people's changes and I can concentrate on what they've done. One thing at a time. I alternate between doing real work and merging in the work done by other people.
<p>
Updates are frequent, but not truly continuous. They are not allowed to interrupt the real work - nothing is. Real work requires periods of unbroken concentration, between half an hour and a few hours. The exact time varies; when I'm done, I'm done, and <em>then</em> I can look around, see what everyone else is up to, update my code base, read email or whatever. This point will be reached at different times for different programmers, but every programmer should reach it sometime during each day. Frequent, but at a time of his choosing.