continuousintegration.html

极限编程 Extream Programing

<p>
Another issue is that an update is fairly time consuming. Say 20 minutes in my (C++) environment? For that reason alone you wouldn't want to do it every hour. You can gain a little bit by postponing several updates and doing them all at once, especially if a single file changes in each update. But you don't gain much. I'd expect DailyIntegration<a href="http://c2.com/cgi/wiki?edit=DailyIntegration">?</a> provides the best balance of forces for quite a fair range of team sizes. 
<p>
I've rambled; I hope this helps anyway. -- <a href="http://c2.com/cgi/wiki?DaveHarris">DaveHarris</a>
<hr>
Does help.  I'm putting this down here 'cause I'm not ready to put it above.
<p>
How frequently should you integrate?  
<p>
<OL>
<li> Don't integrate in mid-task.  It can only hurt you then. (<em>actually, it can be okay here if you have a checkpoint+rollback facility in your VCS. See <a href="http://c2.com/cgi/wiki?SteveBerczuk">SteveBerczuk</a>'s PrivateVersioning<a href="http://c2.com/cgi/wiki?edit=PrivateVersioning">?</a> pattern</em>)
<li> Do integrate after you complete each task, if practical.  This minimizes conflict resolution next time.
<li> If integration takes longer than a coffee break, or requires manual intervention, you'll be tempted to do it less frequently.  Ideally, fix the integration process.  If you don't, you'll increase conflicts.
<p>
</OL>
Even in C3, <a href="ContinuousIntegration.html">ContinuousIntegration</a> isn't continuous.  We do try to integrate our individual workspaces after every task, and that can be a very short time, never less often than daily.  The <em>idea</em>, however, is that (a) you never want to edit over anyone else's edits, therefore you want to be integrated, and (b) you don't want other guys' edits to get in your way as you work, and (c) the longer you wait to integrate, the harder it is.  --<a href="RonJeffries.html">RonJeffries</a>
<hr>
Like Jim, I too have worked both on projects where <a href="ContinuousIntegration.html">ContinuousIntegration</a> works and on ones where it fails. In both sets of cases, although <a href="http://c2.com/cgi/wiki?CodeOwnership">CodeOwnership</a> certainly affected things positively much of the time, it was not required for success. The success of this technique most assuredly has something to do with the complexity of the version space (as Cope noted earlier). More on some of that in a minute.
<p>
There are a number of issues arising from the sentiment &quot;<em>What if they made their (correct) change, and presto! everyone's computer instantly had that version of the module?&quot;</em>
<p>
The above is probably not <em>really</em> what you want, nor what you are truly doing. If it was, all you need is to have all of you make your changes in the very same workspace (with some versioning and concurrent editing facilities). Even if you managed to work on separate files all the time, this is still not what you usually want to happen. The problem is that others don't get to choose when they are ready to deal with your code. You may make some changes which impact the coding task I'm working on, even if it doesn't touch the same files, and now you've just broken my code. I was perhaps in the middle of some important train of thought and now I do not have the option of finishing my flow first, and then dealing with your changes.
<p>
You folks may be doing &quot;daily&quot; or even &quot;hourly&quot; integration (or even more frequently), but it's not quite the same thing as continuous integration because it's still in discrete chunks, and you still retain the choice over precisely when to integrate (pull); its not thrust upon you while your changes are in a volatile state (push). If you have ever used <a href="http://c2.com/cgi/wiki?ClearCase">ClearCase</a> and had people selecting the LATEST versions on the codeline while checking them in and out at the same time, then you will run into this problem (courtesy of its Virtual File System).
It happens far more often than you would think. And it hurts when it bites you.
<p>
Fortunately, you aren't doing true continuous integration, more like &quot;Quantum Integration.&quot; The integrated change-quanta are very small and are done very frequently; but it's not instantaneous, and the developer controls when it happens in their workspace (which is a crucial difference).
<p>
As for the context in which I've seen <a href="ContinuousIntegration.html">ContinuousIntegration</a> succeed... Like Jim said, the version-space is very constrained in terms of the dimensionality exploited. Almost all codelines are along a single dimension, that of delivery (functionality to be delivered in a release - at varying levels of scale. e.g.,
fix, feature, major/minor release, or patch). And there aren't that many parallel codelines going on at the same time either, even though it's almost all in one dimension. Anywhere from 1-3 codelines is the average (a &quot;recent maintenance&quot; line, a development line for the next release, and possibly early/overlapping development for the subsequent release). I don't think I've ever seen it work well with more than 4 concurrent codelines, or with more than 2-3 dimensions of the version-space being employed at the same time.
<p>
--<a href="http://c2.com/cgi/wiki?BradAppleton">BradAppleton</a>
<p>
[See also <a href="http://c2.com/cgi/wiki?ConcurrentVersionsSystem">ConcurrentVersionsSystem</a>.]
<hr>
&quot;<a href="ContinuousIntegration.html">ContinuousIntegration</a>&quot; is a slogan, not a description. It is deliberately overstated to emphasize that DailyBuild<a href="http://c2.com/cgi/wiki?edit=DailyBuild">?</a>'s are not enough.
<p>
That said, there are things that make integration hard, and things that make it easier-
<p>
Multiple code lines. Doctor, it hurts when I do this. Don't. One code line. Always.
<p>
Check in conflicts. Smaller pieces reduces the probability of conflicts, so make methods the grain size of CM. --<a href="KentBeck.html">KentBeck</a>
<hr>
For many projects, multiple-codelines can actually makes things much easier than forcing adherence to one and only one codeline. For other projects, it definitely hurts. Use one codeline if you can easily get away with it. It would be nice to have a universally applicable rule of thumb that works all, or even most of the time; Unfortunately that isn't the case here (but perhaps that could be argued for the specific nature of XP projects).
<p>
<em>In many years, this reader has split codelines about twice. and regretted it. single code line, conditional compilation works better.</em>
<p>
Using more than one codeline is useful for a great many things that have little in common with conditional compilation. Most of them (but not all) are concerned with issues of parallel-development activity/releases rather than environmental and functional variations (keep in mind the difference between parallel development versus concurrent development).
Conditional compilation and codeline-splitting are intended to solve different problems. Splitting codelines to accommodate platform variations is usually ill-advised; Even conditional-compilation isn't usually the best choice here (c.f. Spencer &amp; Collyer in &quot;<em>#ifdef Considered Harmful</em>&quot;). The recommended solution for this is <strong>separate</strong> compilation rather than conditional compilation: Split the platform-specific code into separate compilation units or sub-units, much like Doug Schmidt's WrapperFacade<a href="http://c2.com/cgi/wiki?edit=WrapperFacade">?</a> pattern.
<p>
There are good reasons and bad reasons to split codelines; and once you do there are good ways and bad ways to do it. But the splitting itself is not intrinsically bad; its splitting for the wrong reasons or in the wrong ways. There are in fact many good reasons and ways to go about it and many shops use them daily. Not only does it contribute to their success in these cases but its often the lynch-pin for it.
<p>
In many years, I have come across several hundred projects of all shapes and sizes; A great many of them rarely split codelines and/or regretted it when they did; an equally great many of them split codelines (often after trying everything to avoid it) and life was considerably better for them afterward, and they have continued this trend with marvelous success. Perhaps it's an acquired taste, and those who have bad initial experiences tend to discard it while those who have success with it do not. But the good reasons and practices for code-splitting not only recur, but abound with much regularity (and, unfortunately, so do the bad ones ;-)
<hr>
All code in every ExtremeTask<a href="http://c2.com/cgi/wiki?edit=ExtremeTask">?</a> has the same owner. Luck is not involved. Clearly a typical change affects at least one method. (Exceptions for change to a class definition with no methods, or const definitions if your language has them. Principle applies anyway.) Release all those methods changed. It is sufficient to release no others. If you release more methods than you change, there is a higher probability of conflict. So don't do that. 
<p>
Some code managers can't manage below the file level. Is it possible to put one method per file? If not, try one class per file and accept more conflicts. It won't be better, but it might be the best you can do.  --<a href="RonJeffries.html">RonJeffries</a>
<p>
<em>Many thanks for the clarification!</em> So the logical granule is a single method/function and the physical granule might have to be force-fitted to make the mapping one-to-one. The file-per-function approach is/was very common in C, and in other languages for this very reason.
I imagine good factoring and merciless <em>re</em>factoring help ensure a one-to-one mapping between methods and logical-change-tasks (maybe not just of the code, but of the work that creates &amp; modifies the code).
<hr>
The <a href="http://c2.com/cgi/wiki?VcapsProject">VcapsProject</a> has had much success with the practices of <a href="ContinuousIntegration.html">ContinuousIntegration</a>.  A couple of key factors we found were required to be successful:
<p>
- <a href="UnitTests.html">UnitTests</a> are an absolute gotta-have.  
No one releases unless they run at 100% !!  If they don't, your changes are not going in.
<p>
- Everyone has <a href="http://c2.com/cgi/wiki?CollectiveCodeOwnership">CollectiveCodeOwnership</a> for all of the code.
That is, each time a pair programmers touch the code, it should get improved, refactored, and simplified
<p>
- There must be a <a href="http://c2.com/cgi/wiki?SingleReleasePoint">SingleReleasePoint</a>.
NO ONE releases from their own workstation.
<p>
- As Ron (and others) have stated above, INTEGRATE OFTEN !! The longer you wait to integrate, the more pain you will create.
<p>
- <a href="ContinuousIntegration.html">ContinuousIntegration</a> (as a slogan) is done in our environment (both for <a href="http://c2.com/cgi/wiki?VisualWorks">VisualWorks</a> code, and <a href="http://c2.com/cgi/wiki?GemStone">GemStone</a> code) in a matter of <em>minutes</em>, usually
<em>seconds</em>!  Developers integrate multiple times per day in practice.
If it takes too long to integrate your changes, then the task unit of work is too big!  The pair is responsible for creating their own <a href="IntegrationHell.html">IntegrationHell</a>, or heaven, whichever they prefer...
<p>
A counterpoint to some of the arguments against <a href="ContinuousIntegration.html">ContinuousIntegration</a> noted above:  
<p>
<em>Simply implementing one or two <a href="ExtremeProgramming.html">ExtremeProgramming</a> practices without adopting the entire mental model of ExP, is like a jigsaw puzzle with missing pieces (per <a href="DonWells.html">DonWells</a>).  Of course, you can't see the whole picture, and you can find numerous reasons why any one practice by itself seems flawed, won't work for you, and difficult for you to succeed. The components of <a href="ExtremeProgramming.html">ExtremeProgramming</a> practices should be seen as an entire methodology (Systems Thinking), each piece facilitates and is facilitated by another.</em>
--<a href="http://c2.com/cgi/wiki?JeanineDeGuzman">JeanineDeGuzman</a>
<hr>
I understood much of the above to be trying to flesh out the context in which
<a href="ContinuousIntegration.html">ContinuousIntegration</a> does and doesnt work, not necessarily trying to argue against it. I know from firsthand experience that this practice is not specific to XP because Ive seen it used successfully many times in non-XP environments. Ive also seen it fail in many different environments (also non-XP). So I am confident that the keys to its success transcend XP, and arent specific to the rest of XP. The discussion above that point out potential flaws or weaknesses help serve to identify the forces which drive the pattern and the context in which it can succeed. 
<hr>
<a href="http://www.martinfowler.com/articles/continuousIntegration.html">http://www.martinfowler.com/articles/continuousIntegration.html</a>
<hr>
<a href="http://c2.com/cgi/wiki?TopicGlossaryXp">TopicGlossaryXp</a>
<hr>
<a href="http://c2.com/cgi/wiki?edit=ContinuousIntegration">EditText</a> of this page (last edited November 22, 2000)<br>
<a href="http://c2.com/cgi/wiki?FindPage&value=ContinuousIntegration">FindPage</a> by browsing or searching<p>
<font color=gray size=-1>This page mirrored in <a href="index.html">ExtremeProgrammingRoadmap</a> as of March 31, 2001</font>
</body>