Liquibase is a database change operation tool designed to help you manage changes in your colorful databases as you move from development, test, and production env. It works by storing all the changes that have been made to a given database in one file i.e called a changelog. You can also load up the changelog on a new database and apply all of those changes to it. Find out further about this handy tool in this blog!
Introduction of the Liquibase
Liquibase is an open-source database change operation tool. It helps you manage your database changes in a harmonious and dependable way. it’s easy to use and has a flexible plugin armature that allows you to extend it to fit your requirements.
Liquibase was first released in 2006 and has ago been used by thousands of associations around the world. Liquibase is erected on top of the Java Database Connectivity( JDBC) API and supports a wide range of databases. it is open-source software released under Apache License2.0.
How to Setup Liquibase?
Setting up Liquibase is simple and only requires many ways. First, you need to download the Liquibase binaries from their website. Next, unfold the library and add the liquibase.bat( for Windows) or Liquibase( for Linux/ Unix) train to your PATH terrain variable. Eventually, produce a textbook train namedliquibase.properties in your design’s root directory with the following contents
driver: com.mysql.jdbc.Driver
classpath: /path/to/mysql-connector-java-5.1.34-bin.jar
url: jdbc:mysql://localhost:3306/database_name
username: root
password: passwordChange “database_name”, “root”, and “password” to the appropriate values for your database setup. The final step is to initialize your project’s database by running the following command:
liquibase --changeLogFile=changelog.xml updateWorking with Liquibase
Liquibase is an open-source database change operation tool that’s gaining fashionability in the development community. It has a number of advantages over other tools, including the capability to
Work with multiple databases, including Oracle, SQL Garçon, MySQL, PostgreSQL, and others
Handle changes to stored procedures, functions, and triggers
Automate database deployments
generate database documentation
In this section, we’ll take a look at how to get started with Liquibase and some of the best practices for using it.
Organize your Changelogs
1. Define the directory structure
The most common way to organize changelogs is by major release.
Make sure to store your changelogs in source control, preferably near your database access code
In this example, we will use com/example/db/changelog.
com.example.db.changelog
db.changelog-root.xml
db.changelog-1.0.xml
db.changelog-1.1.xml
db.changelog-2.0.xml
DatabasePool.java
AbstractDAO.java
2. Set up the root changelog and included changelog files
The db.changelog-root.xml file will automatically include the changelogs for each release in the alpha-numeric order.
Note: The db.changelog-root.xml file is the changelog name that you will pass to all Liquibase calls.
For the example above, the changelog would look like the following:
<?xml version=”1.0″ encoding=”UTF-8″?>
<databaseChangeLog
xmlns=”http://www.liquibase.org/xml/ns/dbchangelog”
xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”
xmlns:pro=”http://www.liquibase.org/xml/ns/pro”
xsi:schemaLocation=”http://www.liquibase.org/xml/ns/dbchangelog
http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-4.1.xsd
http://www.liquibase.org/xml/ns/pro
http://www.liquibase.org/xml/ns/pro/liquibase-pro-4.1.xsd”>
<includeAll path=”com/example/db/changelog/”/>
</databaseChangeLog>
The included changelogs can be in any format (including formatted SQL). Choose the appropriate format that best fits you and your team’s situation.
Use a SQL changelog when your team
- Is already familiar with SQL
- Wants to get the benefits of using Liquibase without needing to learn a new way to specify database changes
Use a Model-based changelog (XML, JSON, or YAML) when your team
- Wants to deploy a single set of changes to different types of databases
- Wants to take advantage of automated
rollbackof new database objects - Wants to take advantage of Liquibase
diffanddiffChangelogfunctionality
Here are examples of the different changelog formats for the db.changelog-1.0 file:
<?xml version=”1.0″ encoding=”UTF-8″?>
<databaseChangeLog
xmlns=”http://www.liquibase.org/xml/ns/dbchangelog”
xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”
xmlns:pro=”http://www.liquibase.org/xml/ns/pro”
xsi:schemaLocation=”http://www.liquibase.org/xml/ns/dbchangelog
http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-4.1.xsd
http://www.liquibase.org/xml/ns/pro
http://www.liquibase.org/xml/ns/pro/liquibase-pro-4.1.xsd”>
<changeSet author=”nvoxland” id=”1″>
<createTable tableName=”person”>
<column name=”id” type=”INTEGER”>
<constraints nullable=”false” primaryKey=”true” unique=”true”/>
</column>
<column name=”name” type=”VARCHAR(255)” />
</createTable>
</changeSet>
</databaseChangeLog>Establish team changelog standards
1. One change per changeset
We explosively encourage having only one change per changeset. This makes each change infinitesimal within a single sale. Each changeset either succeeds orfails.However, it can be corrected and redeployed until it succeeds, If it fails. Multiple independent changes in one changeset produce a threat that some changes emplace while a after change fails. This leaves the database in a incompletely stationed state which requires homemade intervention to correct.
The exception is when you have several changes you want to be grouped as a single sale – in that case, multiple statements in the changeset if the correct choice.
2. Define the team’s changeset ID format
Choose a changeset ID that works for you. While it can be any string, we advise using an adding number sequence starting at 1. Flash back that each changeset ID needs to be unique within the changelog.
3. Document unclear or complicated changesets
utmost of the time, changesets are tone- establishing.
still, flash back to use < comment > for any changeset s where you need to explainnon-obvious or complicated database changes to other inventors.
4. Have a rollback plan
Write changesets so they work with Liquibase rollback.
- Use a applicable Liquibase change type rather of using a custom
< sql >label. - Include a Liquibase rollback label(
< rollback >) whenever a change does n’t support an out- of- box rollback.(e.g.,< sql >,< insert >, etc).
Make sure to test rollbacks in development to insure the product rollback is safe and predictable.
5. Manage your reference data
influence Liquibase to manage your reference data. Environment separation( DEV, QA, PROD) can be achieved using Liquibase contexts. These steps can be helpful in the following situations:
- When you have test data that should only get deployed to QA environments
- When managing application configuration data – country table, application configuration data, etc
- When deploying data fixes specific to the pre-production and production environments
Develop software using this standard workflow
- Using your favorite IDE or editor, produce a new original changeset containing the change
- Run liquibase update to execute the new changeset
- Perform the corresponding changes in the operation law
- Test the new operation law together with the database change
- Commit both the changeset and the operation law to the source control
- must read: Spring Webflux
Conclusion:
In this tutorial, we learn about liquibase A Better Database Change Management. it helps to automate database migrations and helps to manage databases as you move from development, test, and production env.
