Liquibase Environment Variables: It’s now easier and safer to control your deployments

July 8, 2021
Liquibase Environment Variables: It’s now easier and safer to control your deployments

Teams can now set where, when, and how Liquibase deploys database changes at the environment level. You no longer need to manage separate files for different environments! 

3 Reasons to Use Liquibase Environment Variables 

Liquibase open source allows users to set deployment parameters and flags using properties files. When you have a small team, it works really well. However, if you have many developers and you need everything to be more secure, using this new Liquibase Pro feature makes a lot of sense. 

Easier for teams

Give the right permissions to the right team members. With environment variables in place, it’s easier for developers to focus on building their code instead of worrying about their connection strings and property information.

For example, without environment variables, when a developer needs to change a flag during runtime, it can get tedious (and error-prone):

liquibase --changeLogFile=myChangeLog.sql --contexts=test,stage --labels=Jira223 --url=jdbc:mysql://hostname:3306/TEST --username=user1 --password=myStrongPassword --defaultSchemaName=mySchema --referenceUrl=jdbc:mysql://hostname:3306/DEV --referenceUsername=refUsername --referencePassword=refPassword --logLevel=FINE --classpath=/path/to/jdbc/mysql-connector-java-8.0.18.jar update

Now, with environment variables set up prior to running commands, developers only need to do this: 

liquibase update

Much easier!

Better security

Ensure no emails, passwords, URLs, and other sensitive information gets pulled into source control. Since the file contains properties such as the URL path to the database along with a username and password, placing this file in source control is not a good idea. By setting up Liquibase environment variables, all of this information can be stored in a secure environment before running commands on the server where the automation job is running.

Another advantage to separating the configuration with your repository is that when a password or other keys/values are changed, no changes need to occur in the code. The environment variables can just be updated to take effect.

Fewer productions mistakes

Human errors happen all the time. With Liquibase environment variables, you can prevent more mistakes from happening. When you configure Liquibase and manage the configuration on the server side, developers never have to see or deal with it. It significantly decreases the chances that changes are deployed to the wrong place, saving a lot of time and confusion. 

What the users & developers see

In the following Jenkins build configuration, we are setting the Liquibase environment variables as a first step, by sourcing the script in the build server’s home directory.

For example: 

. ~/ &>/dev/null

Notice that the user doesn’t have any idea what the properties are. The properties are fully managed by whoever has the access to maintain the file on the server side.

Setting up Liquibase environment variables

Typically, a DevOps team member (or someone with a special authority with access to the database) can create a shell script similar to the one below. We’ll call it This script contains several “export” commands to set the Liquibase environment variables.

export LIQUIBASE_COMMAND_URL="jdbc connection url"
export LIQUIBASE_CLASSPATH="/path/to/jdbc/driver"
export LIQUIBASE_HUB_API_KEY="hub api key"

Setting Liquibase environment variables in Jenkins

Go to Manage JenkinsConfigure system

Under Global properties click the Add button to add the Liquibase environment variable in the Name box, and the value under the Value box.

See our documentation for more information. 

Summing it up

Make your developers and your security team happy by making Liquibase even easier and safer to use. It’s completely free to try out Liquibase environment variables by grabbing a 30-day trial of Liquibase Pro. No credit card necessary. No strings. Just a happier dev team and reduced risk of sensitive data getting saved to your repo. 

Article author
Tsvi Zandany Senior Software Solutions Engineer