If anyone thinks it would be possible to add this attribute as an extension or create a standalone extension to handle the versioning within liquibase i’ll go ahead and try to write something (my java is horrible though). The idea might be
- Specify specific SVN revision in changeset e.g.
- liquibase runs “svn update --force -r"svnrevision” equivalent using
public class SVNUpdateClient extends SVNBasicClient
doUpdate(File file, SVNRevision revision, boolean recursive);
In theory this is to ensure the changeset that gets run is always the same one and not just the latest version.
Any feedback / advice welcome.
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?
Cheers
What do you mean by “losing the process of versioning in VSS”. I haven’t used VSS before to understand the issue.
I’m also not quite sure what you mean by keeping the database objects in SVN, but that being separate from the liquibase scripts. Generally it is best to have your liquibase script be the primary store of the database state, so you don’t have to duplicate code (as your developers are complaining about).
One option you may want to look at is the formatted sql changelog (http://www.liquibase.org/manual/formatted_sql_changelogs) which may be closer to the SQL scripts you are used to but still gives you the databasechangelog and changeset concepts.
Nathan
Thanks for the reply. Yes the formatted sql is very useful.
Let me rephrase the versioning question. In the oracle tutorial http://www.liquibase.org/tutorial-using-oracle it mentions using with the concept of “latest” for rereleasable objects like packages. If we release this package to a UAT environment, find a bug, fix the bug and rerelease, we will have released 2 different versions of the package to UAT. However when we come to release to production, the latest version of the package will be executed twice. This means absolutely nothing to the package itself, the end result is the same in both environments, however if between fixing the bug we were to run a script that uses the package it is possible the the result of that script may be different in UAT vs Production e.g. if the bug fix involved adding an additional parameter to a function used by the script then the script may fail in production but not in UAT. Scarier is if the script succeeds in both environments but has different results.
This is where the versioning comes in. If we are creating revisions in SVN for example for the same object and are able to extract and release the same revision of each object during each release and release everything in the same order there can be no inconsistencies. I just haven’t been able to figure out how to do this using liquibase apart from creating physical versions by copying the code into a changeset that doesn’t change.
