In our previous blog post, we describe how we can conditionally prepare for database state to determine certain conditions and then only proceed to deploy our changes. This prevents us from doing errors like inserting the same record again or dropping a table full of records. However, irrespective of our precautionary measures, mistakes are bound to happen. So we need to prepare for those eventualities as well. This may also be needed if you roll out certain changes and found that those changes were inadequate to resolve the matter at hand. In liquibase, we can prepare for these kind of scenarios using the concept of rollback and tags.
Continue reading “Prepare failback strategy for database changes with Liquibase”
In our previous blog post, we discussed how we can apply different changelogs to different database environments. It is more than often, that when applying a changelog, changeset writer assumes database in a certain state. Like when you are adding a column to the database, you would assume that corresponding table is present. Or when you are dropping a table, it has no data in it. Or we assume that underlying database connection is of a particular nature. We can check for and decide what to do by using the concept of Preconditions in the Liquibase. Using preconditions allows to validate underlying assumption and decide the course of action. Continue reading “Check database state and conditionally apply changes in the Liquibase”
In our previous post, we learned how to use Liquibase to export and compare databases. That brings us to another important question: how do we deploy separate changes on separate database environments like dev, qa, prod etc. Often times, developers would want to push certain changes in the dev environment more frequently and often and not all of them necessarily make it into the production. For example, dev database may have a special ERRORLOG table which stores the debugging information, but there is no requirement of that in the QA or production environment. Similarly, QA team would like to insert some data and modify certain values Continue reading “Selectively apply Changes to Database Environments using Liquibase”
In previous post, we discussed how we can use Liquibase to deploy changeLogs to databases. Often times, when you start implementing Liquibase, you would already have a database which is being used by the application. Though Liquibase does not depend upon the existing schema, it is still a good idea to export all of the existing schema and possibly data (to some extent) and also put that information in the version control. Also, sometimes you would like to compare databases (both schema and data, again to some extent) Continue reading “Export and compare existing databases using Liquibase”
In previous post, we saw how we can install and configure Liquibase. In this blog post, we’ll see how we can leverage Liquibase to deploy changes on the Microsoft SQL Server.
Download JDBC driver for SQL Server
For this, we first need to download the JDBC driver for the SQL Server. This can be downloaded from the Microsoft using this link. The download is available in both .exe format for Windows and .tar.gz format for Mac OS X or Linux. Continue reading “Using Liquibase to manage and deploy changes on SQL Server”