Firstly many thanks to Nathan and all of the liquibase contributors. This is a great tool and obviously the result of a lot of hard work.
Where i work we have a team of 20 or so database developers. Our current release process is quite basic, we create “release notes” in excel with the name of the database object, type of object and object version within VSS. The release manager then uses a batch processes to extract everything from VSS and run it on a target database. There is no databasechangelog concept.
We’re now eyeing up the move to liquibase, coupled with ANT to release to multiple schemas and Jenkins to manage the deployment to multiple servers and baseline release. It’s looking good however the main functionality that we are losing in the process is the versioning in VSS. SVN keeps revisions, however this is not a relevant part of the liquibase process. The main source of resistance therefore has come from developers saying they are against having to store their DB objects in SVN and then copy and paste the code into a changeset file. This is mainly because of the volume of objects and scripts that they are producing as well as the size and complexity of each (15000 lines of code for a package etc). Using a tag would reduce this duplication of work, however our release order needs to be strictly followed. If we have 3 versions of a package and we use the sql file tag the final release will release the latest version 3 times and not the first 2 versions. This may have an impact on a migration script that uses a function based on the version 2 release of the package. You could argue this is a bad practice but the bottom line is we want to ensure the release objects and order are the same in all environments as standard procedure. Also from what i can see the sql file tag option doesn’t mitigate against changes to the source file itself. The checksum of the changeset doesn’t change so any changes to the source go unchecked.
I’m trying to figure out the best way to incorporate this versioning concept into our release process without increasing the workload of the developer to create a physical version or changeset. Any thoughts or suggestions would be appreciated. My first thought was to investigate adding a post-commit hook in svn to automate the changeset creation process, maybe based on the svn commit message? Anyone done anything like this?