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

Re: [scrumdevelopment] Re: Code branches

Expand Messages
  • Brad Appleton
    ... That is true if it is not done properly. The problem here isnt the branching, it is the failure to integrate frequently. ... Using task/feature branches
    Message 1 of 10 , Apr 30, 2007
    • 0 Attachment
      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
    • Guger, Larry
      Another excellent resource for branching guidance can be found here: http://www.codeplex.com/BranchingGuidance Despite being focused on the Team Foundation
      Message 2 of 10 , May 12 11:30 AM
      • 0 Attachment

        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

      • 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 3 of 10 , May 31 12:09 AM
        • 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 4 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.