Re: [Liquibase-user] Res: Starting DB from scratch
The basic structure looks reasonable. I don't put my Liquibase files in the main tree, though. (I have to admit that I haven't given a whole lot of thought to where they [should] go, though.) I created a src/main/database. Because my project grew rather organically, I'm now in the process of pulling it apart into different Maven modules. It's a somewhat painful process. If all of those files you show below are in a module that is specifically created to manage the Liquibase artifacts, then I think you're probably on to something good. Perhaps someone with more experience can jump in here and point us both in the right direction. :-) Otherwise, I think that looks pretty good. Anastasios Angelidis wrote: So I picked the changeset route on a per release level... So... my maven structure now looks like so src/main/resources liquibase liquibase.properties.template liquibase.properties master.xml r1.x 2009-04-01.xml ... Paul Keeble wrote: Absolutely! I constantly remind both the developers and QE that we have to *test the migration*. Just because your change sets work for you in your development environment does not mean that they'll work properly on real-world data. This cannot be stressed enough. Good call, Diego! This is a really important point, your changelog along with its associated changes needs testing progressively as it goes through the environments. In my opinion the moment a ChangeSet goes from being something you are working on, to something you think is ready and is checked in then you should do your utmost not to change it. Something that causes irreverseable damage obviously will need modification, but that is going to require manual intervention on every single environment its been applied to already, which for a 10 developer team + and some environments that can mount up to a lot of work of restoring backups/manually rolling back and repairing data. To put it in source control terms its like rewriting history on a published git branch, if people use that branch are going to be annoyed with you and rightly so. Paul -- ___ Liquibase-user mailing list Liquibase-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/liquibase-user -- ___ Liquibase-user mailing list Liquibase-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/liquibase-user -- ___ Liquibase-user mailing list Liquibase-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/liquibase-user
Re: [Liquibase-user] Res: Starting DB from scratch
src/main/resources is off the liquibase maven examples... David C. Hicks wrote: The basic structure looks reasonable. I don't put my Liquibase files in the main tree, though. (I have to admit that I haven't given a whole lot of thought to where they [should] go, though.) I created a src/main/database. Because my project grew rather organically, I'm now in the process of pulling it apart into different Maven modules. It's a somewhat painful process. If all of those files you show below are in a module that is specifically created to manage the Liquibase artifacts, then I think you're probably on to something good. Perhaps someone with more experience can jump in here and point us both in the right direction. :-) Otherwise, I think that looks pretty good. Anastasios Angelidis wrote: So I picked the changeset route on a per release level... So... my maven structure now looks like so src/main/resources liquibase liquibase.properties.template liquibase.properties master.xml r1.x 2009-04-01.xml ... Paul Keeble wrote: Absolutely! I constantly remind both the developers and QE that we have to *test the migration*. Just because your change sets work for you in your development environment does not mean that they'll work properly on real-world data. This cannot be stressed enough. Good call, Diego! This is a really important point, your changelog along with its associated changes needs testing progressively as it goes through the environments. In my opinion the moment a ChangeSet goes from being something you are working on, to something you think is ready and is checked in then you should do your utmost not to change it. Something that causes irreverseable damage obviously will need modification, but that is going to require manual intervention on every single environment its been applied to already, which for a 10 developer team + and some environments that can mount up to a lot of work of restoring backups/manually rolling back and repairing data. To put it in source control terms its like rewriting history on a published git branch, if people use that branch are going to be annoyed with you and rightly so. Paul -- ___ Liquibase-user mailing list Liquibase-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/liquibase-user -- ___ Liquibase-user mailing list Liquibase-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/liquibase-user -- ___ Liquibase-user mailing list Liquibase-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/liquibase-user -- ___ Liquibase-user mailing list Liquibase-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/liquibase-user
[Liquibase-user] Res: Starting DB from scratch
If you follow the best practices. That means that for every new changeset... Will you have a new file which wont be comparable against an old one? Usually you create a new changeSet for every change to be applied to the database. Except for rare cases such as when you are starting a brand new schema, you will most probably want to avoid (like hell) modifying changeSets. Now, about organizing your changeSets, you have three options: put all of them in a single changelog file; organize them according to feature/module using the include tag; use the one-changeSet-per-file approach (I personally like this one!). Notice that, by following this, the only comparison you can make is checking whether you have new changeSets or not. You dont need all of them being in the same changelog file to do this. If what you wanted was to compare different states of a table definition such as in your previous CREATE TABLE example, then you are right: there is no way to compare two versions of the same table definition. From my experience I would say that you usually dont need it. If you use one changelog.xml you can dif it, but if you use separate ones you can't diff them directly? Yep, that is right. Usually you dont need to diff. Then again one changelog.xml can become huge. Right again. That is why I like separating one changeSet per changelog file. Most people separate changeSet according to feature/module though. Hope that helps, Diego Veja quais são os assuntos do momento no Yahoo! +Buscados http://br.maisbuscados.yahoo.com -- ___ Liquibase-user mailing list Liquibase-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/liquibase-user
Re: [Liquibase-user] Res: Starting DB from scratch
So say I start from new schema... 1- New Schema = first changeset 2- Project released 3- Bug fixes 4- New changeset 5- Project released 6- Feature request 7- New changeset. We work as above. So there should be one master changelog that includes to the various changesets right? And by pointing liquibase to the master changelog only the new changes will be applied? How about in Dev-QA cycle, should the changeset be fixed or should a new changeset be made to fix the problem? Diego Moreira da Rosa wrote: If you follow the best practices. That means that for every new changeset... Will you have a new file which wont be comparable against an old one? Usually you create a new changeSet for every change to be applied to the database. Except for rare cases such as when you are starting a brand new schema, you will most probably want to avoid (like hell) modifying changeSets. Now, about organizing your changeSets, you have three options: put all of them in a single changelog file; organize them according to feature/module using the include tag; use the one-changeSet-per-file approach (I personally like this one!). Notice that, by following this, the only comparison you can make is checking whether you have new changeSets or not. You dont need all of them being in the same changelog file to do this. If what you wanted was to compare different states of a table definition such as in your previous CREATE TABLE example, then you are right: there is no way to compare two versions of the same table definition. From my experience I would say that you usually dont need it. If you use one changelog.xml you can dif it, but if you use separate ones you can't diff them directly? Yep, that is right. Usually you dont need to diff. Then again one changelog.xml can become huge. Right again. That is why I like separating one changeSet per changelog file. Most people separate changeSet according to feature/module though. Hope that helps, Diego Veja quais são os assuntos do momento no Yahoo! +Buscados http://br.maisbuscados.yahoo.com -- ___ Liquibase-user mailing list Liquibase-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/liquibase-user -- ___ Liquibase-user mailing list Liquibase-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/liquibase-user
Re: [Liquibase-user] Res: Starting DB from scratch
Whether you choose to modify change sets during the Dev-QA cycle really depends on your internal process, I would say. We haven't encountered a bug fix in which we had to make database changes. So, we haven't decided how to handle it, yet. The only problem I see with modifying an existing change set during that cycle is that QA might prefer to preserve their data. (Our QA department definitely does. They aren't even close to being automated, yet.) My personal preference would be to modify the change set - akin to fixing the bug. Then, rebuild the QA database from a point prior to that change set. Again, it's really dependent on your own procedures and preferences. On 3/31/09 8:53 PM, Anastasios Angelidis wrote: So say I start from new schema... 1- New Schema = first changeset 2- Project released 3- Bug fixes 4- New changeset 5- Project released 6- Feature request 7- New changeset. We work as above. So there should be one master changelog that includes to the various changesets right? And by pointing liquibase to the master changelog only the new changes will be applied? How about in Dev-QA cycle, should the changeset be fixed or should a new changeset be made to fix the problem? Diego Moreira da Rosa wrote: If you follow the best practices. That means that for every new changeset... Will you have a new file which wont be comparable against an old one? Usually you create a new changeSet for every change to be applied to the database. Except for rare cases such as when you are starting a brand new schema, you will most probably want to avoid (like hell) modifying changeSets. Now, about organizing your changeSets, you have three options: put all of them in a single changelog file; organize them according to feature/module using the include tag; use the one-changeSet-per-file approach (I personally like this one!). Notice that, by following this, the only comparison you can make is checking whether you have new changeSets or not. You dont need all of them being in the same changelog file to do this. If what you wanted was to compare different states of a table definition such as in your previous CREATE TABLE example, then you are right: there is no way to compare two versions of the same table definition. From my experience I would say that you usually dont need it. If you use one changelog.xml you can dif it, but if you use separate ones you can't diff them directly? Yep, that is right. Usually you dont need to diff. Then again one changelog.xml can become huge. Right again. That is why I like separating one changeSet per changelog file. Most people separate changeSet according to feature/module though. Hope that helps, Diego Veja quais são os assuntos do momento no Yahoo! +Buscados http://br.maisbuscados.yahoo.com -- ___ Liquibase-user mailing list Liquibase-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/liquibase-user -- ___ Liquibase-user mailing list Liquibase-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/liquibase-user -- ___ Liquibase-user mailing list Liquibase-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/liquibase-user
Re: [Liquibase-user] Res: Starting DB from scratch
David C. Hicks escreveu: Whether you choose to modify change sets during the Dev-QA cycle really depends on your internal process, I would say. On 3/31/09 8:53 PM, Anastasios Angelidis wrote: How about in Dev-QA cycle, should the changeset be fixed or should a new changeset be made to fix the problem? As David said, it depends. However, I prefer and recommend the idea of always creating a new changeSet. I see only one situation in which it is imperative to modify a changeSet: when there is a bug in the changeSet that causes data loss. For example, if a developer writes a changeSet to split one table in two, drops the original columns, and forgets to migrate the data. Now you have no choice, because the data is gone and there is no way to write a new changeSet to correct this. The only thing to do is to correct the data migration in the original changeSet. To reduce the occurrences of this kind of problem, it is nice to make frequent migrations using test data and/or real world populated databases. Diego -- ___ Liquibase-user mailing list Liquibase-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/liquibase-user
Re: [Liquibase-user] Res: Starting DB from scratch
Absolutely! I constantly remind both the developers and QE that we have to *test the migration*. Just because your change sets work for you in your development environment does not mean that they'll work properly on real-world data. This cannot be stressed enough. Good call, Diego! This is a really important point, your changelog along with its associated changes needs testing progressively as it goes through the environments. In my opinion the moment a ChangeSet goes from being something you are working on, to something you think is ready and is checked in then you should do your utmost not to change it. Something that causes irreverseable damage obviously will need modification, but that is going to require manual intervention on every single environment its been applied to already, which for a 10 developer team + and some environments that can mount up to a lot of work of restoring backups/manually rolling back and repairing data. To put it in source control terms its like rewriting history on a published git branch, if people use that branch are going to be annoyed with you and rightly so. Paul -- ___ Liquibase-user mailing list Liquibase-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/liquibase-user
