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

Re: [XP] What do you think about parallel releases in a single project?

Expand Messages
  • Steven Campbell
    There are two sides to the problem - one is architectural, and one is process oriented. Your blog post speaks more to the process. When we have encountered
    Message 1 of 25 , Apr 16 6:33 AM
    View Source
    • 0 Attachment
      There are two sides to the problem - one is architectural, and one is
      process oriented. Your blog post speaks more to the process. When we
      have encountered this, we have simply included the work in our sprint
      backlogs, in a way that is planned to achieve the necessary release
      schedule. Fixes are more difficult - we tried various things, but for
      us it turned out to be best to have the fixes as another part of the
      sprint backlog. I think each team has to find its own way though.

      It was difficult to achieve all required deadlines in this scenario.
      The reason is that there was simply too much work for a small team -
      we were over-committed.

      For the rest, I'll speak to the architectural side:

      Unless v3 is a rewrite, it is probably defined as a new component, or
      a major improvement of an existing component. In any case, it is ok
      to branch *just* that component, and keep more common code...in
      common. Automated builds can take care of bringing the right code
      together for the right versions.

      If possible, *don't branch at all* and develop v2 and v3 on the same
      code-branch (you can still branch v1 of course). This can be achieved
      with a simple "switch", that is turned on for v3 and off for v2. It
      can be a compiler switch, but I prefer something external to the code,
      such as a setting in a db table. In my own environment, we call these
      switches "feature keys", because they turn on features.

      Some large distributed deployments (ebay) make use of this idea to
      simplify the deployment process - deploy in v2 mode, then throw the v3
      switch when you're ready to activate the features. If things aren't
      working out, reset the switch to v2 and try again next week.


      ~Steve

      On Wed, Apr 16, 2008 at 2:51 AM, Michael Dubakov <firefalcon@...> wrote:
      >
      >
      >
      >
      >
      >
      > I think this question is not highlighted in books, articles and blogs. I did
      > not find any
      > comprehensive article. However the problem is pretty common. Team
      > developing main
      > release line (v.2), support release (v.1.x) line and future release line
      > (v.3) in parallel. What do
      > you think about that? How that should be handled in a single team?
      >
      > Starting point may be this post
      >
      >
      > http://www.targetprocess.com/blog/2008/04/should-we-have-parallel-releases-and.html
      >
      >



      --
      Steve Campbell
      http://blog.perfectapi.com/
    • Matt
      ... I did not find any ... developing main ... line (v.3) in parallel. What do ... http://www.targetprocess.com/blog/2008/04/should-we-have-parallel-releas
      Message 2 of 25 , Apr 16 7:36 AM
      View Source
      • 0 Attachment
        --- In extremeprogramming@yahoogroups.com, "Michael Dubakov"
        <firefalcon@...> wrote:
        >
        > I think this question is not highlighted in books, articles and blogs.
        I did not find any
        > comprehensive article. However the problem is pretty common. Team
        developing main
        > release line (v.2), support release (v.1.x) line and future release
        line (v.3) in parallel. What do
        > you think about that? How that should be handled in a single team?
        >
        > Starting point may be this post
        >
        >
        http://www.targetprocess.com/blog/2008/04/should-we-have-parallel-releas\
        es-and.html
        >


        Are you dealing with "shrink wrapped" software such that "releasing" is
        more painful than simply uploading the latest release to your server?
        If so I can see the value of having distinct releases but otherwise I am
        not seeing the logic of maintaining multiple releases simultaneously.
        Curious about the situation you are dealing with.

        Matt
      • IrishTek
        I have worked with a similar environment. For the sake of discussion, let s say we had a contract with one organization that ran three versions of our software
        Message 3 of 25 , Apr 16 5:28 PM
        View Source
        • 0 Attachment
          I have worked with a similar environment.

          For the sake of discussion, let's say we had a contract with one organization that ran three versions of our software and wanted us to maintain those versions separately.

          We used Microsoft Visual Source Safe to hold all three branches. A developer could delete his local installation and then pull from VSS any one of the branches, then run a batch file to have the databases configured and create and deploy services, cook wars, etc....

          Maintenance was fairly simple for the three branches. If the earliest branch discovered a 'bug', then all three would be tested for the same bug and fixed if it still existed.

          If a bug was reported in a later version, the issue was never addressed with previous versions.

          I do not think the process was too complicated. It would take the developer about an hour to switch branches. As a developer, that meant I nice coffee break :)


          Matt <maswaffer@...> wrote:


          --- In extremeprogramming@yahoogroups.com, "Michael Dubakov"
          <firefalcon@...> wrote:
          >
          > I think this question is not highlighted in books, articles and blogs.
          I did not find any
          > comprehensive article. However the problem is pretty common. Team
          developing main
          > release line (v.2), support release (v.1.x) line and future release
          line (v.3) in parallel. What do
          > you think about that? How that should be handled in a single team?
          >
          > Starting point may be this post
          >
          >
          http://www.targetprocess.com/blog/2008/04/should-we-have-parallel-releas\
          es-and.html
          >

          Are you dealing with "shrink wrapped" software such that "releasing" is
          more painful than simply uploading the latest release to your server?
          If so I can see the value of having distinct releases but otherwise I am
          not seeing the logic of maintaining multiple releases simultaneously.
          Curious about the situation you are dealing with.

          Matt






          ---------------------------------
          Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.

          [Non-text portions of this message have been removed]
        • Michael Dubakov
          The situation is absolutely typical for product development. If you have a product, you have to release patches and developing new version. Release itself has
          Message 4 of 25 , Apr 17 3:27 AM
          View Source
          • 0 Attachment
            The situation is absolutely typical for product development.
            If you have a product, you have to release patches and developing new
            version.

            Release itself has some related activities like web site updates, PR
            buzz and so on. So for example weekly releases will not work.

            BTW, in our company we do not have parallel releases (I mean in plan,
            with dedicated developers, etc).

            Michael Dubakov
            http://www.targetprocess.com

            > Are you dealing with "shrink wrapped" software such that "releasing" is
            > more painful than simply uploading the latest release to your server?
            > If so I can see the value of having distinct releases but otherwise I am
            > not seeing the logic of maintaining multiple releases simultaneously.
            > Curious about the situation you are dealing with.
            >
            > Matt
            >
          • Michael Dubakov
            Folks, I think we are missing the point. The articles is not about versions/branches. There is nothing complex with branches and multiple versions support at
            Message 5 of 25 , Apr 17 3:30 AM
            View Source
            • 0 Attachment
              Folks, I think we are missing the point.
              The articles is not about versions/branches.
              There is nothing complex with branches and multiple versions support
              at all.

              The problems are in development process and planning. Should we have
              parallel releases with dedicated teams? Should we plan and track
              patches separately? Or should we handle all that in one release?

              Michael Dubakov
              http://www.targetprocess.com

              --- In extremeprogramming@yahoogroups.com, IrishTek <irishtek@...> wrote:
              >
              > I have worked with a similar environment.
              >
              > For the sake of discussion, let's say we had a contract with one
              organization that ran three versions of our software and wanted us to
              maintain those versions separately.
              >
              > We used Microsoft Visual Source Safe to hold all three branches.
              A developer could delete his local installation and then pull from VSS
              any one of the branches, then run a batch file to have the databases
              configured and create and deploy services, cook wars, etc....
              >
              > Maintenance was fairly simple for the three branches. If the
              earliest branch discovered a 'bug', then all three would be tested for
              the same bug and fixed if it still existed.
              >
              > If a bug was reported in a later version, the issue was never
              addressed with previous versions.
              >
              > I do not think the process was too complicated. It would take the
              developer about an hour to switch branches. As a developer, that
              meant I nice coffee break :)
              >
              >
              > Matt <maswaffer@...> wrote:
              >
              >
              > --- In extremeprogramming@yahoogroups.com, "Michael Dubakov"
              > <firefalcon@> wrote:
              > >
              > > I think this question is not highlighted in books, articles and blogs.
              > I did not find any
              > > comprehensive article. However the problem is pretty common. Team
              > developing main
              > > release line (v.2), support release (v.1.x) line and future release
              > line (v.3) in parallel. What do
              > > you think about that? How that should be handled in a single team?
              > >
              > > Starting point may be this post
              > >
              > >
              >
              http://www.targetprocess.com/blog/2008/04/should-we-have-parallel-releas\
              > es-and.html
              > >
              >
              > Are you dealing with "shrink wrapped" software such that "releasing" is
              > more painful than simply uploading the latest release to your server?
              > If so I can see the value of having distinct releases but otherwise I am
              > not seeing the logic of maintaining multiple releases simultaneously.
              > Curious about the situation you are dealing with.
              >
              > Matt
              >
              >
              >
              >
              >
              >
              > ---------------------------------
              > Be a better friend, newshound, and know-it-all with Yahoo! Mobile.
              Try it now.
              >
              > [Non-text portions of this message have been removed]
              >
            • Michael Dubakov
              ... Exactly. There are many articles about technical side of the problem and solution looks quite trivial. However there is almost no info about process part.
              Message 6 of 25 , Apr 17 3:37 AM
              View Source
              • 0 Attachment
                > There are two sides to the problem - one is architectural, and one is
                > process oriented. Your blog post speaks more to the process.

                Exactly. There are many articles about technical side of the problem
                and solution looks quite trivial. However there is almost no info
                about process part.

                >When we have encountered this, we have simply included the work in
                our sprint
                > backlogs, in a way that is planned to achieve the necessary release
                > schedule.

                We do exactly the same. We do not have several parallel sprints.

                >Fixes are more difficult - we tried various things, but for
                > us it turned out to be best to have the fixes as another part of the
                > sprint backlog. I think each team has to find its own way though.

                How do you track progress? Do you have two burn downs for the spring?
                (one for main development and second for fixes)?


                Michael Dubakov
                http://www.targetprocess.com
              • Bill Michell
                ... Dubakov ... single ... Bug fixes in one branch will likely need to be merged somehow into other branches. Who better to do that than the developer of the
                Message 7 of 25 , Apr 17 3:39 AM
                View Source
                • 0 Attachment
                  > -----Original Message-----
                  > From: extremeprogramming@yahoogroups.com
                  > [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Michael
                  Dubakov
                  > Sent: 17 April 2008 11:31
                  > To: extremeprogramming@yahoogroups.com
                  > Subject: [XP] Re: What do you think about parallel releases in a
                  single
                  > project?
                  >
                  > Folks, I think we are missing the point.
                  > The articles is not about versions/branches.
                  > There is nothing complex with branches and multiple versions support
                  > at all.
                  >
                  > The problems are in development process and planning. Should we have
                  > parallel releases with dedicated teams? Should we plan and track
                  > patches separately? Or should we handle all that in one release?
                  >

                  Bug fixes in one branch will likely need to be merged somehow into other
                  branches. Who better to do that than the developer of the fix. Better
                  still if they are familiar with whatever code differences there are in
                  the destination branch, and can coordinate fully with the destination
                  branch.

                  With developers spending time in multiple versions, we find planning and
                  tracking together helpful. I guess if you needed to split the teams for
                  some other reason (number of developers, for example), this might be a
                  candidate for separation of responsibilities - but if you don't need to
                  split the team, then keep them working and planning together.
                  --
                  Bill Michell
                  Development Team Leader, Broadcast Platforms, BBC FM&T (Journalism).


                  http://www.bbc.co.uk/
                  This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
                  If you have received it in error, please delete it from your system.
                  Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
                  Please note that the BBC monitors e-mails sent or received.
                  Further communication will signify your consent to this.
                • Brad Appleton
                  ... What is typical here is to see a category of (re)work called something like fixes or patches (or some other form of waste :-) All the time & effort
                  Message 8 of 25 , Apr 17 6:52 AM
                  View Source
                  • 0 Attachment
                    Michael Dubakov wrote:
                    > The problems are in development process and planning. Should we have
                    > parallel releases with dedicated teams? Should we plan and track
                    > patches separately? Or should we handle all that in one release?

                    What is typical here is to see a "category" of (re)work called something
                    like "fixes" or "patches" (or some other form of "waste" :-)

                    All the time & effort that is spent to separately release+deploy such
                    patches get "charged" against this category. If you use story-cards for
                    them, you could "track" them that way, including additional "patch
                    stories" as needed for the additional release-engineering needed for the
                    patches as well as any additional merging effort as a result of having
                    to make sure the patches find their way to the mainline.

                    That lets you PLAN the work together as a concerted effort, but still
                    track the patch-work separately so you can see the additional (re)work
                    it created.

                    The rest depends on your specific "reporting" requirements mandated by
                    your customer or your customers/stakeholders. Some might ask that you
                    track the "patches" as subprojects of an overal project/program.

                    How you actually organize yourselves to DO the work really is up to you
                    and shouldnt be dictated by the tracking+reporting requirements.
                    Depending on the nature of the "patches" to be made, some might employ a
                    pattern entitled "Sacrifice One Person" to handle all the patchwork (the
                    pattern doesnt consider that one might be dong PairProgramming, in which
                    case it might be Sacrifice one "Pair", or one person but with rotating
                    partners).

                    So whether or not it should be planned and executed as one team or two
                    separate teams should (IMHO) be upto your team to self-organize as they
                    see fit. The trick is doing the tracking & planning so that your
                    "interface" (how you report the work/results) can stay separate from
                    your "implementation" (how you self-organize to execute the work).

                    And that is typically done by making sure those "stories" or tasks (or
                    however you are tracking them) have at least one additional piece of
                    information that lets you separate and categorize the patch-work from
                    the main work.
                    --
                    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
                  • Matt
                    Michael, It may be typical but that doesn t mean it is optimal. It may well be for your situation, I don t have a clue. For us though, we released a new
                    Message 9 of 25 , Apr 17 7:21 AM
                    View Source
                    • 0 Attachment
                      Michael,

                      It may be typical but that doesn't mean it is optimal. It may well be
                      for your situation, I don't have a clue. For us though, we released a
                      new product on Nov 20 of last year and have released 8 times since then
                      and have another release coming out this week. For us it doesn't make
                      sense to ship a patch... we just tell them to download the latest build.

                      In the event we ship a critical bug and absolutely *must* ship out a bug
                      fix immediately, we tag at every release and we can go back and fix the
                      bug on the tag and reship that version if necessary.

                      Ultimately our goal (admittedly not quite realistic yet) is weekly
                      releases. 8 releases in 5 months is good but not quite as good as we
                      want. At CITCON (Continuous Integration and Testing Conference) in
                      Denver a few weeks ago, we had a session on whether or not a daily
                      release was a good idea. Andrew Binstock pointed out some of the
                      concerns you have as well as the "over the wall" user testing that is
                      required by some laws that might make it impractical or even impossible.
                      Paul Duval pointed out that with continuous integration it might not be
                      a bad goal to be *able* to ship every day, even if you don't. In any
                      case, daily is probably a bit extreme... or maybe not.

                      Incidentally our frequent releases are on a brand new product, we also
                      have a more mature product that is not as actively developed with new
                      features but which we try to keep in a similar state so that it is
                      shippable as soon as new features are added. Occassionally we have had
                      to go back on a tag / branch and do a bug fix but we try to avoid that.
                      Our goal is to keep the trunk in good enough shape to ship at the drop
                      of a hat... and we provide the hat.

                      Matt


                      --- In extremeprogramming@yahoogroups.com, "Michael Dubakov"
                      <firefalcon@...> wrote:
                      >
                      > The situation is absolutely typical for product development.
                      > If you have a product, you have to release patches and developing new
                      > version.
                      >
                      > Release itself has some related activities like web site updates, PR
                      > buzz and so on. So for example weekly releases will not work.
                      >
                      > BTW, in our company we do not have parallel releases (I mean in plan,
                      > with dedicated developers, etc).
                      >
                      > Michael Dubakov
                      > http://www.targetprocess.com
                      >
                      > > Are you dealing with "shrink wrapped" software such that "releasing"
                      is
                      > > more painful than simply uploading the latest release to your
                      server?
                      > > If so I can see the value of having distinct releases but otherwise
                      I am
                      > > not seeing the logic of maintaining multiple releases
                      simultaneously.
                      > > Curious about the situation you are dealing with.
                      > >
                      > > Matt
                      > >
                      >
                    • Carfield Yim
                      Just wonder are you working of single branch and single set of requirement or does you able to achieve for a project that need to support multiple branch with
                      Message 10 of 25 , Apr 17 8:02 AM
                      View Source
                      • 0 Attachment
                        Just wonder are you working of single branch and single set of
                        requirement or does you able to achieve for a project that need to
                        support multiple branch with multiple overlapping requirements like
                        multiple software support difference markets?

                        On Thu, Apr 17, 2008 at 10:21 PM, Matt <maswaffer@...> wrote:
                        >
                        >
                        >
                        >
                        >
                        >
                        >
                        > Michael,
                        >
                        > It may be typical but that doesn't mean it is optimal. It may well be
                        > for your situation, I don't have a clue. For us though, we released a
                        > new product on Nov 20 of last year and have released 8 times since then
                        > and have another release coming out this week. For us it doesn't make
                        > sense to ship a patch... we just tell them to download the latest build.
                        >
                        > In the event we ship a critical bug and absolutely *must* ship out a bug
                        > fix immediately, we tag at every release and we can go back and fix the
                        > bug on the tag and reship that version if necessary.
                        >
                        > Ultimately our goal (admittedly not quite realistic yet) is weekly
                        > releases. 8 releases in 5 months is good but not quite as good as we
                        > want. At CITCON (Continuous Integration and Testing Conference) in
                        > Denver a few weeks ago, we had a session on whether or not a daily
                        > release was a good idea. Andrew Binstock pointed out some of the
                        > concerns you have as well as the "over the wall" user testing that is
                        > required by some laws that might make it impractical or even impossible.
                        > Paul Duval pointed out that with continuous integration it might not be
                        > a bad goal to be *able* to ship every day, even if you don't. In any
                        > case, daily is probably a bit extreme... or maybe not.
                        >
                        > Incidentally our frequent releases are on a brand new product, we also
                        > have a more mature product that is not as actively developed with new
                        > features but which we try to keep in a similar state so that it is
                        > shippable as soon as new features are added. Occassionally we have had
                        > to go back on a tag / branch and do a bug fix but we try to avoid that.
                        > Our goal is to keep the trunk in good enough shape to ship at the drop
                        > of a hat... and we provide the hat.
                        >
                        > Matt
                      • Michael Dubakov
                        I completely agree. The goal to be able to to ship every day is definitely great. But to be on such high-league-level you should have very good development
                        Message 11 of 25 , Apr 17 8:11 AM
                        View Source
                        • 0 Attachment
                          I completely agree. The goal to be able to to ship every day is
                          definitely great. But to be on such high-league-level you should have
                          very good development process. Many teams are just not there yet. It
                          is not a 1 day change to make it happen. It is hard process that may
                          take year(s?). But again, the goal is correct/

                          Our current goal is 4 weeks releases (we have 6-8 weeks releases
                          currently). Our competitors for example having 12 weeks releases
                          scheduler.

                          Michael Dubakov
                          http://www.targetprocess.com

                          >
                          > Michael,
                          >
                          > It may be typical but that doesn't mean it is optimal. It may well be
                          > for your situation, I don't have a clue. For us though, we released a
                          > new product on Nov 20 of last year and have released 8 times since then
                          > and have another release coming out this week. For us it doesn't make
                          > sense to ship a patch... we just tell them to download the latest build.
                          >
                          > In the event we ship a critical bug and absolutely *must* ship out a bug
                          > fix immediately, we tag at every release and we can go back and fix the
                          > bug on the tag and reship that version if necessary.
                          >
                          > Ultimately our goal (admittedly not quite realistic yet) is weekly
                          > releases. 8 releases in 5 months is good but not quite as good as we
                          > want. At CITCON (Continuous Integration and Testing Conference) in
                          > Denver a few weeks ago, we had a session on whether or not a daily
                          > release was a good idea. Andrew Binstock pointed out some of the
                          > concerns you have as well as the "over the wall" user testing that is
                          > required by some laws that might make it impractical or even impossible.
                          > Paul Duval pointed out that with continuous integration it might not be
                          > a bad goal to be *able* to ship every day, even if you don't. In any
                          > case, daily is probably a bit extreme... or maybe not.
                          >
                          > Incidentally our frequent releases are on a brand new product, we also
                          > have a more mature product that is not as actively developed with new
                          > features but which we try to keep in a similar state so that it is
                          > shippable as soon as new features are added. Occassionally we have had
                          > to go back on a tag / branch and do a bug fix but we try to avoid that.
                          > Our goal is to keep the trunk in good enough shape to ship at the drop
                          > of a hat... and we provide the hat.
                          >
                          > Matt
                          >
                          >
                          > --- In extremeprogramming@yahoogroups.com, "Michael Dubakov"
                          > <firefalcon@> wrote:
                          > >
                          > > The situation is absolutely typical for product development.
                          > > If you have a product, you have to release patches and developing new
                          > > version.
                          > >
                          > > Release itself has some related activities like web site updates, PR
                          > > buzz and so on. So for example weekly releases will not work.
                          > >
                          > > BTW, in our company we do not have parallel releases (I mean in plan,
                          > > with dedicated developers, etc).
                          > >
                          > > Michael Dubakov
                          > > http://www.targetprocess.com
                          > >
                          > > > Are you dealing with "shrink wrapped" software such that "releasing"
                          > is
                          > > > more painful than simply uploading the latest release to your
                          > server?
                          > > > If so I can see the value of having distinct releases but otherwise
                          > I am
                          > > > not seeing the logic of maintaining multiple releases
                          > simultaneously.
                          > > > Curious about the situation you are dealing with.
                          > > >
                          > > > Matt
                          > > >
                          > >
                          >
                        • Steven Campbell
                          ... There is only a single burn-down. We assign point values to fixes and include the points in the sprint. Some sprints have fixes, and others do not. In
                          Message 12 of 25 , Apr 17 9:25 AM
                          View Source
                          • 0 Attachment
                            On Thu, Apr 17, 2008 at 5:37 AM, Michael Dubakov <firefalcon@...> wrote:
                            >
                            > How do you track progress? Do you have two burn downs for the spring?
                            > (one for main development and second for fixes)?
                            >

                            There is only a single burn-down. We assign point values to fixes and
                            include the points in the sprint. Some sprints have fixes, and others
                            do not.

                            In our environment, there are two types of "fixes". One is a pure
                            "bug" fix. The other is that the system is not working exactly as the
                            users want it (it is more like a tweak, or an extension). We
                            typically assign the same point value to all "bug" fixes - experience
                            says that an average fix takes 1/2 a point (in our point system). The
                            other kind is estimated normally, and we do not really think of it as
                            a fix (but it's not treated as a new requirement either).

                            Anyway. using this technique, it is obvious to the product owner where
                            improved quality and requirements gathering could result in higher
                            productivity. It is also easy to manage within the sprint -
                            developers self-select which fixes they work on. Sometimes, this
                            results in a single "fix" developer for the sprint, but it varies.

                            We have 2 week sprints, so the product owner can almost always wait 2
                            weeks for a fix. Hotfixes are defined as a fix that cannot wait for
                            the next sprint. They are handled differently, but are uncommon.

                            In terms of metrics, a "bug" fix means that quality was at fault. An
                            "tweak" fix means that we need to work more closely to understand the
                            requirements while developing (although it could also mean that the
                            requirement *needed* multiple iterations to come to maturity). That
                            is a difficult concept for many people to grasp, but it is important
                            for understanding velocity. I have a blog post explaining the final
                            evolution of this technique, at
                            http://blog.perfectapi.com/2008/01/my-kanban-technique.html.
                            Unfortunately, our product was consolidated with another (causing the
                            team to break up) so I never had the opportunity to explore that idea
                            fully.

                            --
                            Steve Campbell
                            http://blog.perfectapi.com/
                          • Matt
                            ... We have a single branch ... all work is done on the trunk. We practice continuous integration so it is always up to date with the current work. We have a
                            Message 13 of 25 , Apr 17 12:11 PM
                            View Source
                            • 0 Attachment
                              --- In extremeprogramming@yahoogroups.com, "Carfield Yim" <carfield@...>
                              wrote:
                              >
                              > Just wonder are you working of single branch and single set of
                              > requirement or does you able to achieve for a project that need to
                              > support multiple branch with multiple overlapping requirements like
                              > multiple software support difference markets?
                              >
                              > On Thu, Apr 17, 2008 at 10:21 PM, Matt maswaffer@... wrote:
                              > >


                              We have a single "branch"... all work is done on the trunk. We practice
                              continuous integration so it is always up to date with the current work.
                              We have a single back-log that we work from in a kanban style.

                              I am not sure what you mean by "multiple software support difference
                              markets" but my guess is that no, we are not engaged in that kind of a
                              project.

                              Matt
                            • Phlip
                              ... When I was doing that, the cost of supporting multiple code versions was crushing. If the goal was to somehow insulate each flavor s bugs from the others,
                              Message 14 of 25 , Apr 17 3:00 PM
                              View Source
                              • 0 Attachment
                                Matt wrote:

                                > I am not sure what you mean by "multiple software support difference
                                > markets" but my guess is that no, we are not engaged in that kind of a
                                > project.

                                When I was doing that, the cost of supporting multiple code versions was
                                crushing. If the goal was to somehow insulate each flavor's bugs from the
                                others, the effect was instead to drag all their quality down to a lowest
                                common denominator.

                                Running the tests for every flavor, each time you change any flavor, is much
                                much simpler. It avoids the "sunken cost fallacy".

                                --
                                Phlip
                              • Carfield Yim
                                ... For example for a stock trading system to support difference exchange, like HK, TW, KR, difference software need to support difference features, which are
                                Message 15 of 25 , Apr 17 5:36 PM
                                View Source
                                • 0 Attachment
                                  > I am not sure what you mean by "multiple software support difference
                                  > markets" but my guess is that no, we are not engaged in that kind of a
                                  > project.
                                  >

                                  For example for a stock trading system to support difference exchange,
                                  like HK, TW, KR, difference software need to support difference
                                  features, which are similar but not same.

                                  In theory we can still do what you've mentioned but it is difficult
                                  because developers for difference region don't know the requirement of
                                  other exchange. I just wonder if anyone have experience of maintain
                                  software like this in single trunk, we were try to do that before but
                                  the result is not good.
                                • Kent Beck
                                  Carfield, I have experience with a product that has seven customers, each of which has quite a bit of custom logic in addition to the common code. We have a
                                  Message 16 of 25 , Apr 17 9:10 PM
                                  View Source
                                  • 0 Attachment
                                    Carfield,

                                    I have experience with a product that has seven customers, each of which has
                                    quite a bit of custom logic in addition to the common code. We have a single
                                    binary that is run for all the customers. All the customer-specific
                                    decisions are defered until run-time. The challenge is making sure that no
                                    customer-specific code is executed for a different customer, but our design
                                    (as it has evolved) makes this unlikely.

                                    I contrast this with a similar scale project I worked on briefly that had
                                    seven different code bases for seven customers. Each time a new customer was
                                    signed, the "freshest" code base was cloned and thereafter all changes had
                                    to be merged, potentially, six times. The company was sinking under the
                                    weight of merging.

                                    The key difference between the two is finding ways to defer binding. What I
                                    found was that this began by choosing a principle--we are going to have a
                                    single code base. This eliminated some design options, but plenty still
                                    remained. Another important principle is that in the first case we don't
                                    mind having some duplicate code. If it's clear how to eliminate duplication,
                                    we do, but we are willing to wait for clarity.

                                    Does this seem to apply to your situation? Are there ways you could defer
                                    binding and reduce the build-time complexity?

                                    Regards,

                                    Kent Beck
                                    Three Rivers Institute

                                    _____

                                    From: extremeprogramming@yahoogroups.com
                                    [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Carfield Yim
                                    Sent: Thursday, April 17, 2008 5:36 PM
                                    To: extremeprogramming@yahoogroups.com
                                    Subject: Re: [XP] Re: What do you think about parallel releases in a single
                                    project?



                                    > I am not sure what you mean by "multiple software support difference
                                    > markets" but my guess is that no, we are not engaged in that kind of a
                                    > project.
                                    >

                                    For example for a stock trading system to support difference exchange,
                                    like HK, TW, KR, difference software need to support difference
                                    features, which are similar but not same.

                                    In theory we can still do what you've mentioned but it is difficult
                                    because developers for difference region don't know the requirement of
                                    other exchange. I just wonder if anyone have experience of maintain
                                    software like this in single trunk, we were try to do that before but
                                    the result is not good.





                                    [Non-text portions of this message have been removed]
                                  • Tim Ottinger
                                    ... I think it is highlighted. The Berczuk/Appleton book talks about release branches and code line policies and a lot of the stuff you need, no? My personal
                                    Message 17 of 25 , Apr 17 9:52 PM
                                    View Source
                                    • 0 Attachment
                                      ----- Original Message ----
                                      > I think this question is not highlighted in books, articles and blogs. I did not
                                      > find any
                                      > comprehensive article. However the problem is pretty common. Team developing
                                      > main
                                      > release line (v.2), support release (v.1.x) line and future release line (v.3)
                                      > in parallel. What do
                                      > you think about that? How that should be handled in a single team?

                                      I think it is highlighted. The Berczuk/Appleton book talks about release
                                      branches and code line policies and a lot of the stuff you need, no?

                                      My personal opinion: Less is more. Fewer is better. TSTTMPW.

                                      I understand the need for an emergency release line especially if you're
                                      new to agile and haven't reached the point where every build is releasable,
                                      as my current client has not. But ultimately we should have fewer, and the
                                      number should approach 1.

                                      But the book has the patterns and strategies you could use to get started.
                                      And now you have the opinion you asked for.

                                      tim






                                      ____________________________________________________________________________________
                                      Be a better friend, newshound, and
                                      know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
                                    • Tim Ottinger
                                      ... Shorten your cycles, then. You have too long a reach here, IMHO. Doing less, more completely, more often is the way, no? Are you doing internal releases
                                      Message 18 of 25 , Apr 17 9:55 PM
                                      View Source
                                      • 0 Attachment
                                        > Our current goal is 4 weeks releases (we have 6-8 weeks releases
                                        > currently). Our competitors for example having 12 weeks releases
                                        > scheduler.


                                        Shorten your cycles, then. You have too long a reach here, IMHO.
                                        Doing less, more completely, more often is the way, no? Are you
                                        doing internal releases daily or at least weekly? Are you having
                                        many iterations per release?

                                        I would like to see a single team working, even if they have to
                                        jump streams. I really worry about having an "a" team and a "b"
                                        team. I think that B teams tend to leak membership in ugly ways.








                                        ____________________________________________________________________________________
                                        Be a better friend, newshound, and
                                        know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
                                      • John A. De Goes
                                        I m not surprised you don t find much in the agile literature on this topic. Branches are a form of waste and the goal is to eliminate them, to move to a
                                        Message 19 of 25 , Apr 18 10:29 AM
                                        View Source
                                        • 0 Attachment
                                          I'm not surprised you don't find much in the agile literature on this
                                          topic.

                                          Branches are a form of waste and the goal is to eliminate them, to
                                          move to a single code stream, whose most recently released version is
                                          the only supported version, which is forcibly pushed to all
                                          installations on every release, with releases happening as frequently
                                          as possible (ideally, one release per feature/defect).

                                          All of which is made a lot simpler with SaaS.

                                          Regards,

                                          John A. De Goes
                                          N-BRAIN, Inc.
                                          http://www.n-brain.net
                                          [n minds are better than n-1]

                                          On Apr 16, 2008, at 1:51 AM, Michael Dubakov wrote:

                                          > I think this question is not highlighted in books, articles and
                                          > blogs. I did not find any
                                          > comprehensive article. However the problem is pretty common. Team
                                          > developing main
                                          > release line (v.2), support release (v.1.x) line and future release
                                          > line (v.3) in parallel. What do
                                          > you think about that? How that should be handled in a single team?
                                          >
                                          > Starting point may be this post
                                          >
                                          > http://www.targetprocess.com/blog/2008/04/should-we-have-parallel-releases-and.html
                                          >
                                          >
                                          >



                                          [Non-text portions of this message have been removed]
                                        • Carfield Yim
                                          Thanks a lot for reply, We ve tried to have single binary, but fail at the moment. And now it is sinking under the weight of merging. :-/ So I really like to
                                          Message 20 of 25 , Apr 18 11:17 AM
                                          View Source
                                          • 0 Attachment
                                            Thanks a lot for reply, We've tried to have single binary, but fail at
                                            the moment. And now it is sinking under the weight of merging. :-/ So
                                            I really like to ask how can we about to work in single binary
                                            successful.

                                            I think the major issue we have is there are too many requirements,
                                            and our development team are separate into difference city, it is not
                                            likely that we can find a good way to let everyone understand the
                                            requirements. Thus we have difference branches for difference markets,
                                            and merge back to trunk from time to time. We've try to have single
                                            trunk before and built the CI environment to try to make the trunk
                                            work proper. However even with CI built the trunk still broken very
                                            often because developer at one market don't know he break the other
                                            market.

                                            The man power wasted on merging is an issue, but the bigger issue is
                                            that the problem can be hidden in branch for a long time and it is too
                                            late to fix properly when it is identified at trunk.

                                            For my perspective this is more the team issue than technical issue,
                                            but you've mentioned about "eliminated some design options", will you
                                            think this is more on technical side? Would you mention more about
                                            your experience?

                                            May be the first reaction my our situation is our CI environment is
                                            not setup proper, otherwise the developer at market A should know his
                                            committed code broken the market B. If there is something broken at
                                            market B without test fail, developer at market B should write a unit
                                            test to catch this issue before fix it. Well, it is true, but it is
                                            very annoying that someone broken your code work in other timezone and
                                            you cannot contact him when you know your code is broken. Will you
                                            have any suggestion about this scenario?

                                            >
                                            > I have experience with a product that has seven customers, each of which
                                            > has
                                            > quite a bit of custom logic in addition to the common code. We have a
                                            > single
                                            > binary that is run for all the customers. All the customer-specific
                                            > decisions are defered until run-time. The challenge is making sure that no
                                            > customer-specific code is executed for a different customer, but our design
                                            > (as it has evolved) makes this unlikely.
                                            >

                                            > I contrast this with a similar scale project I worked on briefly that had
                                            > seven different code bases for seven customers. Each time a new customer
                                            > was
                                            > signed, the "freshest" code base was cloned and thereafter all changes had
                                            > to be merged, potentially, six times. The company was sinking under the
                                            > weight of merging.
                                            >
                                            > The key difference between the two is finding ways to defer binding. What I
                                            > found was that this began by choosing a principle--we are going to have a
                                            > single code base. This eliminated some design options, but plenty still
                                            > remained. Another important principle is that in the first case we don't
                                            > mind having some duplicate code. If it's clear how to eliminate
                                            > duplication,
                                            > we do, but we are willing to wait for clarity.
                                            >
                                            > Does this seem to apply to your situation? Are there ways you could defer
                                            > binding and reduce the build-time complexity?
                                            >
                                            > Regards,
                                            >
                                            > Kent Beck
                                            > Three Rivers Institute
                                            >
                                            > _____
                                            >
                                            > From: extremeprogramming@yahoogroups.com
                                            > [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Carfield Yim
                                            > Sent: Thursday, April 17, 2008 5:36 PM
                                            > To: extremeprogramming@yahoogroups.com
                                            > Subject: Re: [XP] Re: What do you think about parallel releases in a single
                                            > project?
                                            >
                                            >
                                            > > I am not sure what you mean by "multiple software support difference
                                            > > markets" but my guess is that no, we are not engaged in that kind of a
                                            > > project.
                                            > >
                                            >
                                            > For example for a stock trading system to support difference exchange,
                                            > like HK, TW, KR, difference software need to support difference
                                            > features, which are similar but not same.
                                            >
                                            > In theory we can still do what you've mentioned but it is difficult
                                            > because developers for difference region don't know the requirement of
                                            > other exchange. I just wonder if anyone have experience of maintain
                                            > software like this in single trunk, we were try to do that before but
                                            > the result is not good.
                                            >
                                            > [Non-text portions of this message have been removed]
                                            >
                                            >
                                            >
                                            >
                                          • Kent Beck
                                            Dear Carfield, It sounds like quite a dilemma--if you have a single binary, you break each others code. If you have separate binaries, you have to pay too
                                            Message 21 of 25 , Apr 25 7:08 AM
                                            View Source
                                            • 0 Attachment
                                              Dear Carfield,

                                              It sounds like quite a dilemma--if you have a single binary, you break each
                                              others' code. If you have separate binaries, you have to pay too much to
                                              keep them synchronized. It would be much better to be able to have a single
                                              binary where independent changes stay independent.

                                              I think what I would do in this situation is, first, make sure everyone was
                                              aware of the situation. I might call a meeting of everyone on the project,
                                              spend the first day in an open space to talk about what was going on and the
                                              second in a world cafe talking about what to do about it. Writing better
                                              tests will likely be part of the response. Better design to eliminate the
                                              source of those accidental breakages will also likely be part of it. I would
                                              try to keep my focus on the goal--productive, efficient development on a
                                              single, stable binary.

                                              The scenario you describe--A breaks B's code accidentally, B should write
                                              better tests--doesn't make sense to me. It doesn't align authority and
                                              responsibility. If I am A, I am responsible for the entire system working
                                              after making my changes. If I want to make a change and there are
                                              insufficient tests to keep me from breaking B's code, I am still
                                              responsible. I should write tests, collaborate with B, be more careful, work
                                              in a pair with someone locally, whatever it takes to keep the entire system
                                              working.

                                              Working across timezones certainly makes this more difficult. I have found
                                              it important to schedule interaction when I am working with someone
                                              remotely. I don't find regularly scheduled meetings effective when I am
                                              co-located, but a weekly (or daily or monthly) meeting is better than not
                                              interacting at all.

                                              How might this apply in your situation?

                                              Regards,

                                              Kent Beck
                                              Three Rivers Institute

                                              _____

                                              From: extremeprogramming@yahoogroups.com
                                              [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Carfield Yim
                                              Sent: Friday, April 18, 2008 11:18 AM
                                              To: extremeprogramming@yahoogroups.com
                                              Subject: Re: [XP] Re: What do you think about parallel releases in a single
                                              project?



                                              Thanks a lot for reply, We've tried to have single binary, but fail at
                                              the moment. And now it is sinking under the weight of merging. :-/ So
                                              I really like to ask how can we about to work in single binary
                                              successful.

                                              I think the major issue we have is there are too many requirements,
                                              and our development team are separate into difference city, it is not
                                              likely that we can find a good way to let everyone understand the
                                              requirements. Thus we have difference branches for difference markets,
                                              and merge back to trunk from time to time. We've try to have single
                                              trunk before and built the CI environment to try to make the trunk
                                              work proper. However even with CI built the trunk still broken very
                                              often because developer at one market don't know he break the other
                                              market.

                                              The man power wasted on merging is an issue, but the bigger issue is
                                              that the problem can be hidden in branch for a long time and it is too
                                              late to fix properly when it is identified at trunk.

                                              For my perspective this is more the team issue than technical issue,
                                              but you've mentioned about "eliminated some design options", will you
                                              think this is more on technical side? Would you mention more about
                                              your experience?

                                              May be the first reaction my our situation is our CI environment is
                                              not setup proper, otherwise the developer at market A should know his
                                              committed code broken the market B. If there is something broken at
                                              market B without test fail, developer at market B should write a unit
                                              test to catch this issue before fix it. Well, it is true, but it is
                                              very annoying that someone broken your code work in other timezone and
                                              you cannot contact him when you know your code is broken. Will you
                                              have any suggestion about this scenario?

                                              >
                                              > I have experience with a product that has seven customers, each of which
                                              > has
                                              > quite a bit of custom logic in addition to the common code. We have a
                                              > single
                                              > binary that is run for all the customers. All the customer-specific
                                              > decisions are defered until run-time. The challenge is making sure that no
                                              > customer-specific code is executed for a different customer, but our
                                              design
                                              > (as it has evolved) makes this unlikely.
                                              >

                                              > I contrast this with a similar scale project I worked on briefly that had
                                              > seven different code bases for seven customers. Each time a new customer
                                              > was
                                              > signed, the "freshest" code base was cloned and thereafter all changes had
                                              > to be merged, potentially, six times. The company was sinking under the
                                              > weight of merging.
                                              >
                                              > The key difference between the two is finding ways to defer binding. What
                                              I
                                              > found was that this began by choosing a principle--we are going to have a
                                              > single code base. This eliminated some design options, but plenty still
                                              > remained. Another important principle is that in the first case we don't
                                              > mind having some duplicate code. If it's clear how to eliminate
                                              > duplication,
                                              > we do, but we are willing to wait for clarity.
                                              >
                                              > Does this seem to apply to your situation? Are there ways you could defer
                                              > binding and reduce the build-time complexity?
                                              >
                                              > Regards,
                                              >
                                              > Kent Beck
                                              > Three Rivers Institute
                                              >
                                              > _____
                                              >
                                              > From: extremeprogramming@ <mailto:extremeprogramming%40yahoogroups.com>
                                              yahoogroups.com
                                              > [mailto:extremeprogramming@ <mailto:extremeprogramming%40yahoogroups.com>
                                              yahoogroups.com] On Behalf Of Carfield Yim
                                              > Sent: Thursday, April 17, 2008 5:36 PM
                                              > To: extremeprogramming@ <mailto:extremeprogramming%40yahoogroups.com>
                                              yahoogroups.com
                                              > Subject: Re: [XP] Re: What do you think about parallel releases in a
                                              single
                                              > project?
                                              >
                                              >
                                              > > I am not sure what you mean by "multiple software support difference
                                              > > markets" but my guess is that no, we are not engaged in that kind of a
                                              > > project.
                                              > >
                                              >
                                              > For example for a stock trading system to support difference exchange,
                                              > like HK, TW, KR, difference software need to support difference
                                              > features, which are similar but not same.
                                              >
                                              > In theory we can still do what you've mentioned but it is difficult
                                              > because developers for difference region don't know the requirement of
                                              > other exchange. I just wonder if anyone have experience of maintain
                                              > software like this in single trunk, we were try to do that before but
                                              > the result is not good.
                                              >
                                              > [Non-text portions of this message have been removed]
                                              >
                                              >
                                              >
                                              >





                                              [Non-text portions of this message have been removed]
                                            • Carfield Yim
                                              ... I am certain is not in that position. Other than that, our senior management probably overload with various meetings. Probably we need to learn more
                                              Message 22 of 25 , Apr 29 9:37 AM
                                              View Source
                                              • 0 Attachment
                                                > It sounds like quite a dilemma--if you have a single binary, you break each
                                                > others' code. If you have separate binaries, you have to pay too much to
                                                > keep them synchronized. It would be much better to be able to have a single
                                                > binary where independent changes stay independent.
                                                >
                                                > I think what I would do in this situation is, first, make sure everyone was
                                                > aware of the situation. I might call a meeting of everyone on the project,
                                                > spend the first day in an open space to talk about what was going on and the
                                                > second in a world cafe talking about what to do about it. Writing better
                                                > tests will likely be part of the response. Better design to eliminate the
                                                > source of those accidental breakages will also likely be part of it. I would
                                                > try to keep my focus on the goal--productive, efficient development on a
                                                > single, stable binary.
                                                >

                                                I am certain is not in that position. Other than that, our senior
                                                management probably overload with various meetings. Probably we need
                                                to learn more effective communication. However that would be a long
                                                long way to archieve.


                                                > The scenario you describe--A breaks B's code accidentally, B should write
                                                > better tests--doesn't make sense to me. It doesn't align authority and
                                                > responsibility. If I am A, I am responsible for the entire system working
                                                > after making my changes. If I want to make a change and there are
                                                > insufficient tests to keep me from breaking B's code, I am still
                                                > responsible. I should write tests, collaborate with B, be more careful, work
                                                > in a pair with someone locally, whatever it takes to keep the entire system
                                                > working.
                                                >

                                                True, definitely that can help. However, after having such situation,
                                                it is difficult to convince the team to try again. How can we proof to
                                                the team, to the management, that we will do better this time?

                                                > Working across timezones certainly makes this more difficult. I have found
                                                > it important to schedule interaction when I am working with someone
                                                > remotely. I don't find regularly scheduled meetings effective when I am
                                                > co-located, but a weekly (or daily or monthly) meeting is better than not
                                                > interacting at all.
                                                >
                                                > How might this apply in your situation?
                                                >

                                                Thanks a lot, this is very helpful. By the way, I am going to join
                                                other team, with probably similar situation ( i.e. multiple branch
                                                with a lot of merging :-/ ) . If I propose convert to have single
                                                binary, any paper can help me prepare better to archieve that? I've
                                                read about http://www.infoq.com/articles/agile-version-control and
                                                planning to read this book http://www.scmpatterns.com/ . Will you have
                                                any other suggestion?
                                              • Brad Appleton
                                                ... You might also want to take a look at a collection of Agile SCM articles at http://cmwiki.com/AgileSCMArticles - especially the ones on branching &
                                                Message 23 of 25 , Apr 29 10:48 PM
                                                View Source
                                                • 0 Attachment
                                                  Carfield Yim wrote:

                                                  > Thanks a lot, this is very helpful. By the way, I am going to join
                                                  > other team, with probably similar situation ( i.e. multiple branch
                                                  > with a lot of merging :-/ ) . If I propose convert to have single
                                                  > binary, any paper can help me prepare better to achieve that? I've
                                                  > read about http://www.infoq.com/articles/agile-version-control
                                                  > and planning to read this book http://www.scmpatterns.com/
                                                  > Will you have any other suggestion?

                                                  You might also want to take a look at a collection of "Agile SCM"
                                                  articles at http://cmwiki.com/AgileSCMArticles - especially the ones on
                                                  branching & merging, and release management (and one in particular on
                                                  "Lean Branching")

                                                  For managing a single binary with multiple possible configurations
                                                  without resorting to branching, you'll want to look into techniques for
                                                  what is often called "Variability Management", and is frequently
                                                  mentioned in the same breath with Product-Line or Product-Family based
                                                  engineering.

                                                  For some basic resources as well as some advanced ones, take a peek at a
                                                  recent blog-entry of mine on "Commonality and Variability Management" at
                                                  <<http://blog.bradapp.net/2008/03/commonality-and-variability-management.html>>

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