Liquibase is a database schema management tool that makes your life as a developer much easier. You can define database schema changes using a clear and easy-to-understand syntax, rather than the often headache-inducing raw SQL. Plus, you can use Liquibase to create, modify, or delete tables, columns, indexes, and other database objects, as well as to modify data or manage referential integrity.

But the benefits of Liquibase don’t stop there. It also allows you to track the history of your database schema changes and roll back changes if necessary. No more regretting that ill-advised change you made last week! And if you’re working with a team, Liquibase makes it easy to merge changes and avoid stepping on each other’s toes.

But perhaps the best part of Liquibase is its ability to deploy database schema changes to multiple environments with ease. You can generate SQL scripts or execute changes directly on the database, and use the tool’s command-line interface or its integration with popular build tools and IDEs to automate the process. No more manually deploying changes to each and every environment.

In short, Liquibase is the ultimate tool for simplifying the tedious task of managing and deploying database schema changes. I’ve been using it on a variety of projects dating as far back as 2008. So why wait? Give it a try and see the magic for yourself.

Next: Check out my Quickstart tutorial for getting started with Liquibase on Maven/MySQL projects

In a previous post, I made the case for why every developer needs Liquibase in their toolkit. This tutorial will demonstrate the ease with which you can adopt Liquibase into your workflow.

Like I’ve done on many projects, I have a local MySQL server running on my development machine. That makes testing easier. You could use this same approach to connect to a MySQL DB anywhere, like AWS or Google Cloud. For this tutorial, I’m keeping it simple to demonstrate how easy adding Liquibase to a project can be.

This tutorial assumes:

1. A pom.xml exists at the root of your <project> directory.
2. The <project> uses the typical Maven structure, e.g. production code lives in <project>/src/main/java/… and text resources live in <project>/src/main/resources/…
3. A username and password exist for the database with the right permissions for creating and dropping tables.

Now let’s dive in. It’s a simple 5 steps.

Step 1. Create a place for Liquibase files

Make a directory for database stuff and changelogs:

mkdir <project>/src/main/resources/db
mkdir <project>/src/main/resources/db/changelog

Step 2. Set up your Liquibase properties file

Liquibase uses a properties file to store information about your database connection and any additional settings you may need. Ours will be simple, only requiring four settings.

Create a text file named liquibase.properties in the <project>/src/main/resources/db directory. Edit the file to add four lines to specify the changeLogFile location, the database connection URL, and the username and password for the database.

changeLogFile: src/main/resources/db/changelog/db.changelog-master.yaml
url: jdbc:mysql://localhost:3306/myapp
username: my_username
password: my_password

Step 3. Create your first change set

A change set is a group of changes that should be applied to your database as a single unit. Next, let's specify a change to the database by adding it to the changelog. In the previous step, we said the changeLogFile would be in src/main/resources/db/changelog/db.changelog-master.yaml. We edit that file and add a change to use while testing out Liquibase. Note that we are using the YAML format, which I prefer because it’s terse. Liquibase supports other formats like XML, JSON, SQL, etc.

databaseChangeLog:
- changeSet:
    id: 1
    author: myname
    changes:
    - createTable:
        tableName: person_test
        columns:
        - column:
            autoIncrement: true
            constraints: {nullable: false, primaryKey: true}
            name: id
            type: int
        - column:
            constraints: {nullable: false}
            name: name
            type: varchar(255)
        - column:
            constraints: {nullable: false}
            name: email
            type: varchar(255)

Step 4. Add Liquibase to Maven

Now that we have the liquibase.properties file in place and our first change specified, we are ready to update our Maven pom.xml to include Liquibase. Edit the pom.xml to add the liquibase-maven-plugin to the plugins section of your build section.

<project>
...
  <build>
    <plugins>
      ... 
      <plugin>
        <groupId>org.liquibase</groupId>
        <artifactId>liquibase-maven-plugin</artifactId>
        <configuration>
          <propertyFile>src/main/resources/db/liquibase.properties</propertyFile>
        </configuration>
      </plugin>
    </plugins>
  </build>
  ...
</project>

And if you don’t already have the mysql-connector-java dependency included in your pom.xml, add it now.

<project>
  ...
  <dependencies>
    ...
    <dependency>
      <groupId>mysql</groupId>
      <artifactId>mysql-connector-java</artifactId>
      <version>8.0.31</version>
    </dependency>
  </dependencies>
  ...
</project>

Step 5. Run Liquibase

We are ready to run our first Liquibase command with Maven. First, run the liquibase:update command to add the new person_test table to the database.

> mvn liquibase:update

Then, I like to look at the database. For my satisfaction, I like to make sure that the new table got added. Since I have the MySQL server running locally, I can run a simple command to show the tables and describe the new person_test table.

