I would agree that testing the migration should be a part of the development process, but I think of it as a level of testing that comes after my software. First and foremost, the software has to work with the version of the database that it is designed to run against. I do understand that with large databases, this can be troublesome.
Data being valid after a migration assumes that the data was valid before the migration. When you're testing new software, that's not always the case. Bugs slip through to QE, they create data that isn't really valid using this bug, a later migration pulls along that bad data. You may not discover it for several iterations. Diego Moreira da Rosa wrote: >> Developer A should have merged from the SCM, then done a complete >> re-test, including rebuilding the database. At least, that's how I see it. >> > > > Yep, that is another solution I'd forgotten, but it is also one I was trying > to avoid. In general, I would not recommend rebuilding the database because > of these problems: > > - When you constantly rebuild your database, you are not testing data > migration, which is one of the main advantages of using a tool such as > Liquibase. > - It forces all the developers and testers to loose their test data. When > test data has been inserted during the development or testing of a new > feature or something like that, it may not be so easy to automatically > reinsert it into the database. Loosing that data can be extremely > inconvenient. > - Considering a large database, a rebuild can be potentially slower than a > simple update. > > >> It looks to me like the problem in this scenario is NOT recreating a >> database from the ground up for testing. I constantly struggle with >> this problem with our QE department. They want to keep pulling their >> data forward as changes occur, instead of creating a script that will >> regenerate their data sets. >> > > The problems that arise during development and testing are the same > that will arise during the migrations of your end users databases. As I > said, identifying these problems early is one key feature of a database > change management tool. To achieve this, you must favor updating over > rebuilding. > > >> There is always the potential for problems >> arising from data that is no longer valid after a code/database change. >> > > Data should always be valid after a code/database change. If it is not, then > you are probably not migrating your data correctly. > > Cheers, > Diego > > > Veja quais são os assuntos do momento no Yahoo! +Buscados > http://br.maisbuscados.yahoo.com > > ------------------------------------------------------------------------------ > Stay on top of everything new and different, both inside and > around Java (TM) technology - register by April 22, and save > $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. > 300 plus technical and hands-on sessions. Register today. > Use priority code J9JMT32. http://p.sf.net/sfu/p > _______________________________________________ > Liquibase-user mailing list > Liquibase-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/liquibase-user > ------------------------------------------------------------------------------ Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p _______________________________________________ Liquibase-user mailing list Liquibase-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/liquibase-user
