Loading ...
Sorry, an error occurred while loading the content.
 

Build Contention Equation

Expand Messages
  • Jay Flowers
    http://jayflowers.com/WordPress/?p=65 We are exploring new ways to build our software at work. I was trying to convey a thought on validating the feasibility
    Message 1 of 53 , Jul 11, 2006
      http://jayflowers.com/WordPress/?p=65

      We are exploring new ways to build our software at work. I was trying
      to convey a thought on validating the feasibility of a build process
      today with the following equation.

      Number of Change Packages = 8 Hours * 60 Minutes / (Build Time +
      Preparation Time + Buffer)

      Filling out the right side of the equation will show how many change
      packages can be process by the build on an average day. The Build
      Time is how long it take the build to complete. The Preparation Time
      is how long it takes a developer to get the build started. This could
      represent claiming the build token, submitting to source control and
      waiting for the build process to begin. In the proposed build process
      only one developer could submit at a time; the build is triggered by a
      submission to source control. The Buffer is the tricky variable. The
      buffer deals with contention or rather is a means to reduce
      contention. It is desirable for developers to be able to submit to
      the build when they complete a task. It is not desirable for them to
      have to wait to submit. The buffer is the amount of time that will
      create a situation where when a developer goes to claim the build
      token chances are it is available. Let me repeat that, chances are it
      is available. I do not know how much this variable should be. I just
      see that it is a fulcrum, a way to control, reduce the contention for
      the build. It will not eliminate it will just reduce the chances of
      it occurring. Lets say we make the Buffer 15 minutes. This will
      yield a build that can process on average 20 change packages in 8
      hours with a 65% chance that the build will be available when a
      developer goes to submit.

      20 Change Packages = 8 Hours * 60 Minutes/ (5 Minute Build Time + 3
      Minute Preparation Time + 15 Minute Buffer)

      65% Chance Availability = 15 Minute Buffer / (5 Minute Build Time + 3
      Minute Preparation Time + 15 Minute Buffer)

      So if you have 10 developers they can submit twice a day. Does this
      fit your needs? No? Well can you live with a lower chance of
      availability risking that developers will start working in larger
      change packages? If so then lets try reducing the buffer to provide a
      50% chance of availability . That will yield an average of 30 change
      packages in 8 hours for 2.5 submissions per developer for a 10
      developer team.

      So what is a team of 10 developers to do if there are no acceptable
      set of values to this equation? The only solution that I can fathom
      out is to split the build into multiple builds (e.g. a build for the
      client and a build for the server). Dividing the build should occur
      along two axis, package dependencies and number of contributing
      developers. For example there is not much benefit to splitting the
      the server off into its own build if only 10% of the team works on it.


      --
      Jay Flowers
      ----------------------------------------------------------------------
      http://jayflowers.com
      ---------------------------------------------------------------------
    • Brad Appleton
      If commits are done serially/synchronously, then commit-time corresponds to a time during which others are dis-allowed to commit their changes. If
      Message 53 of 53 , Nov 20, 2006
        If commits are done serially/synchronously, then "commit-time"
        corresponds to a time during which others are dis-allowed to commit
        their changes. If concurrent/asynchronous commits are allowed, it
        corresponds to a window of opportunity during which inconsistent and/or
        non-atomic changes might be made.

        So if I know the average commit-time, and the average quiet-time, and
        the average commit-frequency, that can help me determine how much I am
        at risk of either (a) creating waits (and for how long) due to
        commit-contention, or (b) the likelihood of inconsistency rearing its
        ugly head. For the latter, it helps to also have an idea of how often
        (and how many files) concurrent/parallel changes need to be resolved.

        Jay Flowers wrote:
        >
        >
        > Hmm,
        > I try an translate to the way we operate. We use VSS,<gag> so there is no
        > merging. We have an integration token. Sounds like the commit
        > time/duration begins when the token is claimed and ends when the build
        > completes successfully? If this is a good translation what does it tell
        > me? I would guess it speaks to build quite times. Similar to build times.
        > As in build time is to the guy that committed as commit time is to the guy
        > waiting to commit? So just like you want your build times to be 5- minutes
        > to encourage small change packages you want small commit times for the same
        > reason?
        >
        > On 11/19/06, Brad Appleton <Brad.Appleton@...
        > <mailto:Brad.Appleton%40gmail.com>> wrote:
        > >
        > > Regarding avg # lines added/changed/removed per file ... I've found that
        > > to be less useful because it can vary so widely based on file-type
        > > (e.g., source file, headers/interface files, Makefiles, scripts,
        > > READMEs) and file-size and "well-factored-ness"
        > >
        > > Another measurement I often see is the commit time/duration: the time it
        > > takes from when I first commence committing my changes until they have
        > > successfully been merged to and checked-in to the codeline.
        > >
        > > For those that use "integration tokens", this would equate to the
        > > average time that one holds the integration token. In Lean terminology,
        > > I believe this would be the "batch transfer time"
        > >
        > > The tricky part is whether you define "commit time" to include the time
        > > it takes to build+test, or if its only the time it takes to merge and
        > > checkin. (when using something akin to a "two-phased commit" strategy it
        > > may make sense to record the time for each "phase" of the commit)
        > >
        > > In some ways, commit-duration is the "inverse" of what you (Jay) called
        > > "quiet time" in a previous posting, it's the "noisy time" during a
        > > commit when the codeline is "in use" for a "change transaction"
        > > --
        > > Brad Appleton <brad {AT} bradapp.net>
        > > Agile CM Environments (http://blog.bradapp.net/
        > <http://blog.bradapp.net/>)
        > > & Software CM Patterns (www.scmpatterns.com)
        > > "And miles to go before I sleep" -- Robert Frost
        > >
        > >
        > > To Post a message, send it to: extremeprogramming@...
        > <mailto:extremeprogramming%40eGroups.com>
        > >
        > > To Unsubscribe, send a blank message to:
        > > extremeprogramming-unsubscribe@...
        > <mailto:extremeprogramming-unsubscribe%40eGroups.com>
        > >
        > > ad-free courtesy of objectmentor.com
        > > Yahoo! Groups Links
        > >
        > >
        > >
        > >
        > >
        >
        > --
        > Jay Flowers
        > ----------------------------------------------------------
        > http://jayflowers.com <http://jayflowers.com>
        > ----------------------------------------------------------
        >
        > [Non-text portions of this message have been removed]
        >
        >

        --
        Brad Appleton <brad {AT} bradapp.net>
        Agile CM Environments (http://blog.bradapp.net/)
        & Software CM Patterns (www.scmpatterns.com)
        "And miles to go before I sleep" -- Robert Frost
      Your message has been successfully submitted and would be delivered to recipients shortly.