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

Re: Code branches

Expand Messages
  • kswaters1
    Personally I think branching on every feature is a bit extreme and will be quite onerous in terms of frequent integration, which is the critical success factor
    Message 1 of 10 , May 31, 2007
    • 0 Attachment
      Personally I think branching on every feature is a bit extreme and
      will be quite onerous in terms of frequent integration, which is the
      critical success factor for such an approach to work.

      I've shared my thoughts further here:

      http://kw-agiledevelopment.blogspot.com/2007/05/agile-development-
      back-to-future.html

      Kelly Waters
      http://www.allaboutagile.com


      --- In scrumdevelopment@yahoogroups.com, "Guger, Larry" <lguger@...>
      wrote:
      >
      > Another excellent resource for branching guidance can be found
      here:
      >
      >
      >
      > http://www.codeplex.com/BranchingGuidance
      >
      >
      >
      > Despite being focused on the Team Foundation Server product the
      > information contained in the guidance is very applicable to any
      > platform.
      >
      >
      >
      > Larry
      >
      >
      >
      > From: scrumdevelopment@yahoogroups.com
      > [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Brad
      Appleton
      > Sent: Monday, April 30, 2007 11:03 PM
      > To: scrumdevelopment@yahoogroups.com
      > Subject: Re: [scrumdevelopment] Re: Code branches
      >
      >
      >
      > KasparLund wrote:
      > > Branches will most of the time reduce quality, velocity and
      > > transparency about progress.
      >
      > That is true if it is not done properly. The problem here isnt the
      > branching, it is the failure to integrate frequently.
      >
      > > Finally you cannot really consider a task done if its dangling
      on a
      > branch.
      >
      > Using task/feature branches doesnt imply that teh task/feature is
      > dangling to till the very end without any interim frequent
      integration
      >
      > > But I most cases it will be much more valuable to invest in a
      > > continuous integration strategy (very high ROI).
      >
      > Yes - you want a continuous integration strategy. And branching
      can be
      > an effective part of that (one doesnt preclude the other).
      >
      > Basically, in the case of a handful of feature teams, you
      ultimately
      > have to decide if each feature team's "frequent" integration will
      try
      > to:
      > a) integrate all "current" code for just that feature, or ...
      > b) integrate all "current" code for the entire product.
      >
      > (b) is a better synchronization strategy provided you
      dont "thrash" too
      > much trying to deal with the frequent integration from all the
      other
      > features. There is where Lean provides a lot of help when it tells
      us to
      >
      > use:
      > a) nested synchronization
      > b) harmonic cadences
      >
      > Nested synchronization could be done with feature branches. It
      could
      > also conceivably be done using feature "workspaces" where
      each "feature"
      >
      > gets its own sandbox (which may or may not have a corresponding
      branch).
      >
      > Harmonic cadences has to do with the "wavelength" (regular
      frequency) of
      >
      > integration for each feature.
      >
      > Some additional resources that might help w.r.t. branching are:
      > * Lean Principles for Branching
      > <<http://blog.bradapp.net/2006/01/lean-principles-for-
      branching.html>>
      >
      > * Nested Synchronization and Harmonic Cadences
      > <<
      > http://blog.bradapp.net/2006/06/nested-synchronization-and-
      harmonic.html
      > >>
      >
      > * Codeline Flow, Availability and Throughput
      > <<http://blog.bradapp.net/2006/07/codeline-flow-availability-
      and.html>>
      >
      > * Codeline Merging & Locking: Continuous Updates and Two-Phased
      Commits
      > <<http://www.cmcrossroads.com/content/view/6893/202/>>
      >
      > * Continuous Staging: Scaling Continuous Integration to Multiple
      > Component Teams (NOTE that a similar approach can be used for
      multiple
      > feature teams)
      > <<http://www.cmcrossroads.com/content/view/6869/202/>>
      >
      > and possibly some other articles at
      http://cmwiki.com/AgileSCMArticles
      > --
      > 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
      >
    • Brad Appleton
      ... It depends a lot on what feature means for your project/team, and how fine-grained or coarse-grained it is. If a feature is something that a single
      Message 2 of 10 , Jun 5, 2007
      • 0 Attachment
        kswaters1 wrote:
        > Personally I think branching on every feature is a bit extreme and
        > will be quite onerous in terms of frequent integration, which is the
        > critical success factor for such an approach to work.

        It depends a lot on what "feature" means for your project/team, and how
        fine-grained or coarse-grained it is.

        If a "feature" is something that a single person (or pair) does as part
        of a single "task", then its not all that different from having a
        separate sandbox (workspace) per task, which in Subversion is exactly
        equivalent as a branch.

        But if each 'feature' requires its own integration codeline within the
        same team, the overall system integration gets quite onerous and much
        harder to do as frequently.

        FDD can actually work with this approach EXCEPT that in FDD a 'feature'
        is something the whole team can deliver in ~2 weeks, so its still a
        single integration codeline per team in any given iteration. And there
        is still the issue of system-wide integration, which FDD addresses with
        chief-programmer work-packages per system-build.

        This is an mismatch between the logical unit of value-delivery -versus-
        the physical unit of build/integration. We develop and deliver working
        software one fine-grained increment at a time, but we want to integrate
        as frequently and as coarse-grained as possible. There is no easy or
        straightforward solution unless you manage to organize the code so that
        the 'functional' boundaries (features) match-up as closely as possible
        with the logical code boundaries (UML packages, classes and methods)
        which in turn match-up closely with the physical boundaries (built
        components, compilation units [e.g., Java packages])

        The Color Modeling technique of FDD actually does a consistently good
        job of accomplishing this to a large degree. Story-splitting and
        refactoring can do the same, if done well.

        > I've shared my thoughts further here:
        > <http://kw-agiledevelopment.blogspot.com/2007/05/agile-development-back-to-future.html>

        I actually saw that. It was about the same time I had a related
        blog-entry on "The 5 R's of Agile SCM Baselines".
        <<http://blog.bradapp.net/2007/05/five-rs-of-agile-scm-baselines.html>>

        I use the term "repairable" in a slightly more general sense than your
        "back to the future", where repairable can be either by reverting to the
        previous good state (rollback) *AND/OR* by quickly effecting the change
        to fix (rather than back-out) the offending code.

        Cheers!
        --
        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.