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

Re: [XP] Current use of branching for XP teams?

Expand Messages
  • Paul Beckford
    Hi All, Not sure if most of you will remember. But I asked a question on awhile ago on how best to use SCM and SCRUM (just remembered this was on the yahoo
    Message 1 of 49 , Mar 2 6:05 AM
    • 0 Attachment
      Hi All,

      Not sure if most of you will remember. But I asked a question on awhile
      ago on how best to use SCM and SCRUM (just remembered this was on the
      yahoo scrum group, but I'll post this here anyway).

      Brad came back with some very useful pointers.

      Anyway our experience so far:

      After fearing Branches like the plague :^) we are actually using them
      and it works quite nicely. We are using some of the ideas Brad supplied
      along with some form the following book: Pragmatic Project Automation -
      Mike Clark.

      We have a PC which we use for release staging. We have used cygwin to
      turn this into a pseudo Unix box. When we want to perform a release we
      run a bash script that does the following:

      1. Check out the release from the head
      2. Build the head and run all the unit tests
      3. Drop the WAR into tomcat and run all our Ruby Acceptance Tests (we
      use Ruby and Watir to automate Internet Explorer, hence why the machine
      needed to be a PC. We also use a Ruby Oracle driver to write test setup
      data directly to the database).
      4. If the tests pass on the head, then tag and branch (all one action in
      CVS) a release version.
      5. Check out the release into a new directory named after the release tag
      6. Run unit and accpetances again on the branch as above.
      7. if all tests pass then name the war as the branch and exit successfully.

      The result is that we have a directory on our staging machine for each
      successful release. If we need to apply a patch to a release we can do
      so in the release "staging" directory on a branch and merge changes back
      into the head as we need (we have not had to do this - but it is nice to
      have the option).

      As Brad pointed out at the time, branching isn't a big deal if done the
      right way. What we are finding is that the biggest issue is ensuring
      that all changes have been checked into the head prior to attempting to
      create a release. Also the other important thing is test coverage, in
      particular automated acceptance test coverage. We try to write an
      automated acceptance test per story. Initially our acceptance test
      coverage was light, so we relied on a fair amount of manual regression
      testing. We put a tester on Ruby automated acceptance test writing full
      time and we are getting pretty close to full test coverage. As a
      consequence the quality of our releases have increased significantly. In
      our last few end of iteration demos we have had no unexpected exceptions
      (they use to be quite common) and the time the testers spend preparing
      for the demo has reduced significantly (an hour or so compared to over a
      day in the past).

      I believe that our use of automation is a significant factor. Doing
      things the same way each time improves our confidence in the process and
      automation saves time. If we find a flaw and want to improve the way we
      work, all we need to do is tweak the bash scripts.

      We intend to take this automation further, and may start automated daily
      builds. As we extend our scripts I'll keep you all updated.


      Dominic Williams wrote:

      >Hi Derek,
      >>I find branching a very useful thing to help manage
      >>product release cycles. It's an extension of your
      >>original reason #1 "I need it for fixing bugs in
      >>older versions of our products." Once the procuct
      >>goes out of active development and into a
      >>post-development cycle (packaging, beta, release), a
      >>branch is formed so the development team can start
      >>burning through the next batch of stories that had
      >>been deferred until the following release. Any
      >>issues found post-release need to be fixed in the
      >>I'd be curious to see how you'd manage this kind of
      >>cycle without branching.
      >One way would be not to have that kind of cycle - to
      >release each increment directly to users by
      >I'm aware this has an impact on marketing, licensing
      >etc., so...
      >One way to manage that kind of cycle without branching
      >- not to introduce any defects (XP teams are supposed
      > to know how to achieve this);
      >- to make all user visible changes optional: e.g. a
      > preferences dialogue could require users to activate
      > new features, choose between old and modified
      > workflows, select among various graphical themes
      > (skins)...
      >Dominic Williams
      >To Post a message, send it to: extremeprogramming@...
      >To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
      >ad-free courtesy of objectmentor.com
      >Yahoo! Groups Links
    • George Dinwiddie
      ... [snip] ... You might want to look at Ruby Migrations, too. -- ... When I remember bygone days George Dinwiddie I think how evening
      Message 49 of 49 , Mar 7 9:55 PM
      • 0 Attachment
        Brad Appleton wrote:
        > Regarding version-control (and branching) of databases, I've been
        > "collecting" links to various threads/discussions and sites that present
        > particular strategies.
        > If anyone has any other good URLs/references, please share them!

        You might want to look at Ruby Migrations, too.

        When I remember bygone days George Dinwiddie
        I think how evening follows morn; iDIA Computing, LLC
        So many I loved were not yet dead, gdinwiddie@...
        So many I love were not yet born. http://www.idiacomputing.com
        'The Middle' by Ogden Nash http://www.agilemaryland.org
      Your message has been successfully submitted and would be delivered to recipients shortly.