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

Re: [agileDatabases] Re: how to sequence database refactorings?

Expand Messages
  • Pramod
    Steve, every code branch has its own set of change files (scripts) because when we branch code our DB folder (which includes all the schema creation scripts,
    Message 1 of 15 , Jul 2, 2004
    • 0 Attachment
      Steve,

      every code branch has its own set of change files
      (scripts) because when we branch code our DB folder
      (which includes all the schema creation scripts, data
      population scripts and all the change scripts) is also
      included in the branch, that way the change files go
      along with the code branch.

      we have maintained many branches this way.

      Also the stored procedure does handle different codes
      branches (all you have to do is add code_branch
      checking to the example I sent to some folks, actually
      I stripped it out before sending the example out :( ).
      No we do not use lineage as an unit of configuration
      management since a lineage is made up of
      schema + application setup data + test data.
      There could be n number of lineages within the same
      code branch or even for a given build.

      We always keep track of lineages by their name
      say I10_QA for Iteration 10 QA database or I11_PERF
      for Iteration 11 Performance database or things
      similar to that

      Pramod

      --- Steve <spam.target@...> wrote:
      > Hi Pramod,
      >
      > I'm using a similar approach, but haven't quite yet
      > figured out how
      > to deal with source code branches (for fixes,
      > spikes, etc.).
      >
      > How are you dealing with it? I understand the
      > concept of database
      > lineages (from Martin's article)... do you use
      > lineages as units of
      > configuration management? How do you keep track of
      > which lineages go
      > with which (application) source code files? Is that
      > handled by your
      > stored procedure as well?
      >
      > Regards
      >
      > Steve Tendon
      >
      > --- In agileDatabases@yahoogroups.com, Pramod
      > <psadalage@y...> wrote:
      > > here are the details, I stripped out the previous
      > > msg's for clarity sake.. hopefully the formatting
      > > makes sense :)
      > >
      >
      > <snip>
      >
      >


      =====




      __________________________________
      Do you Yahoo!?
      Take Yahoo! Mail with you! Get it on your mobile phone.
      http://mobile.yahoo.com/maildemo
    • Steve
      According to these scheme, how do you handle merges of different branches - especially with production databases. For instance, if you have a bugfix branch
      Message 2 of 15 , Jul 5, 2004
      • 0 Attachment
        According to these scheme, how do you handle merges of different
        branches - especially with production databases. For instance, if you
        have a bugfix branch which you want to merge into the mainline, you
        have to cater for the situation where some customers have a database
        that comes from the branch (they have deployed the bugfix), while
        others have a database that comes from the mainline (they have not
        deployed the bugfix). At the mergepoint you would have to run two
        different sets of scripts to handle the merge.

        Another situation is where some customers are on a customization
        branch, and then that customization goes into the mainline and you
        get a mergepoint. Again you would have two distinct upgrade paths for
        the production databases: one for the customers with the
        customization and one for those without it.

        How do you handle the above scenarios?

        Cheers

        -ST


        --- In agileDatabases@yahoogroups.com, Pramod <psadalage@y...> wrote:
        > Steve,
        >
        > every code branch has its own set of change files
        > (scripts) because when we branch code our DB folder
        > (which includes all the schema creation scripts, data
        > population scripts and all the change scripts) is also
        > included in the branch, that way the change files go
        > along with the code branch.
        >
        <snip>
      • Pramod
        Sorry it took so long to reply, go side tracked with other stuff. Comments below. Thanks Pramod ... We handle this using the revision or release identifier on
        Message 3 of 15 , Jul 14, 2004
        • 0 Attachment
          Sorry it took so long to reply, go side tracked with
          other stuff. Comments below.

          Thanks
          Pramod
          --- Steve <spam.target@...> wrote:
          > According to these scheme, how do you handle merges
          > of different
          > branches - especially with production databases. For
          > instance, if you
          > have a bugfix branch which you want to merge into
          > the mainline, you
          > have to cater for the situation where some customers
          > have a database
          > that comes from the branch (they have deployed the
          > bugfix), while
          > others have a database that comes from the mainline
          > (they have not
          > deployed the bugfix). At the mergepoint you would
          > have to run two
          > different sets of scripts to handle the merge.


          We handle this using the revision or release
          identifier on the VersionLog table.
          Every change that is made to the database has to be
          logged and tracked in this
          versionlog table with the release being either the
          BugFix version or the Head Version, there on it does
          not matter what branch of the code base you
          made the change in, since before applying a change you
          can check if the particular change was made to the
          database (production in your case ) or not if
          it was not made then you go ahead and make the change.
          The sticking point is how to merge the base scripts
          (the script that creates all the tables/views/indexes
          etc), I guess it would have to be handled like any
          code merge

          >
          > Another situation is where some customers are on a
          > customization
          > branch, and then that customization goes into the
          > mainline and you
          > get a mergepoint. Again you would have two distinct
          > upgrade paths for
          > the production databases: one for the customers with
          > the
          > customization and one for those without it.

          Again I think this is the same situation as above, as
          long as you are tracking,
          logging and applying database changes for each branch
          then you can easily
          determine if the given change was applied to the
          customized Version or the Main
          branch or not

          >
          > How do you handle the above scenarios?


          =====




          __________________________________
          Do you Yahoo!?
          Yahoo! Mail - You care about security. So do we.
          http://promotions.yahoo.com/new_mail
        Your message has been successfully submitted and would be delivered to recipients shortly.