> mysql -u my_username -p myapp -e "show tables; desc person_test;"
+-----------------------+
| Tables_in_myapp       |
+-----------------------+
| ...                   |
| person_test           |
| ...                   |
+-----------------------+
+-------+--------------+------+-----+---------+----------------+
| Field | Type         | Null | Key | Default | Extra          |
+-------+--------------+------+-----+---------+----------------+
| id    | int          | NO   | PRI | NULL    | auto_increment |
| name  | varchar(255) | NO   |     | NULL    |                |
| email | varchar(255) | NO   |     | NULL    |                |
+-------+--------------+------+-----+---------+----------------+

Voila! The new table exists and has the three fields we specified in our changeset. That’s how easy it is to set up and run with Liquibase.

We don’t want to keep our person_test table, though. That was just for testing. Liquibase makes it easy to roll back changes to the database. Let’s roll back that change.

> mvn liquibase:rollback -Dliquibase.rollbackCount=1

As you continue to develop your project, you can add additional change sets as needed to track and apply changes to your database. Simply add new change sets to your change log file and run the update command to apply the changes to the database.

And that’s it! You’re now up and running with Liquibase. With this tool, you’ll be able to easily track and manage changes to your database schema, making your development process more efficient and streamlined. Happy coding!

Watch a video of this tutorial on Loom

Find out more about Liquibase

Find out more about Liquibase with Maven

Find out more about Liquibase with MySQL

Roman Dobrik and I just published an article about how we have been using SnowAlert within Customer Support at Snowflake to get proactive. It’s a great evolution.
Anyone using Snowflake should probably have a read through. You might get some ideas for taking even better advantage of all that info in your warehouses!

PoP Data from SnowAlert to Slack

1. Nobody has to attend, but we might discuss serious topics
2. Treats for everyone
3. End 10 minutes to the hour
4. Tell everyone what’s on the CTO’s mind

[OPTIONAL] Meeting

Every two weeks, I host a special meeting. I invite everyone in my organization to an “optional” roundtable discussion. As many as 40 people, sit in concentric circles at 4 PM ET. We take time to discuss whatever people want to discuss. A recent data warehousing breakthrough provided ample technical conversation one week. Hiccups while moving work across teams gave us process-related debate fodder.

Those serious topics all get documented by a diligent scribe named Pati Biel. She sends the notes to all invitees. This recently won Pati a shout out from a thankful team member.

Treats Keep Them Talking

Treats vary from cookies, to cupcakes, to smoothies. They provide the little nudge some need to go from “I might just skip it…” to “Yeah, I’ll go for a Twinkie.” Given the late afternoon timing, a sugar bump seemed smart.

End Early, On Time

I keep the conversation moving, and we always end on time — at 10 minutes to the hour (4:50 PM). I push people to adopt techniques to optimize our most precious resource, time. See helpful advice like MindTools summary and Forbes more formal treatment. Consider this my little nudge to be a good role model!

End your Chit Chats 10 minutes early.

Hey CTO, What’s on Your Mind?

A couple weeks ago, a quiet session led one person to enlighten me. “What we really want to hear is what’s on your mind, PJ!”. I missed the most obvious question. So now, I start with a quick download on those topics plaguing my thoughts.

During my tenure at ThoughtWorks, Roy Singham ran regular get togethers with employees. I loved Roy’s candid chatter about everything going on at the company. Richard Harris, CEO at Intent Media, hosts monthly Fireside Chats. Employees write anonymous questions on paper. They slip them into a glass bowl. Richard then answers the questions.

Following in Roy’s and Richard’s footsteps, I sit open to ad hoc questions. It took some cajoling before I learned to keep my answers concise. I find it easy to share my concerns, but I am also palaverous.

So, keep it short, and to the point, PJ! The end.

“Keep the employees engaged, motivated, productive, innovative.”

Every lost employee represents real cost eating away precious revenue. Managers often leave their most powerful retention tool holstered — a paintbrush.

Each year, presents me with an opportunity to paint a picture with each employee. I love comp review season!

Let me share an example from 2017. An engineer expected to hear my corporate contextualization and a salary figure. Instead, I told her the salary update right away, and then segued to:

“I am so excited that you have been with us for so long. I can tell that you are one of those programmers. A programmer that will shift the way people think about technology interfaces. You challenge the norms. I love that even when the rest of the industry does one thing, you try to cross the boundary. The next 5 years are going to unleash more change in the way we interact with computers than the last 25. If you keep pushing yourself like you do, you can help lead humanity into a brave new world.”

No mincing words. No lies. Not over-inflating her ego. Nothing about me, nor the company, nor meeting professional expectations.

I tap into my own experience to guess where she might go. I steer her interests toward a big future. I use my knowledge of our industry’s history to paint a big, but realistic future. I always end with a simple question,

“Do you see that for yourself?”

I ask that question, even though I know the answer.

Her response was,

“I never thought that far ahead. That sounds exciting, but I wouldn’t even know where to start.”

That instant marks her critical shift. Instead of focusing on a narrow step or two, she sees a distant horizon pictured . This phrase, “…I wouldn’t even know where to start,” opens the door for one of the greatest honors I have as a manager. My response,

“Well, let me help you get started…”

I get out my paintbrush and help paint a big, big picture!