My standard formula for dev and ci is to use an in-memory hsqldb that is auto-seeded in an object-oriented way at start up. For updating production databases I rely on a mixture of Hibernate update and custom code similar to auto-seeding (in case datatypes/values need to be transformed). For the latter, I have a staged production system that database related updates are installed on first and then the integration test suite is run against it (that's a semi-automatic process after staging a release). If that succeeds, assumption is it's ok to accept the release and update production.
Kalle On Thu, Apr 23, 2009 at 8:58 AM, Ryan Connolly <[email protected]> wrote: > Hi All: > I was hoping someone out there in maven-users land would have > some insight into how to manage database changes in a team environment > that utilizes a dev db, a beta db used by apps built via continuous > integration, a release candidate db, and a production db. I have > looked briefly at liquibase as it is the only thing I've been able to > find that does anything close to what we need for db change management > but I'm running into a few issues with this. What do others use to > manage db changes? I would be interested mostly in solutions that > could be used in a continuous integration environment and am eager to > learn what others know about this subject. > > Thanks in advance! > > -Ryan > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
