tag:blogger.com,1999:blog-10280668.post115373504474412360..comments2023-09-22T06:05:17.495-05:00Comments on Brad Appleton's ACME Blog: Codeline Flow, Availability and ThroughputBrad Appletonhttp://www.blogger.com/profile/15136106921504315995noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-10280668.post-1163199986876196892006-11-10T17:06:00.000-06:002006-11-10T17:06:00.000-06:00Hi Slava! I think you may have misunderstood what ...Hi Slava! I think you may have misunderstood what I wrote above. I didn't suggest "blocking" the team until the build is fixed, I suggested that everyone who is "blocked" by the broken build should perhaps contribute to fixing the build.<BR/><BR/>I'm aware of several approaches that attempt to continue "submitting" changes even when the build is broken - these are different from the debates for synchronous -vs- asynchronous integration.Brad Appletonhttps://www.blogger.com/profile/15136106921504315995noreply@blogger.comtag:blogger.com,1999:blog-10280668.post-1163193587428232212006-11-10T15:19:00.000-06:002006-11-10T15:19:00.000-06:00Brad,I realize that I am responding to a post that...Brad,<BR/><BR/>I realize that I am responding to a post that is five months old, but later is better than never :)<BR/><BR/>I think the idea of blocking the team from submitting changes until the codeline is fixed or any kind of serialization based on some metrics doesn't scale well for bigger teams and/or heavily loaded code lines. This is mainly because those wanted to submit their changes would have to wait until others are done. The delay time grows proportionally the number of changes and generally is a function of size of the team.<BR/><BR/>Instead, our <A HREF="http://www.viewtier.com/products/parabuild/index.htm" REL="nofollow">Parabuild</A> follows what I see as an optimistic integration model or "faithful commit model" for the luck of a better term. A member of the team builds and runs tests clean locally, then syncs to the last state of code line known to be clean (Parabuild provides this information) and repeats clean build and test. After ensuring that everything builds and tests she submits her changes. Note that this approach is not concerned with the state of the code line head at all. <BR/><BR/>The key assumption here is that if the head of the code line is is broken someone is taking care of it. The integration build ensures that new changes integrate on a continuous basis. If by the next build cycle there is more than one change (including yours), they will be built as a group.<BR/><BR/>As you can see, this way no one is waiting and commits are made as soon as changes have been confirmed clean locally. This is a very efficient and I believe the fastest approach to managing the code base. <BR/><BR/>Regards,<BR/><BR/>Slava ImeshevAnonymousnoreply@blogger.com