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

Maturing deployment methods using Database CI

Expand Messages
  • astro_mooseh
    I ve been tasked with shaking up and standardising the method my organisation use to build and deploy database schema. Ideally, a definition of the database
    Message 1 of 5 , Jan 3, 2008
    • 0 Attachment
      I've been tasked with shaking up and standardising the method my
      organisation use to build and deploy database schema. Ideally, a
      'definition' of the database would be packaged up as an RPM which
      could be either deployed as a new instance or used to upgrade an
      existing instance. The RPM will take a sensible backup of an existing
      database schema if there is one, which would be used if the RPM was
      uninstalled.

      Has anyone used any decent tools for managing migrations like this?
      I'm probably going to end up writing one from scratch, using exported
      hibernate sql scripts - but surely someone out there has had to do
      this before?

      It would greatly simplify CI within our teams, to be able to produce
      an RPM of the current database schema with every build. This would
      provide so much more control than just people writing their own
      scripts all over the place. Coupled with RHN Satellite, developers and
      testers could even have their local copies of the database updated
      automagically overnight - it'd be great.

      Hope to hear from someone soon,
      - Jon
    • Donald McLean
      Our database is fairly moderate (26 Hibernate classes, 33 tables) and the data load is very modest. What we have implemented is a system that uses a base plus
      Message 2 of 5 , Jan 3, 2008
      • 0 Attachment
        Our database is fairly moderate (26 Hibernate classes, 33 tables) and
        the data load is very modest.

        What we have implemented is a system that uses a base plus numbered
        updates. When the app boots, it checks to see if there are any updates
        newer than the last one applied and if there are, it applies them.

        Test databases created from scratch automatically get every update. So
        far it's working out, but then it's a fairly new application and we've
        only made one actual database change so far.

        Donald

        astro_mooseh wrote:
        > I've been tasked with shaking up and standardising the method my
        > organisation use to build and deploy database schema. Ideally, a
        > 'definition' of the database would be packaged up as an RPM which
        > could be either deployed as a new instance or used to upgrade an
        > existing instance. The RPM will take a sensible backup of an existing
        > database schema if there is one, which would be used if the RPM was
        > uninstalled.
        >
        > Has anyone used any decent tools for managing migrations like this?
        > I'm probably going to end up writing one from scratch, using exported
        > hibernate sql scripts - but surely someone out there has had to do
        > this before?
        >
        > It would greatly simplify CI within our teams, to be able to produce
        > an RPM of the current database schema with every build. This would
        > provide so much more control than just people writing their own
        > scripts all over the place. Coupled with RHN Satellite, developers and
        > testers could even have their local copies of the database updated
        > automagically overnight - it'd be great.
      • Tansey, Lisa
        We did a similar solution to Donald s (code check on app load based on comparing internal build # hard-coded into java against version number stored in
        Message 3 of 5 , Jan 4, 2008
        • 0 Attachment
          We did a similar solution to Donald's (code check on app load based on
          comparing internal build # hard-coded into java against version number
          stored in database table). We did not have an easy way to roll back,
          though; depended on taking a complete export before loading the app.
          Later versions of Oracle have this recovery area technology which might
          work for us; I haven't tried it though.


          [Non-text portions of this message have been removed]
        • timander37
          Sounds a lot like Rails Migrations http://wiki.rubyonrails.org/rails/pages/UnderstandingMigrations
          Message 4 of 5 , Jan 4, 2008
          • 0 Attachment
            Sounds a lot like Rails Migrations
            http://wiki.rubyonrails.org/rails/pages/UnderstandingMigrations


            --- In agileDatabases@yahoogroups.com, Donald McLean <dmclean@...> wrote:
            >
            > Our database is fairly moderate (26 Hibernate classes, 33 tables) and
            > the data load is very modest.
            >
            > What we have implemented is a system that uses a base plus numbered
            > updates. When the app boots, it checks to see if there are any updates
            > newer than the last one applied and if there are, it applies them.
            >
            > Test databases created from scratch automatically get every update. So
            > far it's working out, but then it's a fairly new application and we've
            > only made one actual database change so far.
            >
            > Donald
            >
            > astro_mooseh wrote:
            > > I've been tasked with shaking up and standardising the method my
            > > organisation use to build and deploy database schema. Ideally, a
            > > 'definition' of the database would be packaged up as an RPM which
            > > could be either deployed as a new instance or used to upgrade an
            > > existing instance. The RPM will take a sensible backup of an existing
            > > database schema if there is one, which would be used if the RPM was
            > > uninstalled.
            > >
            > > Has anyone used any decent tools for managing migrations like this?
            > > I'm probably going to end up writing one from scratch, using exported
            > > hibernate sql scripts - but surely someone out there has had to do
            > > this before?
            > >
            > > It would greatly simplify CI within our teams, to be able to produce
            > > an RPM of the current database schema with every build. This would
            > > provide so much more control than just people writing their own
            > > scripts all over the place. Coupled with RHN Satellite, developers and
            > > testers could even have their local copies of the database updated
            > > automagically overnight - it'd be great.
            >
          • Pramod Sadalage
            Similar to using dbdeploy or liquibase http://dbdeploy.com/ http://www.liquibase.org/ ... [Non-text portions of this message have been removed]
            Message 5 of 5 , Jan 4, 2008
            • 0 Attachment
              Similar to using dbdeploy or liquibase

              http://dbdeploy.com/

              http://www.liquibase.org/



              On Jan 4, 2008 12:22 PM, timander37 <timander@...> wrote:

              > Sounds a lot like Rails Migrations
              > http://wiki.rubyonrails.org/rails/pages/UnderstandingMigrations
              >
              > --- In agileDatabases@yahoogroups.com <agileDatabases%40yahoogroups.com>,
              > Donald McLean <dmclean@...> wrote:
              > >
              > > Our database is fairly moderate (26 Hibernate classes, 33 tables) and
              > > the data load is very modest.
              > >
              > > What we have implemented is a system that uses a base plus numbered
              > > updates. When the app boots, it checks to see if there are any updates
              > > newer than the last one applied and if there are, it applies them.
              > >
              > > Test databases created from scratch automatically get every update. So
              > > far it's working out, but then it's a fairly new application and we've
              > > only made one actual database change so far.
              > >
              > > Donald
              > >
              > > astro_mooseh wrote:
              > > > I've been tasked with shaking up and standardising the method my
              > > > organisation use to build and deploy database schema. Ideally, a
              > > > 'definition' of the database would be packaged up as an RPM which
              > > > could be either deployed as a new instance or used to upgrade an
              > > > existing instance. The RPM will take a sensible backup of an existing
              > > > database schema if there is one, which would be used if the RPM was
              > > > uninstalled.
              > > >
              > > > Has anyone used any decent tools for managing migrations like this?
              > > > I'm probably going to end up writing one from scratch, using exported
              > > > hibernate sql scripts - but surely someone out there has had to do
              > > > this before?
              > > >
              > > > It would greatly simplify CI within our teams, to be able to produce
              > > > an RPM of the current database schema with every build. This would
              > > > provide so much more control than just people writing their own
              > > > scripts all over the place. Coupled with RHN Satellite, developers and
              > > > testers could even have their local copies of the database updated
              > > > automagically overnight - it'd be great.
              > >
              >
              >
              >


              [Non-text portions of this message have been removed]
            Your message has been successfully submitted and would be delivered to recipients shortly.